Når det kommer til web performance, er WordPress-cache kun en af ​​de ting, som enhver webstedsejer har noget at gøre med på et eller andet tidspunkt. Vi elsker WordPress, men det er bestemt ikke den hurtigste platform, især hvis du sammenligner det med et helt statisk sted. En af grundene til dette er simpelthen fordi det er bygget på PHP, som kun kan udføre ting så hurtigt. Vi så nogle massive forbedringer med PHP 8.0 og PHP 8.1, men hvis du ikke cacher dit websted korrekt, kan det stadig komme til en crawl.

Ville det ikke være rart, hvis du ikke behøver at bekymre dig om at finde ud af, hvilket cache-plugin der er bedst? Nå, her hos Kinsta, tager vi os af at cache for dig, så du kan fokusere på at vokse din virksomhed.

Hvad er WordPress Cache?

Cache er processen med at gemme ressourcer fra en anmodning og genbruge disse ressourcer til efterfølgende anmodninger. Grundlæggende reducerer den mængden af ​​arbejde, der kræves for at generere en sidevisning.

Hvorfor skal du bruge cache? Det er enkelt, cache gør WordPress-websteder hurtigere og reducerer belastningen på webserveren. Dette er grunden til, at ethvert websted bør stræbe efter at bruge så meget cache som muligt. Desuden reducerer det i tilfælde af CDN-cache også mængden af ​​serve-rbåndbredde, der kræves for at generere en sidevisning ved at gemme statiske ressourcer, der er eksterne fra din WordPress-host.

Der kræves ingen WordPress-cache-plugins hos Kinsta

Det er rigtigt! Hvis du er vært for dit WordPress-sted med Kinsta, behøver du ikke at bekymre dig om at kommunikere med nogen komplicerede og forvirrende cache-plugins. Det er fordi vi allerede har implementeret forskellige typer cache. Du kan endelig stoppe med at google rundt for de “bedste cache-plugins fra 2019” og fokusere på mere produktive opgaver.

Hos Kinsta bruger vi følgende fire typer cache, som alle automatisk udføres på software- eller serverniveau:

Mange af vores kunder rapporterer om enorme fald i belastningstider, blot ved at migrere til Kinsta. Nedenfor er et eksempel på et websted, der oplevede en 212,5% stigning i ydelsen. Og dette er uden nogen form for cache-plugin installeret.

WordPress belastningstider hos Kinsta
WordPress belastningstider hos Kinsta

Der er andre variabler involveret i disse belastningstider reduceres også, men cache er en enorm del af det. Vi siger ikke, at alle cache-plugins er dårlige, faktisk skyldes det mange gange, at brugeren ikke konfigurerer cache-pluginet korrekt, hvilket igen bremser sit WordPress-sted. Har du nogensinde prøvet at konfigurere W3 Total Cache? Det kan blive direkte forvirrende temmelig hurtigt.

Tag ikke vores ord for det

Og så vidt præstation går, skal du ikke bare tage vores ord for det, så tjek nogle af disse udtalelser fra folk, der er migreret til Kinsta. Alle bruger ikke længere cache-plugins.

Typer af WordPress Cache

Lad os dykke ned i hver type WordPress-cache, som du løbende løber ind her på Kinsta. At forstå, hvad hvert lag af cache gør, hjælper dig med at fejlfinde problemer i forbindelse med cache og sikrer, at dit websted kører problemfrit.

Bytecode-cache

Bytecode-cache gemmer kompileret PHP-kode, så compilerings-trinnet næste gang det bruges, kan springes over. Hos Kinsta har vi aktiveret OPcache i PHP 7.3 og 7.4 (og aktiverer det i nyere versioner af PHP, når de frigives på vores platform).

Opdatering: PHP 8.1 (officiel udgivelse) er nu tilgængelig for alle Kinsta-klienter. PHP 7.4 understøttes ikke længere hos Kinsta. Bemærk venligst, at vi understøtter PHP version 8.1, 8.2 og 8.3.

