Introduksjon
Veiledningen vår om WordPress-caching og hastighet omhandlet sidecaching, som lagrer ferdiggenerert HTML slik at serveren ikke trenger å sette sammen hver side på nytt for hver leser. Dette gir den største ytelsesgevinsten for de fleste nettsteder.
Sidecaching har imidlertid en blindsone.
Når du er logget inn på kontrollpanelet i WordPress, redigerer et innlegg, sjekker bestillinger i WooCommerce eller administrerer et medlemsområde, er sidene du ser tilpasset. De kan ikke hentes fra en statisk cache, fordi innholdet avhenger av hvem du er og hva du gjør. Hver gang kontrollpanelet lastes inn utløses PHP, det sendes fortsatt forespørsler til databasen, og siden bygges fortsatt opp fra bunnen av.
Objektcaching håndterer dette feltet. Objektcaching lagrer enkeltstående dataelementer som WordPress henter fra databasen gjentatte ganger, slik at de samme forespørslene ikke trenger å sendes til databasen hver gang. Med STW WordPress-hosting er verktøyet som brukes til dette vanligvis Redis, som er inkludert i alle WordPress-hostingabonnementene våre.
Hva skiller objektcaching fra sidecaching?
Sidecaching håndterer utdata. WordPress genererer en side, cachen lagrer den ferdige HTML-koden, og fremtidige lesere får den lagrede kopien. Det er raskt og effektivt for sider som er tilgjengelige for publikum.
WordPress fortsetter imidlertid å kontinuerlig hente informasjon fra databasen for nettstedsinnstillinger, menystruktur, widget-konfigurasjoner, brukerdata og innleggsmetadata. Enkelte av disse forespørslene kan returnere de samme dataene hundrevis av ganger i timen. Uten objektcaching må hver enkelt forespørsel henvende seg til databasen hver gang.
Med objektcaching sjekker WordPress først et korttidsminnelager. Hvis dataene finnes der, hopper prosessen helt over databasen og bruker resultatet som er lagret i cachen. Hvis ikke kjøres forespørselen til databasen, og resultatet hentes og lagres til neste gang.
| Sidecaching | Objektcaching | |
|---|---|---|
| Lagrer | Hele HTML-sider | Resultater fra individuelle databasesøk |
| Best for | Offentlige sider som vises til anonyme lesere | Kontrollpaneler, sider for påloggede brukere, dynamisk innhold |
| Hastighetsgevinst | Markant (omgår PHP og databasen helt) | Moderat til betydelig (reduserer belastningen på databasen) |
| Begrensning | Kan ikke lagre tilpassede eller dynamiske sider i cachen | Eliminerer ikke PHP-prosesseringen |
De to lagene utfyller hverandre. Sidecaching tar seg av frontend-delen, mens objektcaching sørger for at backend-delen reagerer raskt.
Dette er Redis
Redis er en datalagringstjeneste som lagrer data i minnet. “I minnet” betyr at den oppbevarer data i RAM i stedet for å lese dem fra disk. RAM er flere størrelsesordener raskere enn diskbasert lagring, så når WordPress ber Redis om data kommer svaret tilbake på mikrosekunder i stedet for millisekunder.
Redis er ikke en erstatning for databasen din. MySQL lagrer fortsatt alt permanent. Redis fungerer som et minnelag med hurtigtilgang foran databasen der de mest etterspurte dataene lagres, slik at databasen ikke må utføre det samme arbeidet om igjen og om igjen.
På STW WordPress-hosting kjører Redis som en dedikert tjeneste for kontoen din så snart de avanserte AccelerateWP-funksjonene er aktivert. Hvis du ikke har gjort dette ennå, sjekk veiledningen vår om WordPress-caching og nettstedshastighet som viser hvor du kan aktivere dem i Plesk.
Når er Redis faktisk nyttig?
Redis gjør ikke alle nettsteder raskere. For et brosjyrenettsted på fem sider med lite trafikk og ingen innloggede brukere er sidecaching alene tilstrekkelig. Databasen blir ikke belastet nok til at objektcaching har noen betydning.
Redis kommer til sin rett når:
- Kontrollpanelet ditt er tregt. Hvis det tar lang tid å laste inn WordPress-panelet, lagre innlegg eller navigere i innstillingene for utvidelser, kan databasen være flaskehalsen. Redis reduserer antallet forespørsler som sendes til databasen hver gang en admin-side lastes inn.
- Du har påloggede brukere. Dette kan være medlemssider, nettkurs, kundeportaler og andre typer nettsteder der brukerne logger seg på og ser tilpasset innhold. Sidecaching hjelper ikke her, siden brukerne ser forskjellige ting. Objektcaching reduserer belastningen på databasen ved å generere disse tilpassede sidene.
- Du bruker WooCommerce. Handlekurver, dynamiske produktsider, brukerkontoer og ordrehistorikk gjør at WooCommerce belaster databasen tungt. Redis sørger for at nettbutikken fungerer raskt under normale trafikkforhold.
- Nettstedet ditt har vokst til å omfatte mer enn bare noen få utvidelser. Hver utvidelse kan generere egne databaseforespørsler. Et nettsted med femten aktive utvidelser utfører betydelig flere slike forespørsler per side enn et nettsted med bare fem. Objektcaching reduserer denne ekstra belastningen.
Slik sjekker du Redis-dashbordet
Gå til Innstillinger → Redis i kontrollpanelet i WordPress. Fanen “Overview” viser tilkoblingsstatusen.
Nøkkelinformasjon på denne siden:
- Status skal vise Connected med et grønt hake-ikon
- Filesystem skal vise Writeable
- Redis skal vise Reachable
“Connection”-seksjonen viser de tekniske detaljene. På STW WordPress-hosting er klienten PhpRedis, og verten peker mot en lokal Redis-socket på serveren din. Du trenger ikke å endre noen av disse verdiene. De konfigureres automatisk.
Nederst på siden ser du to knapper:
- Flush cache sletter alt som er lagret i Redis. WordPress vil gjenoppbygge cachen etter hvert som sidene lastes inn. Bruk denne funksjonen hvis du mistenker at dataene er utdaterte eller etter en større endring på nettstedet, for eksempel bytte av tema eller masseoppdatering av utvidelser.
- Disable Object Cache slår Redis helt av. Dette bør du kun bruke til feilsøking. Under normal drift bør du la Redis være aktivert.
Metrics-fanen
Klikk på fanen Metrics for å se en graf i sanntid over svartidene til Redis.
Grafen viser hvor lang tid det tar for Redis å svare på forespørsler over tid. På et velfungerende nettsted bør du se responstider på mellom 1 og 4 millisekunder. Toppverdier over dette kan tyde på stor serverbelastning eller et stort antall samtidige forespørsler.
I denne fanen kan du også veksle mellom visningene Time, Bytes, Ratio og Calls. “Time”-visiningen er den nyttigste for en rask tilstandssjekk. “Ratio”-visningen viser treff-frekvensen i cachen. En høy frekvens betyr at Redis behandler de fleste forespørslene fra minnet i stedet for å videresende dem til databasen.
Diagnostics-fanen
Diagnostics-fanen viser en oversikt over systeminformasjon med tilkoblingsdetaljer, programvareversjoner og konfigurasjonsdata.
Denne fanen er først og fremst nyttig hvis det oppstår problemer og du må dele tekniske opplysninger med kundestøtte. Under normale omstendigheter trenger du den ikke. Viktige opplysninger å merke seg:
- Status: Connected bekrefter at Redis kjører
- PhpRedis og Redis Version viser versjonene av den installerte programvaren
- Metrics: Enabled bekrefter at grafen for målinger samler inn data
- Errors: [] betyr at det ikke er noen feil (de tomme klammene er et godt tegn)
Du kan klikke Copy diagnostics to clipboard for å hente all informasjonen til en supportforespørsel.
Når bør Redis-cachen tømmes?
Redis håndterer utløpet av sin egen cache automatisk. Vanligvis trenger du ikke å tømme den manuelt. WordPress oppdaterer de lagrede dataene når innholdet endres.
Tøm cachen når du:
- har byttet tema eller gjort større designendringer
- har installert, oppdatert eller fjernet flere utvidelser samtidig
- ser foreldede data (gamle innstillinger som henger igjen, utdatert innhold i kontrollpanelet)
- feilsøker et problem der en utvidelse ikke fungerer som forventet
Gå til Innstillinger → Redis og klikk Flush cache. WordPress bygger opp objektcachen automatisk mens du fortsetter å bruke nettstedet.
Merknad om andre Redis-utvidelser
Enkelte WordPress-veiledninger anbefaler å installere utvidelsen “Redis Object Cache” av Till Krüss fra WordPress-katalogen. Når du bruker STW WordPress-hosting er denne utvidelsen inkludert i AccelerateWP Premium-pakken, så du trenger ikke å installere den manuelt. Det er den samme utvidelsen som du finner under Innstillinger → Redis etter at Redis er aktivert i Plesk.
Ikke installer en annet Redis- eller objektcaching-utvidelse i tillegg. Å kjøre to objektcaching-lag vil bare føre til konflikter og uforutsigbarhet. Hvis Redis-siden viser status som “Connected”, fungerer utvidelsen allerede som den skal.
Hvis du bruker delt hosting uten Redis
STWs standardabonnementer for delt hosting inkluderer ikke Redis eller AccelerateWP. Objektcaching er ikke tilgjengelig med disse abonnementene.
Det betyr ikke at nettstedet ditt er fastlåst. For de fleste nettsteder på delt hosting, særlig presentasjonssider og blogger med lite trafikk fra innloggede brukere, gir sidecaching den største ytelsesforbedringen. Objektcaching er viktigst for nettsteder med aktiv administratorbruk, påloggede brukere eller omfattende databasesøk.
Hvis nettstedet ditt har vokst så mye at kontrollpanelet føles tregt og sidecaching alene ikke lenger er nok:
- Hold antallet aktive utvidelser på et minimum. Deaktiver og fjern utvidelser du ikke bruker.
- Optimaliser bildene dine før du laster dem opp. Bildeoptimalisering-veiledningen vår beskriver denne arbeidsflyten.
- Fjern overflødige data fra databasen. Databaseopprydding-veiledningen vår viser deg hvordan du gjør det.
- Vurder å oppgradere til et STW WordPress-hostingabonnement. Hosting-sammenligningen vår viser forskjellene. Redis, AccelerateWP og et bredere utvalg av ytelsesverktøy er inkludert når du velger WordPress-hosting.
Disse tiltakene reduserer belastningen på databasen fra motsatt side. Det blir færre unødvendige forespørsler, færre foreldreløse data, og nettstedet blir generelt mer optimalisert.
Konklusjon
Objektcaching med Redis utgjør lag nummer to i cache-strukturen. Sidecaching håndterer offentlige sider, mens Redis tar seg av databasesøkene som ligger til grunn for alt annet. Dette inkluderer admin-visninger, innhold for påloggede brukere og de gjentatte oppslagene WordPress utfører ved hver forespørsel.
I den neste veiledningen går vi fra optimalisering på serversiden til noe du har direkte kontroll over, nemlig hvordan du forbereder og optimaliserer bildene dine før de lastes opp til WordPress.
Neste trinn: