W3 Total Cache (W3TC) VS WP Super Cache VS Quick Cache

Hvilket caching plugin er bedst i test?

Der findes mange plugins til wordpress når det kommer til caching af sidernes indhold. Her har jeg foretaget en test af de 3 mest brugte plugins. God læsning og det giver et godt indblik i hvad der gør sig gældende når vi snakker helt almindelig caching af html.

website

Der er megen snak om, hvilket cachingplugin til WordPress, der er det bedste. Der er ingen tvivl om, hvad jeg mener, der er det bedste: W3 Total Cache. Jeg er gået ud fra teori, logik og viden om, hvordan man bør gøre det, og W3TC gør det på den bedste måde i teorien. Men er det nu også det bedste i test, og hvad er godt og dårligt ved de forskellige typer af caching værktøjer? Det vil jeg se nærmere på nu. Jeg vil både se på performance og loadtid, og til det bruger jeg især to værktøjer: Pingdom Tools og AB Test (Apache Benchmark test). Dog har jeg også brugt andre værktøjer til at se loadtiden på sitet både under belastning og ved enkelte besøg.

Jeg vil lige starte med at fortælle lidt om de forskellige plugins, inden jeg viser testresultater for de tre caching plugins.

Selve testen

Testen er udført på et site, der ligner virkeligheden så meget som muligt, dog med undtagelse af at sitet ikke er besøgt eller fundet af Google. Det er den nyeste version af wordpress i engelsk udgave, og jeg har købt et tema (nevada), som rigtig mange gør i dag. Temaet har jeg sat op med det standardindhold, som temaudvikler har stillet til rådighed gennem XML import. Permalinks er aktivt.

Pingdom Tools og Apache Benchmark er brugt til at se på henholdsvis loadtid og performance for sitet. Ud over de to tests har jeg også brugt Gomez Networks, Load Impact samt Google Chrome for at skabe det valide slutresultat, som ligner virkeligheden mest – FastCGI er brugt som motor bag PHP løsningen. Ved Apache Benchmark testen har jeg kørt nedenstående, som betyder at der er kørt 1000 request med 10 samtidige brugere:

ab -n 1000 -c 10 http://www.domæne.dk/

Hver testværktøj er kørt 10 gange både med og uden caching plugins, og det er så gennemsnittet, der vil blive vist til sidst. Der er i alt kørt 250 tests, med 10 minutter mellemrum, og en omgang AB test på en statisk html fil, hvor jeg har kopieret html koden over fra den side, som jeg tester for at se, hvor meget serveren egentlig kan klare i denne forbindelse.

Det er vigtigt at sige, at testen i udgangspunktet kun ser på HTML caching / Page Caching, da det er denne del, som de nævnte plugins er fælles om at håndtere. Nogle af dem har så også CDN, Gzip, Browser Caching, og disse vil ikke blive belyst, da det ikke er fælles for dem alle.

Tests vil være delt op således:

  1. Test af løsningen uden caching plugin af nogen art (50 tests)
  2. Test af løsningen med caching plugin og deres standardindstillinger (150 tests)
  3. Test af løsningen med caching plugin og deres optimerede udgaver (50 tests)

W3TC (W3 Total Cache)

https://wordpress.org/extend/plugins/w3-total-cache/

W3 Total Cache er et af de plugins, der stort set har det hele, når vi snakker optimering af hastighed. Det har blandt andet HTML caching, som er det, vi tester i dag, og så har det minificering, Object Cache, Database Cache, Gzip, browser caching, CDN, Varnish, minificering af js og css filer, minificering af html kode, auto caching og meget mere.

W3 Total Cache laver sine HTML caching filer ved at tage outputtet fra PHP (HTML koden) og smide det ind i to html filer på serveren, en komprimeret og en ukomprimeret. Bliver denne url efterspurgt, er der en lille rewrite i htaccess, som ser på, om browseren understøtter komprimerede filer, om cache filen findes, og gør den det, bliver den vist direkte til brugeren. Gør den ikke det, vil den gå ind over WordPress for at vise denne sides indhold. Må den så caches, vil W3TC lave en cached udgave af den forespurgte side, så den næste bruger, der efterspørger samme side, i stedet vil få den cachede udgave.