Når en PHP-fil eller script behandles, skal den først kompileres til maskinlæsbar opcode. Hvad OPcache gør, er at gemme den konverterede opcode, så PHP vil være i stand til at springe kompileringstrinnet over næste gang, der kræves en bestemt fil eller script. Brug af OPcache forbedrer PHPs ydelse markant. Det betyder dog, at ændringer til PHP-filer ikke afspejles straks. Af denne grund er OPcache deaktiveret på Kinsta-scenesites.

Læs mere om, hvordan OPcache fremskynder PHP-applikationer.

Object Cache

Object cache gemmer resultaterne af databaseforespørgsler, så næste gang der kræves en bestemt bit af data, kan det leveres fra cache uden forespørgsel til databasen. Dette fremskynder udførelsestider for PHP og reducerer belastningen på din WordPress-database.

WordPress har en indbygget object cache: WP_Object_Cache. Denne cache gemmer imidlertid kun objekter til en enkelt sidebelastning. Formålet med cachen er at sikre, at databasen ikke bliver forespurgt nøjagtigt på samme måde flere gange i løbet af en enkelt sideindlæsning. Cache-genstande bruges dog ikke efter den ene sideindlæsning. Selvom dette er en nyttig funktion i WordPress, er object cache meget mere kraftfuld, hvis object cache kan bruges mellem flere sideladninger.

Du kan ændre denne opførsel og genbruge cache-objekter til flere page loads ved at skifte fra WordPress ‘indbyggede object cache til en ekstern løsning. Dette gøres ved at droppe et cache-script i /wp-content/ biblioteket. Der er plugin-baserede object cache indstillinger såsom W3 Total Cache.

Vores kunder hos Kinsta kan også købe vores Redis-tilføjelse og få det installeret sammen med PHP 8.0 eller 8.1. Redis er en open source, i hukommelse datastruktur butik, der bruges som en database, cache og meddelelsesmægler. Se vores artikel om, hvordan du bruger Redis som en vedvarende cache, hvis du vil lære mere.

Page cache

Page cache gemmer hele HTML’en på en side, så efterfølgende sidevisninger kan genereres uden at WordPress behøver at generere siden.

Når du indlæser et WordPress-websted, skal WordPress behandle et stort antal PHP-filer og forespørge databasen et antal gange. For sider, der ikke konstant opdateres, er dette spildt arbejde. Det er meget mere effektivt at generere hver side bare én gang, derefter gemme den side og levere de efterfølgende besøgende. Dette gør, hvad caching af sider gør.

Fordelene ved sidecache inkluderer:

  • Meget hurtigere page loads.
  • Dramatisk reduceret serverbelastning og evnen til at håndtere dramatisk mere trafik som et resultat.

Vores servere bruger nginx fastcgi cache-modulet til sidecaching, og det er indstillet til at udløbe hver 1. time som standard. Klienter kan dog når som helst ændre sidecache-udløb i MyKinsta-dashboardet. For at ændre sidens cache-udløbstid skal du gå til dit websteds side “Værktøjer”, klikke på rullemenuen “Rediger” under “Site-cache” og klikke på Skift cacheudløb.

Skift udløbstid for sidecache i MyKinsta.
Skift udløbstid for sidecache i MyKinsta.

På modulet “Skift cacheudløb” skal du vælge den udløbstid, du vil have, og klikke på Skift udløb. Vi tilbyder muligheder fra 1 time til 7 dage. For websteder, der ikke ændres ofte, kan det være nyttigt med hensyn til ydeevne at have en længere cacheudløb.

Indstillinger for udløb af sidecache i MyKinsta.
Indstillinger for udløb af sidecache i MyKinsta.

Page cache er konfigureret til at arbejde lige ud af boksen med standard WordPress-, BuddyPress-, WooCommerce- og Easy Digital Download-websteder. Dette betyder, at sider som WordPress-dashboardet, WooCommerce-indkøbsvogne, BuddyPress-fora for indloggede brugere og mere automatisk omgås fra sidecachen. Hvis du bruger en meget tilpasset WordPress-opsætning, kan det være nødvendigt med yderligere tilpasninger af sidens cacheindstillinger, og det vil vores supportteam kunne hjælpe dig med.

