I denne artikel kigger vi nærmere på hvordan man udnytter caching til at få et hurtigere wordpress site. Artiklen bygger videre på vores artikelserie om optimering af wordpress med særligt fokus på hastighed i forhold til SEO-værdi. Hvis du ikke har læst den indledende artikel endnu, anbefaler vi at starte med at lære om hvorfor hastigheden er vigtig for SEO.
Hvorfor skal man bruge caching?
Helt kort fortalt: Fordi det kan gøre din hjemmeside hurtigere. I mange tilfælde kan det give en forbedring på 90% eller mere sammenlignet med hvis man slet ikke bruger caching. Det giver en markant bedre oplevelse for brugeren, og ikke mindst kan det give dig et gevaldigt boost i din placering på google og andre søgemaskiner.
Forskellige former for caching
Der findes forskellige typer af caching, som hver især har sine stærke og svage sider. Det gælder om at udnytte hver type af caching bedst muligt. De to typer som du skal kunne skelne mellem for at lave en god udnyttelse på din wordpress hjemmeside er:
- Server side caching betyder at man gemmer en statisk kopi af dynamisk indhold på serveren.
- Client side caching betyder at man gemmer en statisk kopi af dynamisk indhold på brugerens maskine.
Jo tættere på brugeren en resurse er cachet, desto billigere er den at levere.
Der findes andre typer caching, og de to ovennævnte kan desuden inddeles i adskillige “lag”, men i denne artikel kigger vi primært på de to overordnede typer af caching der er mest relevante for hjemmesider generelt og i særdeleshed wordpress.
Server side caching reducerer resurseforbruget pr. forespørgsel
En moderne hjemmeside i et CMS-system som wordpress eller joomla afvikler som udgangspunkt en masse program-kode hver gang der skal vises en side. En meget forenklet version kunne være:
- Afkod brugerens forespørgsel
- Tjek om brugeren er logget ind
- Find den relevante side i databasen
- Slå en masse ting op i databasen, f.eks. relaterede indlæg, seneste kommentarer, sidens titel og meget andet
- Find det aktive tema
- Find alle aktive plugins og undersøg om de hver især er relevante for netop denne visning
- Gennemløb tusindvis af linjer med kode for at generere den endelige side
- Send siden tilbage til brugerens browser
I rigtig mange tilfælde vil trin 2, 3, 4, 5, 6 og 7 tage ca. 90% af den samlede load-tid for hjemmesiden – hvis din server ikke er specielt hurtig kan tallet endda være endnu højere.
Men for langt de fleste hjemmesider er samtlige disse trin faktisk helt unødvendige for mange (eller alle!) forespørgsler – fordi uanset hvem der besøger en given side, og uanset hvornår det sker er siden fuldstændigt identisk. Det vil altså sige at man teknisk set lige så godt kunne gemme en kopi af det endelige resultat som er genereret en gang, og “servere” dette til alle der efterfølgende besøger samme side.
Client side caching reducerer antallet af forespørgsler til serveren
Hvor serverside caching er en kopi der gemmes på serveren er client-side en kopi der gemmes på brugerens egen maskine. Du kender sikkert de “midlertidige internetfiler” fra din egen browser – det er en lokal cache, som gør at du f.eks. ikke skal hente et firmas logo som vises øverst til venstre hver eneste gang du åbner en ny side på firmaets hjemmeside. Der ligger også massevis af scripts og stylesheets, og i visse tilfælde hele hjemmesider.
Client-side caching bør udnyttes maksimalt til resurser der sjældent eller aldrig ændrer sig – såkaldt statisk indhold. Hvis en bruger først har hentet dit logo en gang er det virkelig fjollet hvis det skal hentes igen og dermed forsinke ved hver sidehentning (og belaste serveren, bruge trafik mv!). Det samme gælder for scripts og styles, som typisk går igen på samtlige sider. Også billeder som kun vises på en side er det fornuftigt at cache hos brugeren – det kan jo være at brugeren vender tilbage til samme side.
Jo oftere en resurse genbruges, desto vigtigere er client side caching for den.
Client-side caching kan desuden bruges i mange af de tilfælde hvor server-side caching er udelukket pga. brugertilpasset indhold.
Den store styrke ved client side caching er at det ligger helt ude på slutbrugerens maskine. Det vil altså sige at serveren ingen resurser skal bruge, og fra brugerens synsvinkel går det lynhurtigt. Selv store billeder hentes på millisekunder fra cachen.
Hvornår skal man bruge caching?
I den ideelle verden er svaret meget simpelt: Hver gang det kan lade sig gøre… Caching som er korrekt implementeret giver utroligt mange fordele og ingen ulemper.
Man skelner mellem en cachet resurse og en frisk resurse for hver forespørgsel til et “emne” der potentielt kan caches. Frisk betyder at indholdet er genereret netop til den forespørgsel der kommer fra brugeren, mens cachet betyder at indholdet allerede ligger klar og venter på forespørgslen. De færreste hjemmesider kan køre med 100% cachet indhold, men omvendt er der ingen hjemmesider der kræver frisk indhold for hver eneste forespørgsel.
Der er dog visse situationer hvor det ikke er muligt at cache indholdet.
Man kan som udgangspunkt ikke bruge nogen type caching til dynamisk indhold. Men typisk er dynamisk indhold jo dikteret ud fra en række regler, f.eks.: “Vis Dansk menu hvis brugeren er Dansker, ellers Engelsk“.
Hvis caching systemet skelner mellem præcist de samme kriterier som selve indholdet kan cachen altså udnyttes. Hvis indholdet f.eks. udelukkende afhænger af brugerens identitet (login, IP adresse eller lign.), er det muligt at udnytte browserens cache da denne jo tilhører brugeren.
For de to nævnte typer caching er rækkefølgen for hver enkelt forespørgsel (hvis man udnytter begge typer!):
- Tjek om der ligger en gyldig cachet resurse i browserens egen cache. Hvis ja, returner den.
- Send forespørgsel til serveren.
- Tjek om der ligger en cachet resurse i serverens cache. Hvis ja, returner den.
- Generer indholdet på ny, og gem en cachet version.
- Returner indholdet til browseren.
- Gem en kopi i browserens cache, hvis der er angivet at resursen kan caches lokalt.
For hver enkelt resurse (altså f.eks. en side, et billede, et stylesheet osv) er det altså muligt at definere en række betingelser der skal være opfyldt for at en bestemt version kan lagres i en bestemt caching-mekanisme og genbruges til visninger der opfylder samme betingelser.
Jo bredere reglerne for hvornår der kan bruges en cachet resurse i stedet for en frisk er, desto mere effektiv er cachen, fordi flere forespørgsler kan håndteres så tidligt som muligt i forløbet.
Derfor er det vigtigste trin i optimeringen at identificere de dele der er helt statiske, og lave en fælles cache for disse, som deles mellem alle. F.eks. har du sikkert en menu og en footer som går igen på alle sider, og som sagtens kan deles mellem alle der besøger siden. Ligeledes er rigtig mange af dine sider sikkert reelt helt statiske, og kan dermed caches i deres fulde udgave både på serveren og hos brugeren. Dine stylesheets, scripts og billeder ændres også meget sjældent, og bør derfor højst sendes til brugeren en enkelt gang pr. besøg.
Derimod ville det være meget uheldigt hvis indholdet på en søgeside blev genbrugt til en anden søgning eller visning af indkøbskurven i din shop blev genbrugt til forskellige kunder.
Udløb af caching
En cachet resurse kan i nogle tilfælde være uændret i mange år, men det kan ofte svare sig at udnytte caching for resurser der har langt kortere “levetid” end det. F.eks. ændrer du nok sjældent ret meget på et blog-indlæg når det først er udgivet – men hvis du alligevel retter lidt hist og her skulle det jo gerne kunne ses. Derfor er det nødvendigt at kunne rydde cachen.
For serverside caching er det i teorien nemt nok. De cachede filer ligger jo på serveren, så de skal bare slettes når du har rettet indlægget, så vil der automatisk blive lavet en frisk kopi næste gang der er behov for det.
Men for client-side caching er det noget mere kompliceret. Her ligger resursen jo helt ude hos brugeren, så serveren har ikke nogen mulighed for at slette den når der sker ændringer. Client side caching skal altså planlægges så udløbstidspunktet for en given resurse ligger indenfor det tidsrum man forventer at den vil forblive uændret. Der er metoder til at omgå dette, men det betyder alligevel at man primært bruger client side caching til resurser som man forventer aldrig vil ændres; f.eks. billeder, stylesheets og scripts – men ikke selve indlæggenes indhold, da det er svært at vide om man ønsker at ændre dem senere, og i så fald hvornår.
Hvordan laver man selv caching?
Meget af ovenstående med individuelle caching regler for forskellige brugere og forskellige resurser er teoretisk muligt – og bestemt værd at stræbe efter. Derfor er det godt at have forståelsen for hvad caching rent faktisk betyder – hvor forskellige caching mekanismer arbejder, og hvad deres stærke og svage sider er.
Men hvis du selv skal implementere din caching mekanisme skal du nok fokusere på at opnå de største gevinster med mindst mulig investering, i stedet for at gå helt i detaljen for at opnå det ideelle caching system.
Et effektivt udgangspunkt for langt de fleste overvejende statiske sider (alm. informationshjemmeside, blog ol.) er derfor at definere at en URL svarer til et stykke unikt indhold. Hvis du har en dansk og en engelsk version af dit site, så har hver side en unik URL for hvert sprog, og vil derfor blive cachet hver for sig. Hvis din hjemmeside viser forskelligt indhold på samme URL er der mange gode argumenter for at få det lavet om straks, men det hører ikke til i denne artikel.
En anden god grund til at vælge URL’en som det primære ID til cachens indhold er at det giver dig en rigtig nem og ofte meget effektiv måde at implementere caching på din wordpress hjemmeside. Der findes adskillige caching plugins, som følger netop dette system og flere af dem er vældig gode. Det vi normalt selv vælger er WP Super Cache. Det er et gratis plugin og giver med minimal opsætning meget store gevinster.
Husk at aktivere WP Super Cache efter installationen
Når du har installeret plugin’et er det vigtigt at du går til dets indstillinger (Under “Indstillinger” -> “WP Super Cache”) og vælger “Caching On”. Det skulle uden videre betyde at de fleste besøgende til din hjemmeside får serveret cachede resurser, og at den gennemsnitlige loadtid på din hjemmeside dermed er reduceret markant. Bemærk at brugere der er logget ind som udgangspunkt ikke får cachede resurser serveret, så du vil ikke opleve forskellen før du enten logger ud eller bruger en helt anden browser.
WP Super Cache vil automatisk slette den cachede version af et indlæg eller en side når du f.eks. ændrer noget eller der kommer en ny kommentar. Alligevel kan der opstå situationer hvor du manuelt skal rydde hele cachen. Det gør du ved blot at klikke “Delete Cache” øverst i menubjælken.
Hvis du har mod på det kan du opnå endnu større gevinster ved at grave ned i de avancerede indstillinger. Husk at der er situationer hvor caching ikke kan bruges, så tænk over om det kan være relevant for nogen af dine sider, og sørg for at de i så fald bliver udeladt fra WP Super Cache.
Kan man få hjælp til caching?
Vi har stor viden på området, og kan hjælpe med både opsætning af caching og mange andre typer optimering af din hjemmeside. Ring eller skriv, så tager vi en uforpligtende snak om netop dine behov!