Skal man opsætte hele pluginet og dens funktioner, tager det typisk 1-2 timer alt efter sitets type, indhold, aktivitet, tema mm. Men når man først har opsat hele pluginet og dens funktioner, spiller hjemmesiden typisk også. Den erstatter dog ikke den normale optimering af fx billeder, samt det at temaet, plugins mm i sig selv er kodet godt.

WP Super Cache

https://wordpress.org/extend/plugins/wp-super-cache/

WP Super Cache er et Page Caching plugin, som har nogle forskellige muligheder herunder Page Caching og CDN. Det er nemt at opsætte og kræver ikke så meget viden fra admins side. Den har tre forskellige cachingmetoder, hvor den som standard er opsat til at benytte sig af den næstbedste af de tre valgmuligheder (via PHP). Til forskel fra W3TC laver denne ikke som standard en komprimeret udgave af den cachede fil, men det er naturligvis noget, som man kan bede den om at gøre.

Skal man opsætte hele pluginet, vil det kræve omkring 20 minutter. Det er et lille plugin, som er hurtigt at opsætte, og alle kan stort set finde ud af at opsætte det.

Quick Cache

https://wordpress.org/extend/plugins/quick-cache/

Quick Cache er et endnu mindre plugin, som kun håndterer Page Caching. Der er ikke så mange indstillinger, at det gør noget, men til gengæld er det utrolig nemt at have med at gøre. Det eneste, man skal gøre for, at det virker, er at aktivere pluginet og sætte page caching til on.

De andre indstillinger omhandler primært, hvornår en side må caches, og hvornår den cachede fil skal slettes igen. Men der er også mulighed for browser caching af filen, selvom plugin udvikler anbefaler, at man ikke slår den til.

Fælle for alle plugins i denne test:

Fælles er selvfølgelig caching af den html, som hjemmesiden er bygget op af. Der er ikke rigtig andet, som er fælles for dem alle. Så det er kun tests, som viser effekten af at mindske den ventetid, der er på serveren, før html koden bliver sendt ud til brugeren.

Nu til test af loadtid og performance

Den første test

Den første test er udført på en statisk HTML fil, hvor jeg har kopieret den html kode, som forsiden på hjemmesiden spytter ud. Dette er for at se, hvor meget serveren kan klare, og hvor hurtigt serveren klare dette. Resultatet er, at serveren burde kunne klare omkring 4738,14 requests i sekundet, og at 1000 requests fra 10 samtidige brugere i gennemsnit tager 0,208ms. Det er ret hurtigt og belaster næsten ikke serveren.

Der måles på fire grupper:

  • Afviklingstid på serveren før filen sendes til brugeren
  • Antallet af forespørgsler serveren kan klare i sekundet
  • Ventetiden/afviklingstid som andre testere ser det (fx pingdoms gule markering)
  • Den fulde loadtid for sitet
Filfordeling på sitet

Det sidste punkt (Den fulde loadtid for sitet) er dog ikke noget, som man bør se på i en test som denne, da der er så mange faktorer, som spiller ind (js, css og billeder) på, hvor hurtigt det fulde site loader, at det ikke vil give et retmæssigt billede af de nævnte plugins kunnen. Den eneste fællesnævner for alle plugins i denne test, er page caching / HTML caching, og derfor er det også kun denne del, vi kan teste for at finde ud af, hvilket plugin er bedst.

Plug And Play indstillinger

Denne test er udført med de standardindstillinger, som hvert caching plugin har, altså skal man ikke gøre andet end at aktivere pluginet mv. Der er ikke brugt mere end fem minutter på at installere og opsætte hvert plugin. Kort sagt er der kun valgt én ting og tændt for pluginet.

Ventetid

ventetid-paa-server-wpsc

Ventetid, Afviklingstid, Wait, Time to first byte, ja det bliver kaldt mange ting, men det vigtige er at holde den så lav som overhovedet muligt. Både for at det går hurtigere ude hos brugeren, og fordi det uden tvivl vil aflaste serveren og gøre så serveren/hjemmesiden kan håndtere mange flere brugere på samme tid. Et plus ved dette er at man mindsker risikoen for ustabilitet, og at serveren kan bryde sammen på grund af for mange besøgende på en gang. Ja, du har jo sikkert selv prøvet det, du ser noget i tv som er møntet på rigtig mange mennesker, de nævner en webadresse, og du går ind på den. Den tanke har rigtig mange andre også tænkt, og du møder et site, der er utrolig langsomt eller ligefrem slet ikke vises.



Du kan se på det grønne diagram, som er målt med eksterne værktøjer (fx pingdom tools), at det som udgangspunkt tog serveren omkring 426ms at generere den html, der skulle sendes ud til brugeren. Med caching plugins bliver dette meget bedre, og den bedste her er W3 Total cache med sine kun 27,9 i gennemsnit.

Grunden, til den er hurtigere end fx WP Super Cache og Quick Cache, er egentlig ret simpel. W3TC har nemlig lavet en statisk HTML fil, som gennem en simpel rewrite i htaccess filen bliver vist for brugeren, hvis den da findes i statisk udgave. Derimod skal WP Super Cache og Quick Cache begge i udgangspunktet igennem WordPress for at kunne tage fat den cachede statiske fil (html og php), som de har genereret.

Quick Cache er lidt hurtigere end WP Super Cache. Årsagen har jeg ikke undersøgt til bunds. En af grundene er, at WP Super Cache laver langt mere databehandling end Quick Cache, idet WP Super Cache includer store filer, som så tjekker, om siden skal hentes i cachet udgave, eller om der skal gemmes en cachet udgave.

Antal forespørgsler i sekundet og afviklingstid på serveren

Ovenstående scenarie kan også ses, hvis man kigger på antallet af forespørgsler serveren kan klare – jo højere jo bedre. Udgangspunktet var 11,7 sider i sekundet for hjemmesiden uden caching plugins, mens W3 Total Cache gør det muligt, at serveren kan klare hele 3636,4 forespørgsler i sekundet. Igen er Quick Cache med sine 691,9 bedre end WP Super Cache med sine 334,5 og kan dermed klare dobbelt så meget. Grunden er den samme som nævnt før.

Afviklingstiden, altså den tid serveren skal bruge på at lave/generere/hente den html, som brugerens browser skal fortolke, skal helst være så lav som muligt. Det gør i sidste ende, at serveren kan klare mange flere forespørgsler/brugere på samme tid. Dermed mindskes risikoen for eventuelt nedbrud eller timeout. W3TC gør dette på 0,284ms, altså ikke engang ét millisekund bruges der på denne opgave. Samtidig betyder det også, at hjemmesiden vil køre hurtigere for den enkelte bruger, også selvom den måske lige får et boost i antallet af besøgende.

antal-sider-i-sekundet
afviklingstid-paa-serveren

Den fulde loadtid på sitet

Denne del af testen kan på sin vis ikke rigtig bruges til noget, da det som før nævnt kommer an på så mange faktorer, at vi ikke kan konkludere noget ud fra den fulde loadtid. Nogle gange kan billeder, js og css filer loade langsommere, andre gange hurtigere. Selv i de 120 tests, jeg foretog via forskellige værktøjer, kom der resultater, der var oppe at kysse 2300ms, og der kom resultater, der var nede på 1 sekund. Den store synder efter plug and play optimering var typisk javascriptfilerne, som med lidt optimering ville få den fulde loadtid længere ned og mere stabile målinger.

Så selvom W3TC ud fra tallene for den fulde loadtid er en klar vinder, kan vi ikke konkludere, at W3 Total Cache er vinderen. Det er nemlig ikke her, man skal se eller teste effekten af html caching. Det kan man først gøre, når man har optimeret js, css og billeder, da de så ikke vil være så ustabile.

fuld-loadtid-for-sitet

Konklusion på plug and play (5 min. installation og opsætning)

W3 Total Cache er den klare vinder i plug and play testen, fordi den som udgangspunkt benytter sig af den bedste metode til at vise de cachede udgaver af siderne. Det gør den ved at gå helt uden om PHP og WordPress og i stedet sende en helt statisk html fil til brugeren. Apache er super hurtig til at håndtere statiske html filer, så det er uden tvivl vejen frem, hvis du selv sidder og tænker over, hvordan du kunne lave page caching. Den eneste måde, hvorpå man kan få det hurtigere, er ved helt at undlade den rewrite, som W3TC laver, og i stedet generere filerne hvor de skal være, med de navne de skal have, som det også kan ses på den første test af den statiske html fil.

Grunden til at W3TC ikke når hele vejen til tops, hvad angår performance, er netop fordi der er en rewrite, som serveren lige skal igennem for at kunne tage fat i den rette cachede fil. Det gør altså, at antallet af request er 1000 lavere, og behandlingstiden ca 0,080ms langsommere.

De to andre plugins starter derimod op for PHP motoren og WordPress og laver en masse databehandling, for til sidst at vise brugeren den cachede udgave af HTML koden. Det er en stor synder for disse værktøjer, at de som standard kører gennem PHP og WordPress.

Men heldigvis har WP Super Cache endnu en mulighed, nemlig en mulighed der ligner W3TC måde at gøre det på, som jeg nu vil teste.

Optimerede indstillinger for HTML/Page Caching

I sidste test kiggede jeg på de indstillinger, som de forskellige caching plugins er sat til som standard. Jeg brugte ikke mere end fem minutter på at installere og opsætte hvert plugin og gjorde faktisk ikke andet end at aktivere html/page caching.

Men i denne test vil jeg se på, hvad der sker, når man i stedet bruger max 20 minutter på at opsætte især WP Super Cache. Formålet er, at den performer bedst, når vi snakker html/Page Caching, som jo stadig er det de forskellige plugins har til fælles.

Jeg vil ikke se på Quick Cache, da den ikke kan mere end det, der allerede er testet. W3TC er allerede opsat på bedste vis som standard, når vi snakker Page Caching, så det er også testet.

Det skal dog lige siges, at man i W3TC også kan minificere html koden, men det er ikke noget de andre plugins understøtter, så det bør ikke testes i denne sammenhæng.

WP Super Cache i optimeret form

Man skal gøre som følger under advanced, hvis man vil benytte sig af den bedste metode, som WP Super Cache tilbyder:

  • Vælge “use mod_rewrite to serve cache files”
  • Sætte hak i “compress pages…”
  • Og så gemme
  • Hvis ikke der bliver skrevet i htaccess filen, skal du følge anvisningerne, som kommer efter du har gemt de indstillinger. Det indebærer, at du manuelt indsætter rewritekoden i htaccess filerne.

Resultatet af at have opsat det på den bedste måde, som WP Super Cache tilbyder:

afviklingstid-paa-serveren-wpsc
antal-sider-i-sekundet-wpsc
ventetid-paa-server
fuld-loadtid-for-sitet-wpsc

Som det kan ses på den orange og blå graf, forbedrer det WP Super Cache en hel del. Det er nu gået fra 334,5 til hele 2268,5 forespørgsler i sekundet, hvilket er en forbedring på næsten otte gange. Afviklingstiden er gået fra lidt over 3 ms til under 0,5 millisekund. Ventetiden er gået fra 52,6 til 32,3. Den fulde loadtid, som vi igen ikke skal lægge for meget i, er gået fra 1832 til 1581. Så alt i alt en ret stor forbedring for WP Super Cache.

Konklusion (Vinderen er)

Konklusionen er, at W3TC blev vinderen, WP Super Cache kom på andenpladsen, og Quick Cache på sidstepladsen.

Men den gode læser vil jo kunne se, at WP Super Cache ikke er blevet lige så hurtig som W3 Total Cache, hvad angår loadtid og performance. Selvom de bruger samme grundteknik. Dette er der en grund til.

Ligesom W3TC ikke blev lige så godt som den første test på grund af rewrites i htaccess, er dette det samme for WP Super Cache. Forskellen er bare, at WP Super Cache skriver omkring 60 linjer rewrites, og W3TC laver omkring 20 linjer.

