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 7, 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 2020” 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,

WordPress laddningstider hos Kinsta

WordPress laddningstider hos Kinsta

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.

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.2, 7.3 och 7.4 (och kommer aktivera det i nyare versioner av PHP allteftersom de släpps på vår plattform).

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 är OPcache inaktiverat på Kinsta-test-webbplatser.

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 7.2, 7.3 eller 7.4. 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:

Här på Kinsta använder våra servrar nginx fastcgi cache module för sidcachning. Och det är inställt på att löpa ut varje timme som standard. Kunder kan dock kontakta oss om de behöver öka denna varaktighet. För sajter som inte ändras så ofta, kan det, om man pratar om prestanda, vara fördelaktigt att använda en tidsutlöpande cache som är längre.

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.

Liksom bytecode cachning (OPcache) är sidcaching helt avaktiverad på Kinsta-test-webbplatser.

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 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:

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. Vårt Kinsta CDN är ett standard-CDN som drivs av KeyCDN.

Den andra typen av CDN fungerar som en full proxyserver. Vad det innebär är att varje förfrågan måste gå över leverantörens servrar innan de kommer till Kinstas servrar. Detta aktiveras genom att använda CDN-leverantörens namnservrar, så att CDN-leverantören har fullständig kontroll över webbplatsens DNS. Detta gör det möjligt för leverantören att göra en hel del saker som ett enkelt CDN inte kan göra, till exempel filtrera ut trafik från dåliga IP-adresser, erbjuda DoS / DDoS-skydd, eller till och med lagra en fullsidecache på CDN.

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.

Kinsta Cache-svar Rubriker

Du kan testa om din sida servas from Kinsta cachen genom att titta på dina HTTP-svar-rubriker. 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

Miss cache-rubrik

Miss cache-rubrik

Vid andra förfrågningen till samma sida, kommer X-Kinsta-Cache rubriken att visa HIT, vilket betyder att den servas från cachen.

Hit cache-rubrik

Hit cache-rubrik

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:

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å.

PageSpeed Insights

PageSpeed Insights

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.

Rensa WordPress cache

Rensa WordPress cache

Som standard är caching inaktiverad på Kinsta staging-miljö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.

Kämpar du med driftstopp och WordPress-problem? Kinsta är hosting-lösningen som är utformad för att spara tid! Kolla in våra funktioner

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.

Kinsta MU-plugin

Kinsta MU-plugin

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.

Rensa cache från WordPress verktygsfält

Rensa cache från WordPress verktygsfält

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.

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.

Kinsta cache-komponent

Kinsta cache-komponent

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.

Kinsta cache-komponentdiagram

Kinsta cache-komponentdiagram

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.

WordPress Topp-cache-bypass

WordPress Topp-cache-bypass

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.

404 error breakdown

404 error breakdown

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.

404 förfrågningssida lagrad

404 förfrågningssida lagrad

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.

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.


Om du tyckte om den här artikeln, då kommer du att älska Kinsta´s hosting-plattform. Effektivisera din hemsida och få support dygnet runt från vårt rutinerade team på WordPress. Vår Google Cloud-drivna infrastruktur fokuserar på auto-skalning, prestanda och säkerhet. Lås oss visa dig skillnaden med Kinsta! Kolla in våra paket