Som standard er side-cache deaktiveret på Kinsta-scenesites. I nogle tilfælde er aktivering af sidecache ved scene nyttigt til testformål. Sidecaching til scenesteder kan aktiveres i MyKinsta-dashboardetet .

CDN-cache

CDN-cache gemmer webstedsfiler (som JavaScript, CSS og mediefiler) ude på et content delivery network for hurtigere levering til brugere, der er geografisk fjernt fra værtsserverens placering. Når nogen forsøger at nå et websted, leveres disse filer fra CDN snarere end at skulle leveres fra den server, der rent faktisk er vært for webstedet. Læs mere, hvorfor du skal bruge et CDN.

Et content delivery network (CDN) tilbyder to primære fordele:

  • Det reducerer de serverressourcer, der kræves for at indlæse et websted. Da CDN udfører arbejdet, behøver webserveren ikke at gøre det.
  • Det gør det muligt at levere ressourcer fra lokationer over hele verden, hvilket fremskynder webstedspræstation for brugere, der er geografisk fjernt fra serveren, der er vært for webstedet.

Der er to grundlæggende typer CDN’er: dem, der simpelthen er CDN’er, og dem, der tilbyder et CDN sammen med sikkerhedsfunktioner. Et par almindelige eksempler på hver inkluderer:

  • Standard CDN: Stackpath, CloudFront.
  • CDN plus security: Kinsta CDN (Cloudflare), Sucuri, Akamai (valgfrit).

Den første type CDN konfigureres ved at oprette CDN -URL’er, der bruges til at få adgang til webstedets ressourcer. Den nøjagtige måde, hvorpå dette aktiveres, varierer fra det ene CDN til det næste. Grundtanken er, at URL’er til statiske ressourcer ændres til CDN -URL’en, så ressourcerne trækkes fra CDN’et. Et standard CDN gemmer typisk kun statiske filer som JS, CSS og mediefiler.

Den anden type CDN fungerer som en fuld proxy-server. Hvad dette betyder er, at hver anmodning skal køre på tværs af udbyderens servere, før den ankommer til Kinstas servere. Dette aktiveres ved at bruge CDN-udbyderens navneservere, så CDN-udbyderen har fuld kontrol over webstedets DNS. Dette giver udbyderen mulighed for at gøre mange ting, som et simpelt CDN ikke kan gøre, såsom at filtrere trafik fra dårlige IP’er, tilbyde DoS/DDoS -beskyttelse eller endda gemme en helsides cache ude på CDN. Vores Kinsta CDN drives af Cloudflare, en proxy-ydelse/sikkerhedstjeneste.

Avanceret CDN-cache

Hvis du bruger en proxyserver CDN som Cloudflare eller Sucuri, har du muligheden for at oprette en komplet sidecache på CDN. Brug af et CDN som Cloudflare eller Sucuri til at cache HTML-side på fuld side aflæser alt arbejde fra vores servere fuldstændigt og er en fremragende løsning for et websted, der forventer at se en massiv stigning i trafik.

Kinsta Cache Response Header

Du kan teste for at se, om din side serveres fra Kinsta-cache ved at se på dine HTTP-response headers. Kinsta tilføjer et X-Kinsta-Cache-overskrift. Ved den første anmodning til en ikke-cachelagret side, viser den MISS, som det ses nedenfor.

Miss cache header
Miss cache header

Ved den anden anmodning til den samme side viser X-Kinsta-Cache header value et HIT, hvilket betyder, at den serveres fra cache.

Hit cache header
Hit cache header

Og hvis du læser vores artikel om at score 100/100 i Google PageSpeed Insights, vil du vide, at Kinsta også har yderligere optimeringer på serverniveau til automatisk at løse følgende advarsler, du måske er bekendt med:

  • Aktivér komprimering (Kinsta har allerede Gzip aktiveret på alle servere, ikke nødvendigt at aktivere)
  • Reducer serverens responstid (Kinsta brænder allerede hurtigt, allerede inden for Googles acceptable parametre uden optimeringer)
  • Expires headers (Ingen grund til at aktivere, fordi Kinsta har cache-overskrifter aktiveret på serverniveau)