Læs evt. andre af mine artikler/blogindlæg, som afdækker emnet om htaccess og hastighed/performance, da du så vil blive meget klogere på dette område også. Men kort sagt: jo flere linjer man har i htaccess, jo dårligere performance og hastighed får man i sidste ende. Ikke mindst når vi snakker mod_rewrite, som rewrites benytter sig af, det er nemlig et langsomt og stort modul til Apache.

Der er mere end bare loadtid

Ja der er nemlig mere end bare loadtid når man skal vælge det rette cachingplugin. Selvfølgelig vil man gerne have at sitet loader hurtigt hos brugeren, men det er bestemt også vigtigt at performance spiller. Jo bedre performance, jo hurtigere loadtid.

På opfordring fra læserne

Ja på opfordring fra læserne, har jeg foretaget en yderligere 1 times optimering med alle de funktioner som ligger i W3 Total Cache. Eller det vil sige det eneste jeg har benyttet mig af og optimeret på, er minificering af html, css og javascript, Browser Caching og CDN. Og selvom der efter optimering kunne blive gjort en helt del for at optimere temaet og ikke mindst billeder, indhold mm. Så viser testen at W3TC kunne optimere hjemmesiden helt ned til en gennemsnits loadtid på 537ms indtil videre, og den havde kun et +/- på 100ms under testen, hvilket antyder at hjemmesiden er blevet mere stabil. Der mangler stadig nogle tests før det er helt sikkert hvor hurtigt det er blevet.

Her vil nogen helt sikkert tænke, jamen man behøver vel ikke hastighedsoptimere yderligere. og til det er svaret både ja og nej, for det kommer fuldt ud an på din hjemmeside, det du skal bruge den til, og ikke mindst hvor mange besøgende du har. For jo flere brugere jo mere er det vigtigt at brugeren så hurtigt som muligt får overstået den handling der er sat i gang.

Vi skal ikke belaste men aflaste serveren. 

Har du spørgsmål, så skriv endelig.

kim tetzlaff

Om forfatteren

Se mere Kim Tetzlaff

Jeg har siden 1995 arbejdet med og haft stor fokus på Teknisk SEO og hastighed på hjemmesider. Jeg er programmør, nørd og stolt af det. Jeg bygger hjemmesider, hastighedsoptimere, ser på det SEO tekniske og det er mere end 25 års erfaring der ligger bag – Du er i gode hænder når jeg laver noget for dig 🙂

2 kommentarer til “W3 Total Cache (W3TC) VS WP Super Cache VS Quick Cache”

  1. Pingback: On-Page SEO (Søgemaskineoptimering) • Den komplette guide
    • Helt klart, men set ud fra testens synspunkt, så selv med et enkelt hak i page caching (som i øvrigt ikke er så forskellig fra det man skal gøre i de andre plugins), så er du betydeligt bedre kørende end med quick cache og WP super Cache. Det er jo det testen i sit udgangspunkt ser på. Det kræver hverken viden eller andet i den dur, for sætte hak 1 sted. Ja så er det korrekt hvis man gerne vil bruge de andre funktioner, så kræver det noget viden, men det gør det jo reelt også ved de ikke standard muligheder som ligger i de andre plugins så at sige.

      Det de fleste gør galt her, er i grunden at de bare hakker alt af, fordi muligheden er der, og det gør typisk siden langsommere, især ved first load. og så tænker de, jamen det virker jo ikke det her plugin. Eller en anden som jeg også tit støder på er at de glemmer at se på siden som en almindelig bruger, ikke som admin for siden, altså skal man helst være logget ud når man tester hastigheden. For nej Ingen af de testede plugins optimere den kode som reelt er skylden til at hjemmesiden køre langsomt, så er man logget ind, vil man mærke at den del ikke er optimeret.

      Optimere man dog de andre muligheder som ligger i W3 Total Cache, så vil dette også ave en positiv indflydelse, når man er logget ind. Men ja det kræver at man ved hvad man laver.

      MVH Kim

      Svar

Skriv et svar til Kim Tetzlaff Annuller svar

Kategorier og tags på dette indlæg

, , ,

Måske du også vil læse disse indlæg

Ja, jeg har også skrevet andre indlæg som måske kunne have din interesse