Tilbud på hastighedsoptimering lige nu

Hastighed og performance på wordpress løsninger – WordCamp 2013

[vimeo id=”82463967″ width=”669″]

Introduktion

Mit navn er Kim Tetzlaff, Jeg beskæftiger mig med mange forskellige ting, jeg beskæftiger mig blandt andet med udvikling af hjemmesider og det har jeg gjort i 17 år. Jeg beskæftiger mig også med SEO og teknisk optimering – det har jeg gjort i 12 år. Hastighedsoptimering, som jeg skal snakke om, har jeg på den ene eller den anden måde altid haft med i mit arbejde. Af uddannelse har jeg taget multimediedesigneruddannelsen. Til hverdag driver jeg min egen virksomhed KTJ-Media.dk og derudover er jeg med i flere andre projekter.

Indhold

Jeg skal i dag snakke lidt om hastighedsoptimering på wordpress løsninger, og det er et område som jeg selv går meget op i når jeg bygger og producere hjemmesider hvad enten det er wordpress eller specialprogrammering. Det er ikke bare generel hastighedsoptimering jeg vil snakke om men mere en, vælg den rette motor til at køre din wordpress løsning på, og du kan oppe performance x 16 eller mere.

Jeg vil også fortælle hvordan du opnår den højeste performance din server kan klare.

De tips og tricks jeg vil komme ind på vil både være mere og mindre teknisk så er der noget i ikke forstår eller behøver uddybet så spørg endelig. I skulle jo gerne kunne følge med.

Vi starter fra en ende af

WordPress er bygget i PHP, og her er det ikke helt ligegyldigt hvilken udgave af PHP man køre med på serveren, her mener jeg ikke version, men udgave som fx SuPHP, Fast CGI eller Mod_PHP også kaldet PHP Handler. Det er så at sige motoren bag fortolkningen af den PHP kode hjemmesiden er bygget op af.
php handler - SuPHP, fastcgi , mod_php

Mange servere køre i dag med SuPHP. Har snakket med flere webhoteludbydere og deres grund til at de netop køre med denne PHP handler, er fordi sikkerheden er høj og den er lettere for køber af webhotellet at have med at gøre.  Men hvad nu hvis man rent faktisk kan få hastigheden fra Mod_PHP og sikkerheden fra SuPHP? Det ville jo være idelt, og man kan rent faktisk få dette gennem

Jeg har kørt 2 forskellige tests på et WP multisite, hvor der er installeret temaet twenty eleven og omkring 20 forskellige plugins. De to tests jeg har kørt er en normal pingdom test, som ser på loadtiden for en given url.

Og den anden er en AB test, Apache Benchmark test, som er en test hvor man kan teste performance på en url. AB testen er god fordi man her kan teste flere samtidige brugere, lave et bestemt antal forespørgsler. I de forskellige tests vil jeg bruge 10 samtidige brugere som laver 1000 forespørgsler.

SuPHP:

Jeg tested SuPHP som er den langsomste af de 3 PHP handlere, og resultatet af AB testen viser da også at serveren kan klare 5.76 forespørgsler i sekundet, og at hver forespørgsel i gennemsnit tager 1735ms. Hvilket er langsomt og meget lav performance.

Requests per second:    5.76 [#/sec] (mean)
Time per request:       1734.978 [ms] (mean)
SuPHP - Pingdom test og AB test

Sitets loadtid (Pingdom Tools) afspejler det også meget godt. Nogen vil måske sige, at det er jo fint nok, og det er jo under 2 sekunder, men hvad nu hvis man ved skift til en anden PHP handler faktisk kan forbedre det drastisk? Det er nemlig muligt at forbedre det en helt del.

Fast CGI

Ved brug af FastCGI vil du uden tvivl kunne opnå en bedre performance, og en bedre loadtid. Netop fordi den tager det gode fra begge verdener.

Requests per second:    89.80 [#/sec] (mean)
Time per request:       111.355 [ms] (mean)
FastCGI - Pingdom og Apache Benchmark Test - AB test

Som det kan ses ret tydeligt på de 2 versioner, så giver Fast CGI godt og vel 16 gange bedre performance og ca 10 gange hurtigere afvikling end SuPHP, så det kan bestemt anbefales at man bruger Fast CGI frem for SuPHP, Især hvis man regner med at få mange besøgende.

Sværhedsgraden for denne er under middel, da det kræver en smule viden om fil og mapperettigheder, men de er ikke så forskellige fra andre udgaver. Laver man et skift fra den ene version til den anden, skal man også huske at ejeren af filerne skal ændres fra bruger til www-data, dette gør man typisk via SSH, eller kontakter udbyderen.

Der kan altid blive gjort mere, også i det her tilfælde.

Du så nok på eksemplet fra pingdom ovenfor, at den Gule del (ventetid som typisk bliver brugt på at generere den html der sendes til brugerens browser) fyldte lidt meget.

Men hvad gør man ved denne ventetid?

En ting man kan gøre hvis man er programmør, er at gennemsøge plugins og især temafiler for flaskehalse som kan forbedres. Programmer til dette er xDebug sammen med WinCacheGrind. Som man kan køre på sin interne server (fx WAMP). Plugins skal man dog ikke rette til, men derimod skrive til plugin udvikler at de bør rette det til, og først hvis de ikke retter det, så  kan du naturligvis godt rette pluginet til.

Men ud over det skal man have gang i HTML caching, som er yderst effektivt. Her findes der flere måder at gøre det på, den mest effektive er dog at man generere hver enkelt sides html, og gemmer dette i en html fil på serveren. Denne html fil bliver så sendt til brugeren når den respektive side efterspørges.

Det lyder svært, men i wordpress er der faktisk flere plugins til formålet. Der er 2 af slagsen som jeg mener, er de bedste: W3 Total Cache og WP Super Cache.

Effekten af HTML Caching er helt utrolig, se her:

Requests per second:    3938.92 [#/sec] (mean)
Time per request:       2.539 [ms] (mean)
W3 Total Cache - HTML Caching gør underværker for performance og loadtid

Altså i sidste ende et boost i performance på ca. 680 gange, set i forhold til udgangspunktet. Og en optimering i loadtiden på 5-7 gange.

Det er noget der batter må man sige. Selvom der typisk bør blive gjort betydeligt mere for at oppe hastigheden, men her har jeg vis de 2 vigtigste ting som gør noget for en hjemmesides hastighed, og samtidig giver dig muligheden for at arbejde lidt videre med det, og fx også se på CDN, Minificering, sammenlægning, browser cache mm.

SPØRGSMÅL SOM KOM TIL FREMLÆGGELSEN PÅ WORDCAMP 2013 DANMARK

Det jeg bedst kan li ved en sådan fremlæggelse er at besvare de spørgsmål folk der sidder der ude, har. også selvom det er kritiske, eller får mig til at se tingene fra en anden vinkel.

HVOR SKAL MAN ÆNDRE, ELLER HVEM SKAL MAN KONTAKTE, FOR AT FÅ ÆNDRET FRA SUPHP TIL FASTCGI?

Du skal typisk ringe til din webhoteludbyder for at få at vide hvilken version du lige nu køre på serveren. og har de SuPHP kan du spørge om det er muligt at få FastCGI, ellers kan du vælge at flytte fra den udbyder over til en som kan tilbyde dig det. For Dedikerede servere og virtuelle servere vil det typisk være en mulighed at indstille dette i kontrolpanelet for et givent webhotel.

KAN MAN PÅ WEBHOTELLET KUNNE SE HVILKEN PHP HANDLER DER BLIVER BRUGT?

Både og, der vil være en indikation af hvilken PHP handler der køre på serveren, men den er lidt vag i sin angivelse af handler. For selvom der fx står, CGI/FastCGI, så kan SuPHP stå som CGI også. Så det er lidt svært at vide helt eksakt, men spørg din server/webhoteludbyder for at være helt sikker.

HVOR ER DISSE TESTS FORETAGET? HVOR LIGGER TESTHJEMMESIDEN?

Alle tests er udført på samme server som KTJ-Media.dk også ligger på, det vil sige på et live site, som har besøgende, hvor serveren også har besøgende. De fleste test er dog lavet på de tidspunkter hvor der har været færest besøgende på den pågældende server.

Hvor meget tid bruger du til at sætte WP Total Cache op, for det er jo et plugin med mange funktioner og indstillinger.

Altså lige denne her del hvor jeg kun har set på html Caching, har jeg rundet regnet brugt 10 minutter på at installere, aktivere og teste. Hvis det eneste man vil er at HTML cache sin hjemmeside, er WP Super Cache fint, da genereringen af html cachen via w3tc vil kræve for meget af serveren set i forhold til at det eneste man vil er at cache siden. W3 Total Cache kan jo meget mere end det og er derfor også et stort plugin.

Nu er vi jo nede i millisekunder, hvor er den store fordel i at gå op i millisekunder, det er jo ikke ligefrem noget at skrive hjem om.

Først og fremmest var udgangspunktet for testen ikke så værst endda, den var på 1500ms og kunne servere ca 6 sider i sekundet. Ved at benytte sig af FastCGI i stedet for SuPHP, blev loadtiden halveret og hjemmesiden kan nu servere 89 sider i sekundet. Og yderligere at aktivere HTML caching, kom vi ned på ca 300ms loadtid, og serveren kan nu servere næsten 4000 sider i sekundet. Derfor betyder Millisekunder altid noget. Og nej det er ikke kun noget man får noget ud af når man har mange brugere, Enkeltbesøg og hjemmesider med få besøgende, vil i den grad mærke en forskel… Men det er især noget der har betydning når man har mange brugere, da det kan være forskellen mellem en server der går ned og en server der ikke går ned.

Har du testet en af de andre PHP handlere? (Mod_PHP)

Ja, men jeg har ikke taget det med. Jeg gik ud fra det jeg havde testet og tog den dårligste og den bedste set i forhold til WordPress. Det er selvfølgelig altid bedst at benytte sig af Mod_PHP, men set i forhold til WordPress er det faktisk bedre at bruge FastCGI da denne har en højere sikkerhed og fil / mapperettigheder er nemmere. Og den nærmer sig samme performance som Mod_PHP.

Jeg havde nogle problemer med W3 Total Cache, er det faldet til ro igen?

Ja det var fordi der var et sikkerhedshul i W3TC, som gjorde at man kunne gå ind og se databasecache, hvilket jo ikke ligefrem er godt. Men samtidig resulterede det også i at servernes FireWalls også prøvede at beskytte mod dette hul. Og de var så lidt for strikse så strikse at W3TC begyndte på at timeoute og meget andet. Altså loadede W3TC meeeget langsomt. Men fejlene er rettet og pluginet fungerer som det skal.

Jeg ved ikke om du kan svare på det, men Total Cache, der er noget der hedder Object Cache og Database cache, hvad er forskellen og hvad gør de.

Database cache gør det at den cacher databasens resultat, for en given side, mens Object Caching på sin vis kan ses som html caching, bare i meget mindre bidder.

– Hvad skulle fordelen være ved at bruge Database/Object cache?
Det kan være en fordel på sider hvor der er meget aktivitet, men stadig det er ikke noget jeg selv ville bruge eller anbefale man bruger, da det kræver så mange resourcer at det rent faktisk i mange tilfælde bedre kan betale sig helt at skære det væk, ved bruge af almindelig HTML caching.

Er der forskel på de forskellige hosts eller bruger de alle den samme handler?

Det er meget forskelligt hvad de forskellige udbydere bruger, men de fleste benytter sig af SuPHP. Selv der hvor min server står benytter sig af SuPHP, men siger at de hurtigst muligt vil få lavet det om til FastCGI. Og de gør det fordi de går op i sikkerheden og egentlig ikke har tænkt over at sikkerheden fra SuPHP er taget med over i FastCGI.

Har du nogen erfaring med hvor hurtige shared hosts er?

Altså der er ikke den store forskel, de fleste er hurtige så vidt jeg har set. Også de billige. Det er først når man kommer op i de større løsninger, hvor der er mange plugins, mange sider mm, at de begynder at have problemer. Man kan sige, kan man ikke få sin hjemmeside hurtig på en lille server, har man gjort noget galt. Man vil i de fleste tilfælde kunne få en hjemmeside til at være hurtig også på små servere.

Du nævnte W3TC, men hvis du bruger WP Super Cache, som laver statiske filer, så vil man jo slet ikke komme i nærheden af WordPress, Databaser, PHP mm. Ville det så ikke være bedre at bruge WP Super Cache?

Det er det samme for W3TC, den laver også statiske filer. Den store forskel er bare at WP super Cache som standard kommer ind over WordPress og PHP, mens W3TC går helt uden om. Og sætter man WP Super Cache til at køre på samme måde som W3TC, vil WP Super Cache skrive langt flere Rewrites i htaccess filen, og dette kan potentielt gøre så den rent faktisk er langsommere.

Hvorfor er w3tc bedre at bruge frem for fx Quick Cache?

Der er flere grunde, du skal jo også sørge for sammenlægning af filer, minificering af filer og html, CDN mm. Der er så mange ting i W3 Total Cache som gør at det rent faktisk bedre kan betale sig at bruge det, frem for et plugin som udelukkende ser på HTML caching.

– Laver den alt det her inden den laver cache filer?

Ja, den gør sådan set det at den minificere HTML koden, og gemmer outputtet i en html fil på serveren. Denne fil bliver så serveret direkte til brugeren når en url bliver efterspurgt. Ud over det minificere og sammenlægger den CSS og JS filer ”On The Fly” og gemmer også disse i deres respektive filer på serveren og de bliver så efterspurgt direkte uden brug af htaccess. I begge ovenstående tilfælde gemmer den også en komprimeret udgave af filen.

Alternativet er at installerer 10 plugins for at opnå det samme resultat, hvilket kan give et dårligere resultat da de jo så skal kunne spille sammen.

Har du prøvet Varnish Caching?

Både ja og nej, jeg prøvede det engang, og min erfaring med det er at man alt for tit møder sider som ikke findes, selvom de reelt set findes på hjemmesiden, da der er en form for delay fra varnish er blevet slettet til den henter en ny version af hjemmesiden.

Nu vi snakker om W3 Total Cache, der er jo 900 indstillinger i det, og jeg aktivere typisk det jeg kan og håber på det går godt. Hvor lang tid ville du skulle bruge på at opsætte det så det spiller maks?

Typisk vil jeg skulle bruge 1-2 timer på at opsætte og teste for bedste performance. Fordi det der også er problemet er at man ikke altid bare kan sige at minificering af javascript og css kode skal ske pr automatik (en indstilling i w3tc), da fx javascriptkode alt for tit laver fejl på den måde, grundet inline jquery mm. Så man skal tænke sig lidt om her og rent faktisk teste det til man får det bedste både i loadtid, men også hvad angår det visuelle. Ud over det er hjemmesider jo forskellige og kræver derfor også forskellige indstillinger.

På forskellige typer af hosts kan man vælge mellem (memcached mf) er det noget man skal sætte sit caching plugin op til, og er det noget man skal gøre, hvad kan du sige om det?

I W3TC er det sådan at hvis der er andre muligheder åbne, som fx memcached, så vil du kunne vælge dette på en dropdown menu, og cache via den vej. Men Memcached er ikke lige så hurtig som HTML cache på filbasis. Grunden er at du med memcached skal ind over wordpress og php for at kunne læse fra hukommelsen.

Er der noget tidspunkt hvor du ikke ville bruge HTML caching som W3TC gør det?

Altså så skulle siden være utrolig aktiv, fx Amino.dk ville jeg nok ikke gøre det på, Jeg ville måske gå ind og sige at indlæg der er en måned gamle skal caches, da dette vil spare serveren for rigtig meget arbejde, og dermed gøre andre indlæg og sider hurtigere.

Jeg ville ikke gøre det på nye indlæg netop fordi du både skal slette, skrive og læse konstant. Hvilket også tager power fra serveren, og dermed har man lidt fjernet den fordel som det har at cache sider.

En anden måde man kunne gøre det på er at man cacher alle sider der ikke har haft skriveaktivitet i 30 minutter. Ud over det kan man også lave en delvis caching af sider, fx cache elementer som ikke ændre sig helt så tit, fx en footer, header, elementer i sidebaren mm. Og det kan man også i wordpress gøre.

Hvad med CDN er det en god ide? Er det noget der rykker.

Det kan betale sig hvis man har et stort site med mange statiske filer, men har man et lille site med få statiske filer og yderligere henvender sig til danskere kan det ikke betale sig med fx amazon som er meget brugt. Da loadtiden faktisk vil blive højere.

Der hvor det kan betale sig er hvis man fx hoster i dk, men henvender sig til folk i udlandet. Eller hvis man har et stort site med mange statiske filer og gerne vil sprede filer ud over flere servere. Her vil det kunne betale sig, da filerne så vil være tæt på dine brugere. Men husk, man bruger typisk en CDN til statiske filer som billeder, css, javascript, video mm.

Der er begyndt at poppe flere og flere udbydere op der giver mulighed for fx litespeed. Hvad er realiteterne for en wordpress på litespeed, er de hurtigere end apache?

Ja litespeed er i sit udgangspunkt hurtigere end apache serveren, men det overflødiggøre ikke at man optimere yderligere på sit site i form af fx HTML caching, minificering af js/css mm. Da du selv på en litespeed, kan optimere performance for et website.

Et tænkt eksempel er at du er i aftenshowet fortæller om dit site, og det resulterer så i et øget antal besøg inden for meget kort tid, hvis det du tilbyder, er interessant for folk, kan du risikere at dette er flere tusinde på en gang.

Har du så ikke html cachet din side, vil det betyde at alle de brugere skal igennem PHP og litespeed mf skal også i gang. Og så er en behandlingstid (i php) på fx 200ms ret højt, og kan i sidste ende lægge din server ned. Men har du HTML cachet din html, så brugeren rent faktisk ikke kommer i nærheden af PHP/Wordpress, så vil behandlingstiden måske være på 2-3ms, og så afhænger det pludselig mere af båndbredden hos udbyderen, frem for om serveren nu kan holde til det.

Du nævnte W3tc og WP Super Cache, men så er der Quick Cache som jo i grunden bare er plug and play, ligesom WP Super Cache jo også er, har du prøvet Quick Cache?

Nej jeg har ikke prøvet Quick Cache, s ved reelt set ikke hvordan den arbejder, hvordan den cacher mm. Men det vil jeg da tage et kig på.

 UPDATE: Tester lige nu Quick Cache og der vil komme en artikel for sig til denne del.

Nu nævnte du at du havde testet på et site med 20 plugins, er det et problem at der er 20 plugins?

Nej det er ikke et problem, det der er et problem er hvis man glemmer at opdatere dem og man ikke husker at gøre hvad man kan for at optimere di her plugins. Et eksempel MailChimp er et plugin rigtig mange bruger, men det har i 1-2 år haft en fejl som de endnu ikke har fjernet, og så må man jo selv gå ind og rette den når de ikke selv vil rette den.

Det er ikke antallet af plugins der er problemet, men kvaliteten af de plugins man bruger der kan skabe problemer for hastigheden. 1 plugin er i grunden nok til at et site kan gå ned.

Jeg bruger nogle plugins til backend og andre til frontend, har de to typer indflydelse på hinanden?

Ja de har indflydelse på hinanden, da WordPress bliver nød til at læse og fortolke for at den kan finde ud af hvad den skal gøre, og dette gør den hele vejen igennem. Ellers ved den jo ikke at der er noget der skal bruges i henholdsvis backend og frontend.

Er W3TC noget der kun skal konfigureres en gang, eller skal man gøre det løbende?

For mit vedkommende er det noget der skal konfigureres hver gang der kommer pluginopdateringer, forstået på den måde at jeg jo i forhold til css og js minificering, ikke benytter mig af AUTO funktionen, da den typisk er langsommere. Og ændre pluginet pludselig stier til de her filer, så skal de jo opdateres i W3TC pluginet. Men det er noget de fleste kan finde ud af, da det jo står i html koden hvor denne fil er flyttet hen, og så er det jo i grunden bare copy/paste.

Eller hvis du installerer nye plugins, og gerne vil have at dennes css og js filer skal minificeres, skal de jo også skrives ind på listen.

Hvor stor indvirkning har det at du hoster det hele i USA?

Altså, serverne er jo typisk de samme, der hvor man vil kunne opleve en nedsat hastighed er hvis man fx er en dansk bruger der tilgår denne server. Så vil der være en ventetid på omkring 4-7 sekunder, alene fordi serveren er placeret så langt væk.

Nu nævnte du pingdom, men bruger du andre værktøjer når du optimere hastigheden?

Ja, jeg bruger blandt andet: Pingdom Tools, Apache Benchmark, xDebug, ySlow, Google pagespeed, Google Chromes indbyggede loadtool. Og min sunde fornuft.

Er der noget at hente på at lægge filerne på subdomæner?

Ja det er der, men du vil ikke få samme effekt som ved fx en reel CDN. Men ja det vil gøre noget for hastigheden. Det man jo skal huske er at alle cookies skal fjernes fra domænet, og der skal sættes de rette headere mm. Og det er det en CDN blandt andet gør.

Reelle domæner vil faktisk være bedre at bruge end subdomæner, da de ikke kan associeres med hoveddomænet.

Skriv en kommentar

Målet er kvalitet

Det er mit mål at levere kvalitetsløsninger med høj fokus på hastighed og teknisk seo. Uanset om der er tale om små eller store løsninger, vil fokus altid være på hastighed og teknisk seo.