For eksempel scorer vores teststed en 100/100 på PageSpeed Insights uden noget cache-plugin aktiveret. WordPress-cachen håndteres alt sammen af Kinsta på serverniveau.

PageSpeed Insights
PageSpeed Insights

Kinsta Cache-indstillinger

Rydning af WordPress-cache

Hvis du manuelt vil rydde din fuld sides cache, kan du gøre det fra MyKinsta dashboardet. Klik blot på dit websted, klik på værktøjer og klik på knappen “Ryd cache”.

Ryd WordPress-cache i MyKinsta.
Ryd WordPress-cache i MyKinsta.

Som standard er cache deaktiveret i Kinsta WordPress scenemiljøer. Hvis du gerne vil teste cache funktionen på et scenesite, kan du aktivere cache ved hjælp af “Site Cache” -værktøjet i MyKinsta-dashboardet. Når cache er aktiveret i et scenemiljøe, kan du bruge knappen “Ryd cache” til at rydde cachen, ligesom det levende miljø.

Kinsta MU-plugin

Den anden mulighed, du har, er at bruge Kinsta MU-plugin. Hvad? Ja, teknisk set er det et cache-plugin, men det er ikke dit typiske cache-plugin, da det fungerer på et serverniveau.

Som standard installeres Kinsta MU-plugin på alle websteder, der hostes af os og er tilgængelige fra venstre side af dit WordPress admin dashboard. Dette bruges til intelligent at rydde cachen på passende sider på dit websted. Plugin er påkrævet for at sikre, at dit websted kører problemfrit i vores miljø. Husk også, at sidecachen udløber hver 1. time som standard.

Kinsta MU plugin.
Kinsta MU plugin.

Pluginet giver dig også mulighed for at rense cachen lige fra din WordPress admin bar. Dette ville sandsynligvis være en af de største grunde til at bruge det, da du ikke behøver at hoppe over i MyKinsta dashboardet. Du kan gøre det lige fra dit websted.

Ryd cache fra WordPress toolbar
Ryd cache fra WordPress toolbar

Det giver dig også mulighed for at oprette custom cache-regler. Afhængig af hvordan dit websteds konfiguration kan der være behov for yderligere cache-regler. Du kan tilføje tilpassede stier til udrensning, når dit websted opdateres.

Du kan også kontakte vores supportteam, hvis du har brug for en bestemt side eller URL ekskluderet fra cache.

Kinsta Scenemiljø

Scenemiljøer på Kinsta har som standard cachelagring af sider deaktiveret. Dette gør det nemt at udvikle og debugge dit WordPress-sted uden at skulle rydde cachen manuelt efter hver redigering. I nogle tilfælde kan du muligvis aktivere sidecache i et scenemiljø for at køre en nøjagtig hastighedstest for en cachelagret side uden at skubbe dit websted live.

For at aktivere cache-cache i et scenemiljø skal du navigere til Sites> Værktøjer i MyKinsta og klikke på knappen “Aktivér cache”. Når cache er aktiveret ved iscenesættelse, kan du bruge knappen “Ryd cache” til at rense cachen.

Aktivér cache-side til dit scenesite.
Aktivér cache-side til dit scenesite.

Kinsta Cache Analytics

Du kan tage et dybt dyb ned i, hvor godt dit WordPress-sted cache i MyKinsta Analytics. Cache-komponentstakken giver dig mulighed for at se status for hver anmodning, hvad enten det var en HIT, BYPASS, MISS eller EXPIRED. Du kan filtrere dataene inden for de sidste 24 timer, 7 dage eller 30 dage.

Kinsta cache-komponentstabel
Kinsta cache-komponentstabel

Cache-komponentkortet giver dig et hurtigt blik på dit cache-forhold. Jo flere anmodninger du serverer fra cache, jo bedre.

Kinsta cache-komponentstabel
Kinsta cache-komponentstabel

I det øverste cache-bypass-afsnit kan du se, hvilke anmodninger der ikke vises fra cache. Disse kan typisk omfatte CRON-job, admin-ajax-anmodninger, e-handels-kassesider, forespørgselsstrenge og UTM-parametre osv.

WordPress top cache omgår
WordPress top cache omgår

Cache 404 sider

404 sider kan være meget ressourcekrævende. En masse WordPress-websteder, især store medlemssites, genererer flere 404 errors, end du måske tror. Måske har du ændret placeringen af en side og glemt at tilføje en omdirigering, eller du har et forkert link på noget, du delte på sociale medier. Med andre ord er der mange ting, der får en besøgende til at ende på din 404-side. Disse sider har også en tendens til at have forespørgsler til at få alternative søgeresultater, som derefter rammer databasen.

For at sikre en bedre ydelse på dit WordPress-websted cache Kinsta cache 404 sider i 15 minutter. Værdien på X-Kinsta-Cache-overskriften viser en HIT, hvilket betyder, at den serveres fra cache. Hvis du opretter en side, der tidligere var en 404, renses cachen straks.

Vores MyKinsta analyseværktøj kan hjælpe dig med at bestemme den nøjagtige mængde af 404 errors, der sker på dit websted.

404 fejlfordeling
404 fejlfordeling

Det er dog vigtigt at præcisere, at vi ikke cacher alle 404 anmodninger. Der er to forskellige typer: dem fra PHP-sider, der lander på din 404-side, og dem fra manglende filer eller billeder, der ikke længere findes eller er blevet flyttet. Vi cache 404 sider, 404 anmodninger om manglende filer og billeder håndteres forskelligt.

Derfor kan du bruge “Top 404-errors” til bedre at bestemme, hvor og hvad der forårsager disse.

404 forespørselsside cache lagret
404 forespørselsside cache lagret

Du kan også kontrollere 404-errors i Google Search Console eller installere et tredjeparts plugin, f.eks. omdirigering, der logger 404-fejl. Husk dog, at plugins som disse også har indflydelse på ydelsen. Det er meget bedre at stole på et værktøj på serverniveau.

Opret en simpel 404-template, der undgår forespørgsel om databasen yderligere, hvis muligt.

POST anmoder om BYPASS-cache

Vi ønsker, at vores analyser og cache-statistikker skal være så nøjagtige som muligt. Det er vigtigt, at når du fejlfinding af ydelsesproblemer, normalt ser du på dit samlede cache-HIT-forhold, som du ønsker at være så høj som muligt. Derfor er POST-anmodninger inkluderet i vores rapportering.

POST-anmodninger kan ikke caches, bortset fra nogle meget specialiserede opsætninger. Værdien på X-Kinsta-Cache-headeren viser en BYPASS for disse anmodninger. Disse må ikke forveksles med blogindlæg eller nogen form for WordPress-indlæg (som kan genoprettes). En POST-anmodning bruges til at sende data til serveren. Så for eksempel gemmes de data, der sendes, når du sender en webformular i HTTP-anmodningens anmodningsorgan.

Resumé

Forhåbentlig forstår du nu lidt mere om WordPress-cache og de fire forskellige typer, du vil løbe op med regelmæssigt her på Kinsta: bytecode-cache, object cache, sidecache og CDN-cache.

Hvis du er træt af at kommunikere med typiske WordPress-cache-plugins og blot ønsker et hurtigt sted lige fra flagermus, anbefaler vi dig at prøve Kinsta! Der er en grund til, at vi har fået status som “top tier” i WordPress-ydelse 5 år i træk af ReviewSignal. Og det er fordi vores servere finjusteres oven på Google Cloud Platform til lynhurtige belastningstider. Du bliver ikke skuffet over vores præstation.

Brian Jackson

Brian har en stor lidenskab for WordPress, har brugt det i over et årti og udvikler endda et par premium plugins. Brian kan lide blogging, film og vandreture. Opret forbindelse med Brian på Twitter.