När det gäller webbprestanda är WordPress-cache bara en av de saker som varje webbplatsägare måste hantera vid en eller annan punkt. Vi älskar WordPress, men det är definitivt inte den snabbaste plattformen, speciellt om du jämför det med en helt statisk webbplats. En anledning till detta är helt enkelt att det är byggt på PHP som bara kan utföra saker till en viss hastighet. Vi har sett några enorma förbättringar med PHP 8.0 och PHP 8.1, men om du inte cachar på din webbplats korrekt kan den ändå komma att krypa fram.
Skulle det inte vara trevligt om du inte behövde oroa dig för att ta reda på vilket cacheplugin som är bäst? Tja, här hos Kinsta, tar vi hand om cachning åt dig, så du kan fokusera på att växa din verksamhet.
Vad är WordPress-Cache?
Cachning är processen som lagrar resurser från en begäran och återanvänder dessa resurser för efterföljande förfrågningar. I grund och botten minskas den mängd arbete som krävs för att visa en sida.
Varför ska du använda cacheminnet? Det är enkelt, cachning gör WordPress-webbplatser snabbare och minskar belastningen på webbservern. Det är därför som varje webbplats bör sträva efter att använda så mycket cachning som möjligt. Dessutom reducerar det vid CDN-cachning också mängden serverbandbredd som krävs för att skapa en sidvisning genom att lagra statiska resurser som är externa från din WordPress-värd.
Inga WordPress Cache-plugin Behövs hos Kinsta
Det är rätt! Om du hostar din WordPress-webbplats med Kinsta behöver du inte oroa dig för att krångla med några komplicerade och förvirrande cachning-plugin. Det beror på att vi redan har implementerat olika typer av cachning. Du kan äntligen sluta Googla runt för ”bästa cachning-plugin 2024” och fokusera på mer produktiva uppgifter.
Vid Kinsta använder vi följande fyra typer av cache, som alla automatiskt görs på program- eller servernivå:
Många urav våra kunder rapporterar stora minskningar i laddtider genom att enkelt migrera till Kinst. Nedan är ett exempel på en sajt som upplevde en 215.5% ökning i prestanda. Och detta är helt utan några caching-plugin installerad,
Det finns också andra variabler som är inblandade i den här laddningstiden, men cachning är en stor del av det. Vi säger inte att alla cacheplugin är dåliga, det är faktiskt många gånger det beror på att användaren inte konfigurerar cachepluginet korrekt, vilket i sin tur saktar ner deras WordPress-webbplats. Har du någonsin försökt konfigurera W3 Total Cache? Det kan bli ordentligt förvirrande ganska snabbt.
Lita inte bara på vad vi säger
Och när det gäller prestanda, lita inte bara på vad vi säger själva, kolla in några av dessa omdömen från människor som har migrerat till Kinsta. Ingen använder längre cacheplugins.
An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀
— WPColt (@WPColt) January 3, 2018
Quite impressed what @googlecloud and @kinsta can pull of for #WordPress hosting! #DevOps #Cloud #WPDev #webdevelopment pic.twitter.com/Cr7UMaHdpH
— Neuralab (@Neuralab) July 22, 2017
@TheSportReview's new @Googlecloud based @kinsta environment handled the post-match @ManUtd v @ChelseaFC traffic spike in style 👌⚽ pic.twitter.com/kJewykSqaV
— Martin Caparrotta (@MartinCap) April 16, 2017
60%+ drop in @pingdom load times for @voompla after move to @kinsta + @CloudFlare CDN + site optimization! support by @tomzur @MarkGavalda
— Palash Bakshi (@ppbakshi) September 11, 2016
Typer av WordPress-cache
Låt oss nu dyka in i varje typ av WordPress-cache du regelbundet kommer att träffa på här på Kinsta. Att förstå vad varje lager av cachning gör hjälper dig att felsöka problem relaterade till cache och säkerställer att din webbplats kommer att fungera smidigt.
Bytecode Cache
Bytecode cache förvarar kompilerad PHP-kod så att kompileringsteget kan hoppas över nästa gång den används. Vid Kinsta har vi aktiverat OPcache i PHP 7.3 och 7.4 (och kommer aktivera det i nyare versioner av PHP allteftersom de släpps på vår plattform).
Uppdatering: PHP 8.1 (officiell release) finns nu tillgänglig för alla Kinsta-kunder. PHP 7.4 stöds inte längre hos Kinsta. Observera att vi stöder PHP-versionerna 7.4, 8.0, 8.1, 8.2, 8.3 och 8.4.
När en PHP-fil eller ett skript behandlas måste det först sammanställas i maskinläsbar opkod. Vad OPcache gör är att lagra den konverterade opkoden så att PHP kommer att kunna hoppa över kompileringssteget nästa gång den specifika filen eller skriptet behövs. Att använda OPcache förbättrar prestanda för PHP avsevärt. Det innebär dock att ändringar i PHP-filer inte återspeglas omedelbart. Av denna anledning så är OPcache inaktiverat på Kinsta’s WordPress-iscensättningsmiljöer.
Läs mer om hur OPcache påskyndar PHP-applikationer.
Objektcache
Objektcache lagrar resultaten av databasefterfrågningar, så att nästa gång det behövs särskild databit kan detta levereras från cache utan att fråga databasen. Detta ökar PHP-exekveringstiden och minskar belastningen på din WordPress databas.
WordPress har ett inbyggt objektcache: WP_Object_Cache. Men detta objektcache förvarar bara objekt för en enda sidladdning. Syftet med cacheminnet är att se till att databasen inte efterfrågas på exakt samma sätt flera gånger under en enda sidoladdning. Emellertid används inte cachade objekt efter den enda sidoladdningen. Även om detta är en användbar funktion i WordPress är objektcache mycket kraftfullare om cache-objekten kan användas mellan flera sidladdningar.
Du kan ändra detta beteende och återanvända cachade objekt för flera sidoladdningar genom att växla från WordPress inbyggda objektcache till en extern lösning. Detta görs genom att lägga in ett skript i /wp-content/ katalogen. Det finns plugin-baserade objektcachealternativ såsom W3 Total Cache.
Våra kunder hos Kinsta kan även köpa vårt Redis-tillägg och ha det installerat tillsammans med PHP 8.0 eller 8.1. Redis är öppen-källkodad i-minnes datastrukturslagring, som används som databas, cache och meddelandeförmedlare. Kolla in vår artikel om hur du använder Redis som en beständig objektcache om du vill lära dig mer.
Sidcache
Sidcaching lagrar hela HTML:en för en sida så att efterföljande sidvisningar kan genereras utan att WordPress måste generera sidan.
När du laddar upp en WordPress-webbplats måste WordPress bearbeta ett stort antal PHP-filer och efterfrågningar till databasen ett antal gånger. För sidor som inte ständigt uppdateras är detta bortkastad ansträngning. Det är mycket effektivare att skapa varje sida bara en gång, sedan lagra den sidan och leverera till de efterföljande besökarna. Det här är vad sidcaching gör.
Fördelarna med sidcaching inkluderar:
- Mycket snabbare sidladdningar.
- Dramatiskt minskade serverbelastningar och förmågan att hantera dramatiskt mer trafik som ett resultat.
Våra servrar använder nginx fastcgi-cachemodulen för sidcachelagring, och den är inställd på att upphöra varje timme som standard. Klienter kan dock ändra sidcachens förfallodatum när som helst i MyKinsta-instrumentpanelen. Om du vill ändra sidcachens förfallotid går du till webbplatsens sida ”Verktyg”, klickar på listrutan ”Ändra” under ”Webbplatscache” och klickar på Ändra förfallodatum för cacheminnet.
I modalen ”Ändra förfallodatum för cache” väljer du den förfallotid som du vill ha och klickar på Ändra förfallodatum. Vi erbjuder alternativ från 1 timme till 7 dagar. För webbplatser som inte ändras så ofta kan det vara fördelaktigt för prestandan att ha ett längre cache-förfallodatum.
Sidcachen är konfigurerad för att fungera direkt vid installation med vanliga WordPress, BuddyPress, WooCommerce och Easy Digital Download-webbplatser. Du behöver inte göra någonting! Starta helt enkelt din WordPress-webbplats och sidcaching kommer att börja arbeta. Men anpassning kan behövas om du använder en anpassad URL-struktur eller en inställning som ligger långt utanför det vanliga WordPress.
Som standard är sid-cachelagring inaktiverat på iscensättnings-miljöer av Kinsta. I vissa fall är det användbart att aktivera cachelagring av sidor på inscensättning i testsyfte. Cachelagring av sidor för iscensättnings-platser kan aktiveras i mykinsta’s instrumentpanel.
CDN-Cache
CDN-cachning lagrar webbfiler (som JavaScript, CSS och mediefiler) på ett innehållsleveransnätverk för snabbare leverans till användare som är geografiskt avlägsna från värdserverns plats. När någon försöker nå en webbplats, levereras dessa filer från CDN istället för att behöva levereras från servern som faktiskt är värd för webbplatsen. Läs mer varför du borde använda ett CDN.
Ett innehållsleveransnätverk (CDN) erbjuder två primära fördelar:
- Det minskar de serverresurser som krävs för att ladda en webbplats. Eftersom CDN gör jobbet behöver inte webbservern göra det också.
- Det gör att resurser kan levereras från platser runt om i världen, vilket ökar webbplatsens prestanda för användare som är geografiskt avlägsna från servern som hostar webbplatsen.
Det finns två grundläggande typer av CDN: de som bara är CDN och de som erbjuder ett CDN tillsammans med säkerhetsfunktioner. Några vanliga exempel på varje är:
- Standard CDN: Stackpath, CloudFront.
- CDN plus säkerhet: Kinsta CDN (Cloudflare), Sucuri, Akamai (optionally).
Den första typen av CDN skapas genom att skapa CDN-URL-adresser som används för att komma åt webbplatsens resurser. Exakt hur detta aktiveras varierar från ett CDN till nästa. Grundidén är att webbadresser för statiska resurser kommer att ändras till CDN-URL så att resurserna dras från CDN. Ett standard-CDN cachar typiskt bara statiska filer som JS, CSS och mediefiler.
Den andra typen av CDN fungerar som en fullständig proxyserver. Detta innebär att varje begäran måste gå via leverantörens servrar innan den anländer till Kinsta’ s servrar. Detta aktiveras med hjälp av CDN-leverantörens namnservrar, så att CDN-leverantören har full kontroll över webbplatsens DNS. Detta gör det möjligt för leverantören att göra många saker som ett enkelt CDN inte kan göra, exempelvis filtrera bort trafik från dåliga IPs, erbjuda DoS / DDoS-skydd eller till och med lagra en hel sidas cache på CDNet. Vårt Kinsta CDN är ett standard-CDN som drivs av Cloudflare, en tjänst för proxyprestanda/säkerhet.
Avancerad CDN-Cachning
Om du använder en proxyserver CDN som Cloudflare eller Sucuri har du möjlighet att skapa en fullsideache på CDN. Användningen av ett CDN som Cloudflare eller Sucuri för att cacha hela sid HTML avlastar helt allt arbete från våra servrar och är en utmärkt lösning för en webbplats som förväntar sig att se en stor trafikökning.
- Sucuri konfigurerar fullsidecachen om cachenivån är inställd på ”Enabled.”
- Cloudflare kräver att sidreglerna konfigureras för att fullsidecachen ska fungera. Reglerna måste använda cache-nivån ”Cache Everything”.
Kinsta Cache-svar Rubriker
Du kan testa för att se om din sida serveras från Kinsta’s cache genom att kontrollera dina HTTP svars-sidhuvuden. Kinsta lägger till en X-Kinsta-Cache ubrik. Vid första förfrågan till en icke-cachad sida, kommer den visa MISS, som visas nedan
Vid andra förfrågningen till samma sida, kommer X-Kinsta-Cache rubriken att visa HIT, vilket betyder att den servas från cachen.
Och om du läser vår artikel om att få 100/100 i Google PageSpeed Insights kommer du känna till att Kinsta också har ytterligare optimeringar på servernivå för att automatiskt åtgärda följande varningar du kanske känner till:
- Aktivera komprimering (Kinsta har redan Gzip aktiverat på alla servrar, behöver inte aktiveras)
- Minska serverns svarstid (Kinsta är redan blixtsnabbt, redan väl inom Googles acceptabla parametrar utan några optimeringar)
- Expires-rubriker (behöver inte aktiveras eftersom Kinsta har cachning-rubriker aktiverade på servernivå)
Till exempel får vår testplats en 100/100 på PageSpeed Insights utan något cachning-plugin aktiverat. WordPress-cachen hanteras helt av Kinsta på servernivå.
Kinsta Cache-inställningar
Du kanske undrar nu över hur du kontrollerar cachen hos Kinsta. Det händer naturligtvis att du behöver rensa det, särskilt vid felsökning. Du har ett par enkla alternativ. Du kan rensa din cache från både MyKinsta-instrumentpanelen eller använda Kinsta-MU plugin.
Rensa WordPress-Cache
För att manuellt rensa hela sidcachen kan du göra det från MyKinsta-instrumentpanelen. Klicka bara på din webbplats, klicka på verktyg och klicka på ”Rensa cache” -knappen.
Som standard så är cachelagring inaktiverat i Kinsta’s WordPress-iscensättningsmiljöer. Om du vill testa sid-cachnings funktionen på en staging-webbplats kan du aktivera cachning med verktyget ”Site Cache” i mykinsta-instrumentpanelen. När cachning är aktiverad för en staging-miljö kan du använda knappen” Rensa Cache ” för att rensa cacheminnet precis som live-miljön.
Kinsta MU-Plugin
Det andra alternativet du har är att använda Kinsta-MU-pluginet. Va? Ja, tekniskt är det ett cacheplugin, men det är inte ditt typiska cacheplugin, eftersom det fungerar på en servernivå.
Som standard är Kinsta MU ett plugin installerat på varje webbplats som är hostad av oss och finns tillgänglig på vänster sida av din WordPress admin dashboard. Detta används för att intelligent rensa cacheminnet på lämpliga sidor på din webbplats. Pluginet krävs för att din webbplats ska fungera smidigt i vår miljö. Också, kom ihåg att sidcachen löper ut varje timme som standard.
I pluginet kan du också rensa cacheminnet direkt från ditt WordPress-administratörsfält. Detta skulle förmodligen vara en av de största anledningarna att använda det, eftersom du inte behöver hoppa över till MyKinsta-instrumentpanelen. Du kan göra det direkt från din webbplats.
Det låter dig också konfigurera anpassade cachningsregler. Beroende på webbplatsens konfiguration kan det behövas ytterligare cachningsregler. Du kan lägga till anpassade sökvägar för att rensa när din webbplats är uppdaterad.
Du kan även nå ut till vår kundsupport om du behöver hjälp med en specifik sida eller URL exkluderar från cache.
Kinstas iscensättnings-miljö
Som standard har iscensättnings-miljöer på Kinsta sid-cachelagringen inaktiverad. Detta gör det enkelt att utveckla och felsöka din WordPress-webbplats utan att behöva rensa cacheminnet manuellt efter varje redigering. I vissa fall kanske du vill aktivera sidcachelagringen på en iscensättnings-miljö för att köra ett korrekt hastighetstest för en cachelagrad sida utan att omvandla din webbplats till live.
Om du vill aktivera cachelagring av sidor på en iscensättnings-miljö navigerar du till Webbplatser > Verktyg i MyKinsta och klickar på knappen ”Aktivera cache”. När cachelagring är aktiverat på iscensättningen kan du använda knappen ”Rensa cache” för att rensa cachen.
Kinsta Cache-Analys
Du kan ta en djupdykning i hur bra din WordPress webbplats cachas i MyKinsta Analytics. Cache-komponenten låter dig se statusen för varje förfrågan, oavsett om det var en HIT, BYPASS, MISS eller EXPIRED. Du kan filtrera data efter senaste 24 timmar, 7 dagar eller 30 dagar.
Cache-komponenten ger dig en snabb blick över ditt cachning-förhållande. Ju fler förfrågningar sidan servar från cache desto bättre.
Topp-cachebypass-sektionen låter dig se vilka förfrågningar som inte serveras från cacheminnet. Vanligtvis kan dessa innehålla CRON-jobb, admin-ajax-förfrågningar, kassan för e-handel, frågesträngar och UTM-parametrar etc.
Caching 404 Pages
404 sidor kan vara mycket resursintensiva. Många WordPress-sajter, särskilt stora medlemskapssidor, genererar fler 404 fel än du kanske tror. Kanske har du ändrat platsen för en sida och glömt att lägga till en omdirigering, eller du har en felaktig länk till något du delade på sociala medier. Med andra ord finns det många saker som gör att en besökare hamnar på din 404-sida. Dessa sidor tenderar också att ha frågor om att ta upp alternativa sökresultat som är träffar i databasen.
För att säkerställa bättre prestanda på din WordPress-sajt, lagrar Kinsta 404 sidor i 15 minuter. Header-värdet X-Kinsta-Cache kommer att visa en HIT, vilket betyder att den serveras från cacheminnet. Om du skapar en sida som tidigare var en 404, slängs cachen omedelbart.
Vårt MyKinsta analytics verktygkan hjälpa dig att bestämma exakt hur mycket 404 fel som inträffar på din webbplats.
Det är viktigt att klargöra att vi inte lagrar alla 404 förfrågningar. Det finns två olika typer: de från PHP-sidor som landar på din 404-sida, och de från saknade filer eller bilder som inte längre existerar eller har flyttats. Vi lagrar 404 sidor, 404 förfrågningar till saknade filer och bilder hanteras annorlunda.
Därför kan du använda ”Top 404-fel” för att bättre avgöra var och vad som orsakar dessa.
Du kan också kontrollera 404-fel i Googles sökkonsol eller installera en plugin från tredjepart som Redirection som loggar 404 fel. Kom ihåg att plugins som dessa också påverkar prestanda. Det är mycket bättre att förlita sig på ett servernivåverktyg.
Skapa en enkel 404-mall som undviker att fråga databasen vidare om möjligt.
POST-förfrågningar BYPASS-lagring
Vi vill att vår analys- och cachestatistik ska vara så exakt som möjligt. Det är viktigt eftersom du, när du felsöker prestandafrågor, normalt tittar på ditt totala HIT-förhållande, som du vill ska vara så hög som möjligt. Därför ingår POST-förfrågningar i vår rapportering.
POST-förfrågningar kan inte bli lagrade, förutom några högkvalitativa specialiserade setups. Headervärdet X-Kinsta-Cache kommer att visa BYPASS för dessa förfrågningar. Dessa ska inte förväxlas med blogginlägg eller någon typ av WordPress-inlägg (som kan cachelagras). En POST-begäran används för att skicka data till servern. Exempelvis lagras de data som skickas när du skickar ett webbformulär i begärandetexten i HTTP-begärandet.
Sammanfattning
Förhoppningsvis, förstår du nu lite mer om WordPress-cache och de fyra olika typerna som du kommer att stöta på regelbundet här på Kinsta: bytecode cachning, objektcaching, sidcaching och CDN cachning.
Om du är trött på att pyssla med typiska WordPress-cacheplugin och helt enkelt vill ha en snabb sida direkt rekommenderar vi att du testar Kinsta! Det finns en anledning att vi har fått ”toppnivå” -status i WordPress-prestanda 4 år i rad av ReviewSignal. Och det beror på att våra servrar är finjusterade ovanpå Google Cloud Plattform för blixtsnabba laddningstider. Du kommer inte bli besviken på vår prestation.
Brian har stor passion för WordPress och har använt det i över ett årtionde, han har till och med utvecklat ett par premium-plugins. Brian gillar att blogga, kolla filmer och hiking. Ta kontakt med Brian via Twitter.
Lämna ett svar