Vi har publicerat många handledningar om optimering av WordPress hastighet genom åren med sätt att optimera och snabba på WordPress. Men ibland kan det vara förvirrande att försöka hitta allt du behöver på ett ställe. Så idag kommer vi att dela allt vit vet med om att turboladda WordPress, med över 15 års erfarenhet och svåra läxor, allt i en ultimat guide. Oavsett om du just börjat använda WordPress eller är en erfaren utvecklare, lovar vi att du hittar något användbart i det här färdledare!
Över 43.5% av webben drivs nu av WordPress. Även om detta är fantastiskt betyder det också att det finns tusentals olika teman, plugin och teknik som alla måste samexistera. För den dagliga WordPress-användaren kan detta snabbt bli en mardröm när deras webbplats börjar få prestandaproblem och de vet inte varför eller ens var de ska felsöka.
I vår tidigare guide om sidhastighet gick vi över en hel del grunder för prestanda och hur det kan få stor inverkan på framgången för ditt företag. Men idag dyker vi ner i tillämpliga steg du kan ta just nu för att se förbättringar på dina egna WordPress-webbplatser. Vi delar också några resurser som har varit ovärderliga för oss.
WordPress Webbplatstyper: Statisk eller Dynamisk
Innan vi dyker in i optimeringarna är det viktigt att förstå att inte alla WordPress-webbplatser är lika. Det är därför många användare har problem, eftersom man inte kan hantera varje problem på samma sätt. Vi ger alltid WordPress-webbplatser en klassificering: statisk eller dynamisk. Så låt oss först utforska skillnaderna mellan dessa två typer av webbplatser.
Mest Statiska Webbplatser
Statiska webbplatser skulle typiskt betyda webbplatser som bloggar, småföretag, nyhetswebbplatser, personlig information, webbplatser för fotografering etc. Med statisk mening menar vi att data på dessa WordPress-webbplatser inte ändras särskilt ofta (kanske ett par gånger om dagen). Även större delen av vår Kinsta-webbplats skulle anses vara en statisk webbplats.
Detta blir oerhört viktigt eftersom många av förfrågningarna kan serveras direkt från cacheminnet på servern vid blixtsnabba hastigheter! Oroa dig inte; vi dyker in i ämnet cachning längre fram. Det betyder att de kommer att ha färre databasförfrågningar och inte så många resurser som behövs för att uppnå Google-prestanda.
Högst Dynamiska Webbplatser
På andra sidan av myntet har vi mycket dynamiska platser. Dessa inkluderar webbplatser som e-handel (WooCommerce eller Easy Digital Downloads), community, medlemskap, forum (bbPress eller BuddyPress) och lärplattformar (LMS). Med dynamisk menar vi att data på dessa WordPress-webbplatser ändras ofta (servertransaktioner äger rum varannan minut eller till och med varje sekund). Det betyder att inte alla förfrågningar till servern kan serveras direkt från cacheminnet och kräver ytterligare serverresurser och databasförfrågningar.
Dessa webbplatser har också vanligtvis ett stort antal samtidiga besökare och sessioner. På en informations- eller företags-WordPress-webbplats som är mestadels statisk kan en besökare stanna i fem eller 10 minuter tills de hittar vad de behöver (och det här är ett högt antal, vanligtvis är avvisningsfrekvensen mycket högre). På dynamiska platser händer motsatsen. Besökare brukar komma till platsen för att engagera sig med någonting eller någon. Om de läser en onlinekurs är det inte ovanligt för dem att stanna i timmar.
Du kan se var detta är på väg. De samtidiga besökarna som är anslutna till din WordPress-värd läggs snabbt ihop till en enorm mängd. För att göra det värre har du sedan ett stort antal samtidiga besökare ovanpå ett problem med ”icke-cachebart innehåll”.
Välj högpresterande WordPress-Hosting
En WordPress-värd är ett företag som lagrar alla dina webbplatsdata. Du registrerar dig för en plan och alla dina bilder, innehåll, videoklipp etc. finns på en server som sitter i värdens datacenter. WordPress-värden ger dig ett enkelt sätt att komma åt data, hantera det och skicka det till dina besökare. Ganska enkelt eller hur? Tja, inte riktigt.
Det finns tre väldigt olika typer av WordPress-hosting som du kommer att stöta på på webben. Låt oss dyka in i för och nackdelar med varje. Det är viktigt att du väljer rätt från början, annars kommer du helt enkelt att orsaka huvudvärk och bortkastad tid.
1. Delad WordPress-Hosting
Den första och mest populära typen av WordPress-hosting är vad vi kallar ”delad hosting.” Dessa inkluderar de största värdarna inom branschen, såsom EIG-företag som Bluehost och HostGator, liksom leverantörer som Siteground, GoDaddy, Media Temple, OVH, GreenGeeks och InMotion Hosting. De brukar använda cPanel, och genomsnittskunderna betalar vanligen mellan $ 3 och $ 25 per månad.
Någon som använder denna typ av värd kommer någon gång att uppleva långsamhet, det är bara en fråga om tid. Varför? Eftersom gemensamma värdar tenderar att överbelasta sina servrar, vilket i sin tur kan påverka webbplatsens prestanda. Webbplatsavstängningar eller att se frekventa 500 fel är vanliga saker som du kommer att uppleva eftersom de måste sätta gränser för allt och konsolidera resurser för att överleva. Eller ännu värre, driftstopp på webbplatsen. Även om du inte vet det, sitter din WordPress-webbplats troligtvis på samma server som 200 + andra människor. Eventuella problem som dyker upp med andra webbplatser kan spilla över till din webbplats.
Oavsett hur du räknar, efter utgifter, generar inte $3 per månad några intäkter för webbhotellet. Speciellt när du ansluter support till det. En supportbiljett och de går redan back. Det sätt på vilket de tjänar mycket av sina pengar är på merförsäljning och dolda avgifter. Denna merförsäljning inkluderar saker som migreringar, domänregistreringar, SSL-certifikat etc. En annan vanlig taktik är att ge enorma registreringsrabatter. Men när kontraktet ska förnyas får du den riktiga fakturan.
De flesta av dessa värdar erbjuder vad de kallar ”obegränsade resurser”-plan. Ni har nog alla sett det här. Tja, det finns ingen sådan sak i den verkliga världen som obegränsade resurser. Vilka värdar gör bakom kulisserna är att bromsa kunder som använder mycket resurser. Detta slutar i sin tur med arga klienter som lämnar hostingen, vilket gör plats för fler kunder som inte använder mycket resurser. I slutändan har du en ond cykel av webbhotell som driver billiga planer och registrerar kunder som de hoppas inte kommer att använda mycket resurser och kommer att köpa tilläggsprodukter.
Kundtjänst och support med delad hosting är nästan alltid undermålig på grund av den stora volymen av webbplatser vs supportrepresentanter. Delade värdar måste sprida sig mycket tunna för att ens göra en vinst och det leder vanligtvis till en obehaglig upplevelse för kunden.
Försäkra dig om att kolla in en fördjupande artikel av vår ekonomidirektör angående de chockerand sanningarna bakom hur billig WordPress-hosting egentligen fungerar.
2. Gör-det-själv VPS WordPress-Hosting
Den andra typen av WordPress-värd är DIY VPS eller ”Gör det själv på en virtuell privat server.” Denna grupp består vanligen av startups och användare med lite mer utvecklings-, serverhanterings- och WordPress-erfarenhet. De är DIY-folket. Dessa människor försöker vanligtvis fortfarande spara pengar, men de är också vanligtvis oroade över prestanda och inser dess betydelse för framgången med sin verksamhet. Vanligt upplägg kan innefatta att använda en tredje part VPS-leverantör som Digital Ocean, Linode eller Vultr; tillsammans med ett verktyg som ServerPilot för att hantera det lättare.
En liten VPS från DigitalOcean startar på $5 per månad och den populära planen på ServerPilot börjar på $10 per månad. Så beroende på hur du har lagt upp det kan du ha en kostnad på mellan $5 till $15 eller mer per månad. DIY-tillvägagångssättet kan sänka kostnaderna, men det betyder också att du är ansvarig om något går sönder och för att optimera din server för prestanda.
DIY-tillvägagångssättet kan vara bra, men det kan också slå tillbaka på dig om du inte är försiktig. Gå inte denna väg om du inte är tekniskt kunnig eller bara för att du vill fiffla! Din tid är värt pengar och du borde spendera den på att odla din verksamhet.
3. Managed WordPress-Hosting
Den tredje typen av hosting är det vi erbjuder hos Kinsta och det är managed WordPress-hosting. Dessa typer av värdar hanterar alla back-end-serverrelaterade uppgifter åt dig, tillsammans med att ge support när du behöver det. De är vanligtvis finjusterade för att fungera med WordPress och innehåller vanligtvis funktioner som enklicks-testmiljöer och automatiska säkerhetskopior. Deras supportteam kommer att vara mer kunniga när det gäller att kunna CMS eftersom de är inriktade på en plattform på daglig basis.
Om du vill spara tid är Managed WordPress hosting rätt väg att gå! 👍
Planer för managed WordPress-hosting varierar vanligtvis från $25 till $150 per månad eller mer beroende på storleken på din webbplats och dina behov. Stora företag som jQuery, Intuit, Plesk, Dyn, Nginx och till och med Vita huset använder alla WordPress som värd för deras hemsida. Vissa populära managed WordPress-värdar du är förmodligen bekant med, eller kanske även för närvarande använder inkluderar WP Engine, Flywheel, Pressable, Media Temple, Pressidium och Pagely.
Kinsta Tar en Annorlunda Approach
Kinsta tar dock WordPress-hosting till nästa nivå. Vår värdplattform omfattas inte av någon av de traditionella värdkategorierna. Hela vår infrastruktur är byggd på Google Cloud Platform och skiljer sig från traditionell delad, VPS eller dedikerad infrastruktur. Detta gör den till en av de snabbaste tillgängliga hosting-lösningarna på WordPress.
Varje WordPress-webbplats på vår plattform körs i en isolerad mjukvarucontainer som innehåller alla programresurser som krävs för att köra webbplatsen (Linux, Nginx, PHP, MySQL). Det innebär att programvaran som kör varje webbplats är helt privat och delas inte ens mellan dina egna webbplatser.
Varje webbplats-container körs på virtuella datorer i ett av flera GC-datacenter, och utnyttjar Google Cloud plattformens premiumnivånätverk för optimerad dataöverföring med låg latens. Varje maskin har upp till 96 cpu: er och hundratals GB RAM. Maskinvaruresurser (RAM/CPU) allokeras automatiskt till varje webbplats-container av våra virtuella maskiner efter behov.
Till skillnad från andra hostar som använder Google Cloud plattformens virtuella datorer för allmänna ändamål gör vi beräkningsoptimerade virtuella datorer för C2 tillgängliga för alla våra kunder i regioner som stöds. Google Clouds C2-maskiner har den senaste generationens Intel Xeon-skalbara processorer som kan upprätthålla 3,8 GHz turbohastigheter i alla kärnor. C2-maskiner är populära för CPU-tunga användningsområden som exempelvis vetenskaplig modellering och maskininlärning, men de är även bra för högpresterande WordPress-hosting. Under vår testning, fann vi att migreringen av en WordPress-webbplats från en allmän VM till en C2 VM resulterade i 2x ökning av prestanda!
Thank you @kinsta for handling today's traffic spike without issue. It's comforting to know your site can handle surges. #webperf #webhosting #wordpress pic.twitter.com/fplO87LIu0
— Adam Lundeen (@adam_lundeen_) January 29, 2019
Varje år släpper Review Signal sina WordPress-värd prestanda-måttstock, och vi är stolta över att Kinsta i fem år i rad har visat sig vara det bästa företaget på alla nivåer! Och inte bara på en eller två av våra planer, utan varje plan, från Starter hela vägen upp till Enterprise. 🤘
Vi har inte heller supportansvariga på nivå 1 eller nivå 2. Vårt hela supportteam består av WordPress-utvecklare och Linux-värdingenjörer, varav många har hanterat sina egna servrar, skapat teman och plugin och bidragit till WP-kärnan. Detta garanterar att du får expertråd från någon som aktivt använder och utvecklar med WordPress.
Du får chatta med samma supportteammedlemmar som backar våra Fortune 500 och företagskunder. Vi är så kräsna om kvaliteten på vårt supportteam att vi bara anlitar mindre än 1 % av de sökande som ansöker. Du kommer inte hitta bättre stöd någon annanstans!
För att lära dig mer om varför du ska välja Kinsta som managed WordPress-värd, läs varför oss – hur Kinsta är annorlunda. Men oberoende av vem du väljer som webbhotell, bör du alltid leta efter följande serverfunktioner för att säkerställa att din webbplats körs så fort som möjligt.
PHP 7 eller Högre för Bästa Prestanda
PHP är ett serverskriptings- och programmeringsspråk med öppen källkod som främst används för webbutveckling. Huvuddelen av den centrala WordPress-programvaran är skrivet i PHP, tillsammans med dina plugin och teman, vilket gör PHP till ett mycket viktigt språk för WordPress-communityt. Du bör se till att din WordPress-värd erbjuder minst PHP 7 eller högre.
Din host kommer att erbjuda olika versioner av PHP på din server, och den nyare versionen PHP 7.3 erbjuder enorma prestandaförbättringar.
Faktum är att i våra senaste PHP-riktmärkestester, kom vi fram till att PHP 7.3 kan hantera 3 gånger så många begäranden per sekund som PHP 5.6! PHP 7.3 är även i genomsnitt 9% snabbare än PHP 7.2. Detta kan även påverka responsiviteten på din WordPress-administratörspanel.
Snabbare hastigheter plus förbättrad säkerhet är anledningen till att Kinsta alltid erbjuder de senaste versionerna av PHP. Du kan ändra PHP-versioner med ett enda klick.
Och se upp för WordPress-värdar som erbjuder HHVM som ett alternativ till PHP. HHVM är inte längre en passande lösning för WordPress-hosting.
Välj en värd som använder Nginx
Bakom kulisserna använder varje WordPress-värd en webbserver för att driva dina WordPress-webbplatser. De vanligaste valen är Nginx och Apache.
Vi rekommenderar starkt att du väljer en värd som använder Nginx på grund av dess rötter i prestationsoptimering. Nginx överträffar ofta andra populära webbservrar i benchmarktester, särskilt i situationer med statiskt innehåll eller höga samtidiga förfrågningar. Därför använder Kinsta Nginx.
Några högprofilerade företag som använder Nginx inkluderar Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel, och många fler. (källa)
Enligt W3Techs driver Apache 44,0% av alla webbplatser, vilket gör det till det mest använda alternativet. Men om du tittar på den mest populära webbservern bland högtrafikwebbplatser (topp 10 000), har Nginx 41,9% av dem, medan Apache endast driver 18,1%. Den används av några av de mest resurskrävande webbplatser som finns, inklusive Netflix, NASA och även WordPress.com.
Läs mer i vår webbserver-showdown: Nginx vs Apache.
Din Värds Nätverk Spelar Roll
När du väljer en WordPress-värd kanske du inte ens tänker på att fråga eller undersöka vilket nätverk de använder, men du borde göra det. Nätverket kan ha stor inverkan på webbplatsens prestanda och till och med hur snabbt din WordPress-instrumentpanel svarar. Många värdar utelämnar detta från sin marknadsföring eftersom de väljer det billigaste nätverket för att minska kostnaderna.
Här är några frågor du borde ställa:
- Vilka nätverk överför du data över? Är majoriteten av det över offentliga ISP-nätverk eller privata infrastrukturer som Google eller Microsoft? Dessa stora leverantörer har nätverk som är byggda och optimerade för låg latens och hastighet. De har även sina egna internetkablar under havet!
- Är de nätverk du använder överflödiga? Vad händer om en kabel av misstag skärs av? Detta händer oftare än du tror.
Under år 2017 annonserade Google sitt standardnätverk, vilket är ett långsammare nätverk men till en lägre kostnad. På Kinsta använder vi dess premiumnivånätverk för alla våra planer. Medan det här är en extra kostnad för oss, garanterar vi att du får blixtsnabba hastigheter.
Enligt Google uppnår premiumnätverket en förbättrad nätverksprestanda genom att minska resans varaktighet på det offentliga internetet; datapaket ankommer (och lämnar) Googles nätverk så nära användaren som möjligt och reser sedan på Googles ryggrad innan de kommer till VM. Standardnivån levererar utgående trafik från GCP till Internet via offentligt nät (ISP) istället för Googles nätverk.
För att uttrycka det på ett annat sätt som kan vara lättare att förstå:
- Premiumpaket spenderar mer tid på Googles nätverk, med mindre studsar och presterar därmed bättre (men kostar mer).
- Standardpaket spenderar mindre tid på Googles nätverk, och mer tid att bli omkringkastade på offentliga nätverk och presterar därmed sämre (men kostar mindre).
Hur stor påverkan har detta? Tja, för data som reser över kontinenter, är deras premiumnivånätverk ungefär 41 % snabbare i genomsnitt än standardnivånätverk. För data som reser till en närliggande region (samma kontinent), är premium-nivån cirka 8 % snabbare. Medan nätverksarbete bara utgör en bråkdel av dina totala sidladdningstider, spelar varje millisekund roll!
Redundans är också en viktig faktor, och det är därför som Google använder minst tre oberoende banor (N+2-redundans) mellan två platser i Googles nätverk, vilket gör att trafiken fortsätter att flöda mellan platserna, även vid störningar.
Som du förmodligen kan se händer för tillfället mycket bakom kulisserna när det gäller nätverk. Se till att din WordPress-värd använder ett ansett nätverk och inte väljer de lägre nivåerna för att minska kostnaderna.
HTTP/2 är ett Måste
HTTP/2 är ett webbprotokoll som släpptes 2015 som utformades för att snabba på leveransen av webbplatser. På grund av webbläsarstöd krävs det HTTPS (SSL). Om din WordPress-värd inte stöder HTTP/2 bör du börja leta efter en ny leverantör. I och med att hela webben flyttar till HTTPS är det inte längre bara en bra funktion att ha; det är en nödvändighet.
Förbättringen av prestanda med HTTP/2 beror på olika orsaker, till exempel stöd för bättre multiplexering, parallellitet, HPACK-komprimering med Huffman-kodning, ALPN-förlängningen och serverpush. Det var ganska mycket TLS-overhead när det gällde att driva HTTPS, men det är nu mycket mindre tack vare HTTP/2 och TLS 1.3. Kinsta stöder TLS 1.3 på alla våra servrar och vår Kinsta CDN.
En annan stor seger med HTTP/2 är att med de flesta WordPress-webbplatser behöver du inte längre oroa dig för concatentation (kombinering av filer) eller domain sharding. Dessa är nu föråldrade optimeringar.
Välj en server nära dina besökare
En av de allra första sakerna du bör göra när du hostar din WordPress-webbplats är att avgöra var majoriteten av dina besökare eller kunder kommer ifrån. Varför är detta viktigt? Eftersom den plats där du är hostar din webbplats spelar en viktig faktor för att bestämma din övergripande nätverkslatens och TTFB. Det påverkar också din SFTP-hastighet och WordPress adminkontrollpanels responsivitet.
Nätverkslatens: Detta avser tid och eller fördröjning som är inblandad i överföringen av data över ett nätverk. Med andra ord, hur lång tid det tar för ett paket av data att gå från en punkt till en annan. Numera mäts det vanligtvis i millisekunder; Det kan dock vara sekunder beroende på nätverket. Ju närmare noll desto bättre.
Kolla in vårt djupgående inlägg om nätverkslatens.
TTFB: Detta står för tid till första byte. För att uttrycka det enkelt är det här ett mått på hur länge webbläsaren måste vänta innan den mottar sin första bit av data från servern. Ju längre tid det tar att få den data, desto längre tid tar det att visa din sida. Återigen, ju närmare noll desto bättre.
Kolla in vårt djupgående inlägg på TTFB.
Vi kommer inte att tråka ut dig med alla tekniska detaljer i det här inlägget. Allt du behöver veta är att du vill att din nätverkslatens och TTFB ska vara så låga som möjligt. Ett av de enklaste sätten att uppnå detta är att välja en server som är närmast din besökare. Du kan bestämma den bästa platsen genom att följa tipsen nedan.
Tips 1 – Kolla Google Analytics för dina besökares geografiska plats
En av de allra första sakerna du kan göra är att titta på de geografiska platserna för dina besökare i Google Analytics. Du hittar det här under ”Målgrupp → Geo → Plats”.
I det här exemplet nedan kan du se att över 90 % av trafiken kommer från USA. Så i de flesta fall skulle du vilja placera din WordPress-webbplats på en server i USA. Du kan också filtrera ner data ännu längre till städer. Detta är särskilt viktigt om du är ett lokalt företag. Men vanligtvis rekommenderar vi en central plats som Iowa, USA.
Tips 2 – Kolla E-handelsdata
Om du driver en e-handelsbutik, se till att du också kontrollerar var dina kunder kommer ifrån. Det här är förstås hur du genererar intäkter, så det här är dina viktigaste besökare. Detta bör sammanfalla med din trafik ovanför; Detta är emellertid inte alltid fallet. Om du har e-handelsdatainställningar eller mål i Google Analytics kan du enkelt överlappa den informationen ovanpå geolokaliseringsdata för att göra ett mer informerat beslut. Eller kontrollera platsinformation som finns lagrad i din e-handelsplattforms databas.
Tips 3 – Gör ett snabbt Latenstest
Det finns många praktiska gratisverktyg där ute för att mäta latens från din nuvarande plats för olika molnleverantörer. Detta kan hjälpa dig att snabbt utvärdera vilken region som kan vara det bästa valet för din webbplats.
- GCP Ping (mäter latens till Google Cloud Platform-regioner, inklusive Kinsta-servrar)
- CloudPing.info (mäter latens till Amazon Web Services regioner)
- Azure Latency Test (mäter latens till Azurregioner)
I det här exemplet nedan kan vi se att Oregon, USA (us-west1) är det snabbaste från där vi befinner oss. Om du betjänar kunder över hela USA kan det vara bättre att välja Iowa, USA (us-central1) för att garantera låg latens för besökare från både väst och östkusten.
Här på Kinsta, erbjuder vi 37 olika datacenter över hela jordklotet. Du kan enkelt välja en plats som kommer ha både låg latens och låg TTFB! Detta hjälper dig också att reducera nätverkshopp.
Ytterligare sätt att reducera latens och TTFB
Utöver att välja en närmare serverplats, här är några andra sätt att minska latensen.
- Implementera cachning på din WordPress-webbplats. I våra test reducerade cachning vår TTFB med en hel del 90 %!
- Använd ett innehållsleveransnätverk (CDN) för att betjäna cachade tillgångar från POPs runt om i världen. Detta hjälper till att negera nätverkslatensen för besökare som kanske inte befinner sig nära din värdserver.
- Dra fördel av HTTP/2-protokollet för att minimera antalet rundresor, tack vare parallellisering. HTTP/2 är aktiverat på alla Kinsta-servrar.
- Minska antalet externa HTTP-förfrågningar. Var och en av dessa kan ha sin egen extra latens baserat på deras server.
- DNS spelar en roll i TTFB, så du bör använda en premium DNS-leverantör med snabba uppslagstider.
- Använd prefetch och prerender för att utföra uppgifter bakom kulisserna medan sidan laddas.
Oroa dig inte; Vi täcker alla rekommendationer som nämns ovan längre fram i det här inlägget.
SFTP-hastigheter och WordPress Adminkontrollpanel
Dina besökare och kunder ska alltid vara din prioritet. Men en annan aspekt av prestanda som många inte pratar om är hur vissa av dessa beslut påverkar ditt dagliga arbete. Den datacenterplats du väljer har en inverkan på hur snabbt din SFTP-hämtning och uppladdningshastighet (överföring av filer med en FTP-klient) är samt hur snabb din WordPress adminkontrollpanel är.
Så samtidigt som du vill se till att välja en plats som är bäst för dina besökare, bör du också komma ihåg att det kan påverka webbplatshanteringen. Uppgifter som att ladda upp filer till WordPress-mediebiblioteket kommer att gå snabbare när din webbplats är hostad på ett datacenter närmare dig.
Vi hör konsekvent från kunder hos Kinsta att de är förvånade över hur mycket snabbare deras adminkontrollpanel är med oss. Det finns en mängd faktorer som påverkar detta, men att ha 37 olika datacenter är en stor en! Välj en plats som fungerar både för dina besökare och för dig! När allt kommer omkring är du den som förmodligen kommer att spendera tusentals timmar som arbetar på din webbplats.
Premium DNS är bättre än gratis DNS
DNS, kort för Domain Name System, är en av de vanligaste men mest missförstådda komponenterna i webblandskapet. För att uttrycka det enkelt hjälper DNS till att styra trafik på Internet genom att ansluta domännamn med faktiska webbservrar. I grund och botten tar det en människo-vänlig term – ett domännamn som kinsta.com – och översätter det till en datorvänlig server-IP-adress – som 216.58.217.206.
Du kan hitta både gratis DNS och premium DNS. Alla Kinsta-kunder får tillgång till premium-DNS via Amazon Route 53. Och i allmänhet tror vi att premium DNS är en nödvändighet i dagens värld.
En stor anledning till att välja premium DNS är snabbhet och pålitlighet. Att leta upp DNS-poster och styra trafik tar tid, även om det bara handlar om millisekunder.
Vanligtvis är den fria DNS som du får från din domännamnregistrator relativt långsam, medan premium DNS ofta erbjuder bättre prestanda. Till exempel, i våra tester fann vi att den fria NameCheap DNS var 33 % långsammare än Amazon Route 53 Premium DNS. Dessutom kan premium DNS erbjuda bättre säkerhet och tillgänglighet, särskilt när du är under DDoS-attack.
Du kan använda ett verktyg som SolveDNS hastighetstest för att kontrollera dina DNS-uppslagstider. DNSPerf ger också utmärkt prestandadata på alla tops DNS-leverantörer.
För en bra mellanklass mellan den kostnadsfria DNS som tillhandahålls av din domänregistrator och premium DNS, är Cloudflare DNS en gratistjänst som fortfarande erbjuder många av fördelarna med premium DNS. Och de är blixtsnabba med under 20 ms. genomsnittliga svarstider runt om i världen (se nedan).
Cloudflare-integreringen inkluderas i alla Kinsta-planer. Om du främst tjänar besökare i USA är DNS Made Easy en annan jättebra premium-DNS-leverantör som du kanske vill kolla in. De har rykte om sig för att ge några av de bästa DNS-upptidstiderna under det senaste decenniet.
Under de senaste 30 dagarna visar DNSPerf följande driftstid från dessa leverantörer:
- DNS Made Easy: 99,99% vilket motsvarar 4m 23,0s månatlig driftstopp.
- Amazon Route 53: 99,88% vilket motsvarar 52m 35,7s månatlig driftstopp.
- Cloudflare: 99,85% vilket motsvarar 1h 5m 44,6s månatlig driftstopp.
Spelar driftstoppstid så stor roll med DNS-leverantörer? Svaret på detta är verkligen ja och nej. DNS cachas vanligtvis med Internetleverantörer med hjälp av tiden för live-värde (TTL) på DNS-posten. Om en DNS-leverantör går ner i 10 minuter, kommer du därför sannolikt inte att märka något. Driftstopp spelar dock roll om leverantören konsekvent har längre och frekventa driftstopp, eller om din ISP och DNS-poster båda använder mycket låga TTL-värden.
Ditt WordPress-tema spelar roll
Alla älskar ett helt nytt WordPress-tema, men var försiktig innan du väljer det med alla nya glänsande funktioner. Först bör du kolla in vår artikel om skillnaderna när det gäller gratis vs betalteman. När det gäller prestanda, har varje element du ser i ett tema en viss inverkan på den totala hastigheten på din webbplats. Och tyvärr, med tusentals teman ute i det vilda finns det både goda och dåliga.
Så hur ska du kunna veta vilket du ska välja? Vi rekommenderar att du väljer ett med ett av följande två alternativ:
- Ett snabbt lätt WordPress-tema som är byggt med endast de funktioner du behöver, inget mer.
- Ett mer funktionsrikt WordPress-tema, men du kan inaktivera funktioner som inte används.
Saker som Google Fonts, Font Awesome ikoner, sliders, gallerier, video- och parallaxskript etc. Det här är bara några av de många saker som du bör kunna stänga av om du inte använder dem. Du kommer inte vilja försöka justera dessa manuellt i efterhand. Och vi kommer inte visa dig 50 olika sätt att ta bort saker. Istället bör du börja med eller byta till ett WordPress-tema som är antingen lätt från början eller ger dig dessa alternativ.
Nedan följer ett par WordPress-teman som vi rekommenderar och som inte kan gå fel! Lita på oss, du kommer att tacka oss senare. 😉
Varje tema som nämns nedan är fullt kompatibelt WooCommerce och Easy Digital Downloads, WPML, BuddyPress och bbPress. Vi kör några hastighetsprov med varje tema med följande konfiguration:
- Hostad på Kinsta, kör WordPress 4.9.8
- PHP 7.3 och SSL (HTTPS)
- Kinsta CDN
- Imagify användes för att automatiskt komprimera bilder.
GeneratePress
GeneratePress är ett snabbt, lättviktigt (mindre än 1MB-zippat), mobil-responsivt WordPress-tema byggt med hastighet, SEO och användbarhet i åtanke. Byggd av Tom Usborne, en utvecklare från Kanada. Det är ofta uppdaterat och välskött. Även några Kinsta-teammedlemmar använder GeneratePress för sina projekt.
Det finns både en fri och premium version tillgänglig. Om du tittar på WordPress-Repository, har den fria versionen för närvarande över 200 000 aktiva installationer, 2+ miljoner nedladdningar och en imponerande 5 av 5-stjärnklassificering (över 850 personer har gett det 5 stjärnor).
En av de fantastiska sakerna med GeneratePress är att alla alternativ använder den inbyggda WordPress Customizer, vilket innebär att du kan se varje ändring du gör omedelbart innan du trycker på publicera-knappen. Det betyder också att du inte behöver lära dig en ny temakontrollpanel.
Hur snabbt är det? Vi gjorde en ny installation av GeneratePress, körde fem hastighetsprov i Pingdom och tog medeltalet. Den totala laddningstiden var 305 ms med en total sidstorlek på endast 16,8 KB. Det är alltid bra att ha ett baslinjetest för att se vad temat är kapabelt av i fråga om råprestanda.
Vi körde sedan en annan uppsättning tester med ett av de förbyggda temana från GeneratePress-webbplatsbiblioteket. Detta innehåller bilder, bakgrunder, nya sektioner, etc. En fördel GeneratePress har är att den har många förbyggda teman som inte kräver en plugin för sidbyggare. Du kan se det som det fortfarande klockade under 400 ms.
Nu kan du naturligtvis i en verklig miljö ha andra saker som körs, som Google Analytics, Facebook remarketing pixel, Hotjar, etc. Men du borde kunna sikta på under 1 sekunds laddning enkelt. Kolla in en djupgående recension av GeneratePress över på woorkup.
Vi visar dig fler sätt att optimera och snabba upp WordPress nedan.
OceanWP
OceanWP-temat är lätt och mycket justerbart och gör att du kan skapa nästan vilken typ av webbsida som helst, en blogg, portfölj, företagswebbplats och WooCommerce-butik med en vacker och professionell design. Byggd av Nicolas Lecocq, det är också aktivt uppdaterad och välunderbyggd.
Precis som med GeneratePress finns både en gratis och premiumversion tillgänglig. Om du tittar på WordPress-repository, har den fria versionen för närvarande över 400 000 aktiva installationer och en imponerande 5 av 5 stjärnor (över 2 600 personer har gett det 5 stjärnor).
Hur snabbt är det? Vi gjorde en ny installation av OceanWP, körde fem hastighetsprov i Pingdom och tog medeltalet. Den totala laddningstiden var 389 ms. med en sammanlagd sidstorlek på endast 230,8 KB. Skripten i OceanWP är något större, men inget att skriva hem om.
Vi körde sedan en annan uppsättning tester med ett demo-tema från OceanWPs webbplatsbibliotek. Det här innehåller bilder, bakgrunder, nya avsnitt och kräver Elementor-sidobyggare-plugin. Du kan se att det fortfarande laddade under 600 ms.
Du kan kolla in en mer djupgående recension av OceanWP på vår blogg.
Astra
Astra är ett snabbt, fullständigt anpassningsbart och vackert tema som passar för bloggar, personliga portföljer, företagswebbplatser och WooCommerce-butikfronter. Den är väldigt lätt (mindre än 50 KB på front-end) och ger oöverträffad hastighet. Byggd av teamet på Brainstorm Force, är den aktivt uppdaterad och välunderbyggd. Du kanske känner igen dem som skapare av det populära All In One Schema Rich Snippets-plugin som har funnits i många år.
Precis som med GeneratePress och OceanWP finns både en gratis och premiumversion tillgänglig. Om du tittar på WordPress-repository har den fria versionen för närvarande över 400 000 aktiva installationer, 1,6 + miljoner hämtningar och en imponerande 5 av 5 stjärnor (över 2 500 personer har gett det 5 stjärnor).
Hur snabbt är det? Vi gjorde en ny installation av Astra, körde fem hastighetsprov i Pingdom och tog medeltalet. Den totala laddningstiden var 243 ms. med en total sidstorlek på endast 26,6 KB.
Vi körde sedan en ny uppsättning tester med ett demo-tema från Astra Starter kit-webbplatsbiblioteket. Det här innehåller bilder, bakgrunder, nya avsnitt och kräver Elementor-sidobyggare-plugin. Du kan se att det fortfarande laddade under 700 ms. Obs: bilderna i denna demo komprimerades helt, men de valde mycket högupplösta från början.
Det är viktigt att ta skillnaderna mellan hastighetsprov med dessa tre teman med saltkorn. Problemet är att det är nästan omöjligt att köra en helt exakt sida vid sida jämförelse. Det viktiga vi ville visa er att alla dessa WordPress-teman är blixtsnabbt, både i fullversion och som demo! 🚀
Varning om Sidbyggare
Som du säkert märker, kräver OceanWP och Astra båda sidbyggare för att använda deras webbplatsteman från biblioteket. Här är några saker att tänka på när du använder ett plugin för sidbyggare:
- Vissa sidbyggare kan öka laddningstiden på din webbplats. Detta beror på att de måste ladda ytterligare CSS och JS för att få saker att fungera för dig utan kod. Det är så magin sker! Vi rekommenderar alltid hastighetstestning av din WordPress-webbplats före och efter installationen av en sidobyggare.
- Du håller på att ingå en förbindelse och låser dig hos den sidbyggaren för design. Se till att du väljer en som uppdateras regelbundet och har allt du behöver för en lång tid framöver.
Med det sagt är vi fortfarande stora fans av sidbyggare som Elementor och Beaver Builder. För det mesta är de utvecklade med prestanda i åtanke och lägger bara till lite overhead. För de flesta är funktionaliteten och användbarheten värt det, eftersom dessa plugins låter dig skapa allt du kan drömma! De kan också vara snabbare i vissa fall, eftersom de kan vara en ersättning för 5 + andra plugin som du annars skulle behöva använda.
Men om du inte behöver en plugin för sidobyggare, installerar inte bara en för skojs skull. Det kommer också bli intressant att se hur den nya Gutenberg-editorn kommer att spela en roll i webbdesign under de närmaste åren.
Sanningen om WordPress-Plugin
Nu för sanningen om WordPress-plugin. Du kanske har fått höra att du inte ska installera för många plugins för att inte sakta ner din WordPress-webbplats. Även om detta ibland är sant, är det inte den mest kritiska faktorn. Antalet plugin är inte lika viktigt som pluginsens kvalitet. Där, vi sa det. 😜
Precis som med teman är det viktigt hur plugin utvecklas och om den byggdes med prestanda i åtanke. Vi har många kunder hos Kinsta som kör 30-40 plugin och deras webbplatser laddas fortfarande långt under en sekund.
Även om det är kul att lägga till kod på din webbplats, är det inte alltid praktiskt av följande skäl:
- Du måste uppehålla koden själv och hålla den uppdaterad allteftersom standarden ändras. Folk är upptagna, varför inte lita på de fantastiska utvecklarna som känner till standarderna bättre än de flesta?
- För det mesta kommer ett välkodat plugin inte att introducera mycket mer overhead än koden självt.
- Du måste komma ihåg att en majoritet av WordPress-communityt inte är så tekniskt kunnigt som utvecklaren. Plugin är lösningar som hjälper till att lösa problem.
Det finns naturligtvis många inte så bra plugin där ute som du vill hålla dig borta från. Lita på oss; vi har sett det värsta av de värsta på Kinsta. Många, inte alla, av de pluginsen som vi förbjudit på Kinsta, har vi själva sett skapa prestandaproblem.
Francesco har ett intressant inlägg där han dyker in i laddningstestade WordPress plugins för att se hur de fungerar på en WordPress-sidas back-end, vilket i de flesta fall inte lagras. Vi snöar in på hur du hittar dåliga plugins på din webbplats längre fram.
Men det kan inte ignoreras att en av de saker som människor älskar med WordPress är dess massiva bibliotek med plugin från tredje part. Men med 56 000 + gratis plugin listade enbart på WordPress.org och tusentals mer listade någon annanstans kan det vara svårt att hitta det enda plugin du behöver. Prata om en nål i en höstack! Kolla in listan som vi har sammanställt av bara de bästa WordPress-pluginsen på marknaden.
Vi försöker bara dela med oss av saker vi använder dagligen. Och ja, vi använder WordPress-plugin på vår webbplats precis som resten av er. Många av gruppmedlemmarna hos Kinsta utvecklar och säljer också plugin.
Ett Stort Problem med WordPress-Plugin
Ett stort problem med WordPress-plugin är avinstallationsprocessen. När du installerar ett WordPress-plugin eller ett tema, lagras det data i databasen. Problemet är att när du tar bort ett plugin med en av standardmetoderna, lämnar det vanligen kvar tabeller och rader i din databas. Med tiden kan detta lägga till mycket data och även börja sakta ner din webbplats. I vårt exempel avinstallerade vi Wordfence-säkerhetspluginet, och det lämnade kvar 24 tabeller i vår databas (se nedan). Det är ännu värre om de ligger bakom data i din wp_options tabell.
Och förutom databasen lämnar många plugin också kvar ytterligare mappar och filer. Enligt vår erfarenhet ses det vanligen med säkerhets- och cachepluggar som skapar ytterligare kataloger för loggning. Till exempel, efter att Wordfence-pluginet raderades, lämnades vi med en ”wflogs” -mapp i vår wp-innehållskatalog. Och vi försöker inte vara elaka mot Wordfence, de flesta plugin och teman på marknaden fungerar så här.
Varför Gör Utvecklare på det här sättet?
Så du undrar nog varför utvecklare inte har självrensningsalternativ när du avinstallerar och tar bort ett plugin? Tja, de gör det. Men här är några av anledningarna till att de förmodligen inte är lika självklara omedelbart.
- De vill behålla inställningar för användaren. Om du tar bort ett WordPress-plugin och bestämmer dig för att försöka igen senare kommer alla dina inställningar och data fortfarande att finnas där. Även om detta är superbekvämt, är det inte det mest effektiva sättet.
- De bryr sig inte om prestanda. Vissa utvecklare kanske hävdar att det inte påverkar prestanda att lämna tabeller bakom sig. Men tänk på en webbplats över tio år, efter att ha använt hundratals plugin, som har genererat möjligen tusentals rader eller tabeller. Databasförfrågningar har en betydande inverkan på din WordPress-webbplats, och pluginsen kan stå för många av dessa förfrågningar om utvecklaren inte var försiktig. I allmänhet borde ett välskrivet plugin bara göra förfrågningar till de tabeller eller rader som det är knutet till, men det är inte alltid fallet. Vi har sett detta själva i Kinsta, långa databasförfrågningar som gör att en webbplats kryper fram på grund av onödiga autoladdade data i wp_options-tabellen som har lämnats kvar.
- De gjorde ett misstag. I WordPress-pluginhandboken står det även att ”mindre erfarna utvecklare ibland gör misstaget att använda avaktiveringshaken för detta ändamål.”
De goda nyheterna? Det finns sätt att städa upp och bli av med ett plugin på rätt sätt. 👏 Kolla in våra följande handledningar:
Optimala WordPress-inställningar
Nu för att gå vidare till optimala WordPress-inställningar. Här är några ändringar du kan göra för att hjälpa till att påskynda din WordPress-webbplats. Många av dessa är mycket subtila förändringar, men allt hjälper!
Ändra din WordPress Inloggnings-URL
Enligt standard är din WordPress-webbplats inloggnings-url domain.com/wp-admin/. Ett av problemen med detta är att alla bots, hackare och skript där ute också vet detta. Genom att ändra URL:n kan du göra dig mindre av ett mål, bättre skydda dig mot råstyrkeattacker och minska bandbredd som används av de robotar som attackerar denna URL flera gånger.
Om du ändrar din WordPress-inloggningsadress kan du också bidra till att förhindra vanliga fel som ”429 för många begäranden”. Det här är inte en lösning, det är bara ett litet knep som kan hjälpa till att skydda dig och minska belastningen på den sidan.
För att ändra din WordPress-inloggningsadress rekommenderar vi att du använder en av följande plugin:
- WPS Hide Login (gratis)
- Perfmatters (premium, men inkluderar andra prestandaoptimeringsinställningar. Utvecklat av en teammedlem från Kinsta)
Avaktivera eller Justera Plugin- och Tema-uppdateringar
Långsamma WordPress adminkontrollpanel kan påverkas av nätverket, datacenterplatsen och även PHP-versioner. Men en annan faktor som inte många pratar om är WordPress-uppdateringskontrollen som körs i bakgrunden. Detta är ett exempel där det kan skada dig med många WordPress-plugin och teman. WeFoster har ett bra blogginlägg om detta där de myntar frasen ”Third Party Plugin Update Check Syndrome” eller TPPUCS.
I huvudsak är problemet att den inbyggda WordPress-uppdateringskontrollen gör en extern GET-förfrågan bakom kulisserna (https://third-party-plugin/update-check.php). Ibland kan det vara periodiskt eller mycket ofta. Om det händer hela tiden kan detta leda till att din adminkontrollpanel börjar krypa fram.
Det här är mer av ett problem med hur uppdateringskontrollen i WordPress är byggd. Om du lider av långsamma WordPress adminkontrollpaneltider, kanske du bör prova. Åtgärden är att inaktivera automatiska uppdateringar. Varning: Gör bara detta om du tänker leta efter uppdateringar manuellt. Många uppdateringar inkluderar säkerhets- och buggfixar.
För att inaktivera uppdateringar rekommenderar vi att du använder ett av följande pluginprogram:
- Disable All WordPress Updates: Helt gratis utan inställningar. Gör vad det säger bra.
- Easy Updates Manager: Ger mer kontroll över selektiva uppdateringar. Kärnversionen är gratis.
Du kan enkelt ställa in en kalenderpåminnelse, inaktivera plugin en gång i veckan, kolla efter uppdateringar och sedan aktivera det igen.
Stäng av Pingbacks
En pingback är en automatiserad kommentar som skapas när en annan blogg länkar till dig. Det kan också finnas själv-pingbackar som skapas när du länkar till en artikel i din egen blogg.
Vi rekommenderar att stänga av dessa eftersom de genererar värdelösa förfrågningar och ytterligare skräppost på din webbplats. Kom ihåg att desto mindre förfrågningar som din WordPress-webbplats måste göra desto bättre, särskilt på webbplatser med hög trafik. För att inte nämna det faktum att en pingback på din egen hemsida bara är rätt irriterande. Följ stegen nedan för att inaktivera pingbacks.
Steg 1 – Inaktivera Pingbackar från andra bloggar
Klicka på ”Inställningar → Diskussion” i din WordPress-kontrollpanel. Under avsnittet Diskussionsinställningar avmarkera alternativet ”Tillåt länkmeddelanden från andra bloggar (pingbacks och trackbacks) på nya artiklar.”
Steg 2 – Inaktivera självpingbackar
När det gäller att inaktivera självpingbackar har du ett par alternativ. Du kan använda gratispluginet No Self Pings. Eller så kan du använda ett premiumplugin som Perfmatters.
Alternativt kan du också inaktivera självpingbackar genom att lägga till följande kod till ditt WordPress-temas functions.php-fil. Varning, redigering av källan till ett WordPress-tema kan bryta din webbplats om det inte görs korrekt. Tips, du kan enkelt lägga till PHP-snippets så här med det kostnadsfria Code Snippets-plugin. Det betyder att du aldrig behöver röra ditt tema.
function wpsites_disable_self_pingbacks( &$links ) {
foreach ( $links as $l => $link )
if ( 0 === strpos( $link, get_option( 'home' ) ) )
unset($links[$l]);
}
add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );
Begränsa inlägg på din Bloggfeed
Om din bloggfeed är inställd som din hemsida eller en annan sida på din webbplats behöver du inte 50 miniatyrer som alla laddas samtidigt. För dem som kör bloggar med hög trafik är din hemsida den viktigaste sidan på din webbplats, och du vill att den ska ladda snabbt. Ju färre förfrågningar och media desto bättre när det gäller prestanda.
Detta är också just därför att paginering uppfanns (se nedan). Paginering är vad du ser i slutet av bloggfeeds som låter dig bläddra till nästa sida. Vanligtvis är dessa siffror, eller de kan använda ”nästa/tidigare” inlägg. Ditt WordPress-tema kommer sannolikt redan att ha anpassad paginering inbyggd.
WordPress anger som standard gränsen för nya WordPress-installationer till 10, men vi har sett att detta ändrats så många gånger vi har tappat räkna. Så se till att dubbelkolla vilket värde du använder. Vi rekommenderar någonstans mellan 8 och 12. Om du är nyfiken använder vi 12 på vår Kinsta blogghemsida.
Du kan hitta det här alternativet i din WordPress adminkontrollpanel under ”Inställningar → Läsning.” Du kan sedan ändra värdet för att ”Blogg visar högst antal.”
Varför Cache Är så Viktigt
Cachning är överlägset ett av de viktigaste och enklaste sätten att snabba på WordPress! Men innan vi visar dig hur du använder cachning, är det viktigt att först förstå hur det fungerar och vilka olika typer av cachning som finns.
Vad är Cachning?
Kort sagt, varje webbsida som besökts på din WordPress-webbplats kräver en begäran till servern, bearbetning av den servern (inklusive databasfrågor) och sedan ett slutresultat som skickas från servern till användarens webbläsare. Resultatet är din webbplats, komplett med alla filer och element som gör att den ser ut som den gör.
Du kan till exempel ha en rubrik, bilder, en meny och en blogg. Eftersom servern måste behandla alla dessa förfrågningar tar det lite tid för hela webbsidan att levereras till användaren, speciellt med klumpiga eller större webbplatser.
Det är där ett WordPress-cachningsplugin kommer in! Cachning instruerar servern att lagra vissa filer till disk eller RAM, beroende på konfigurationen. Därför kan den komma ihåg och duplicera samma innehåll som det har visat i det förflutna. I grund och botten minskas den mängd arbete som krävs för att skapa en sidvisning. Som ett resultat laddas dina webbsidor mycket snabbare, direkt från cacheminnet.
Några andra fördelar med cachning är:
- Din server använder färre resurser – det här knyter an till hastighet, eftersom färre resurser ger en snabbare webbplats. Det lägger emellertid också mindre på din server. Det här är mycket viktigt när det gäller högdynamiska platser, till exempel medlemskapswebbplatser, och bestämmer vad du kan och kan inte tjäna från cacheminnet.
- Du får lägre TTFB – Cachning är ett av de enklaste sätten att sänka din TTFB. I själva verket reducerar cachning typiskt TTFB med upp till 90 %!
Typer av Cachning
När det kommer till cachning, används vanligen två olika tillvägagångssätt:
1. Cachning på Server-Nivå
Cachning på servernivå är överlägset en av de enklaste metoderna för slutanvändaren. Vad detta innebär är att WordPress-webbhotellet hanterar det åt dig. På Kinsta använder vi följande fyra typer av cache, som alla automatiskt görs på program- eller servernivå:
Det betyder att du inte behöver oroa dig för att strula med några komplicerade och förvirrande cachningsplugin. Du kan sluta Googla runt för ”bästa cachningsplugin 2024” och fokusera på mer produktiva uppgifter. 👏
An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀
— WPColt (@WPColt) January 3, 2018
Sidcachen är konfigurerad för att fungera direkt med standard WordPress. Du behöver inte göra någonting! Starta helt enkelt din WordPress-webbplats och sidcachning kommer att börja hända.
Vi har också cachningsregler på plats för e-handelswebbplatser som WooCommerce och Easy Digital Downloads. Som standard är vissa sidor som aldrig ska cachas, till exempel kundvagn, mitt konto och kassa, uteslutna från cachning. Användare kommer automatiskt förbi cachen när woocommerce_items_in_cart cookien eller edd_items_in_cart detekteras för att försäkra en smidig och synkad utcheckningsprocess.
Du kan enkelt rensa din WordPress-webbplats cache när som helst från adminkontrollpanelen.
Det är också integrerat i vår MyKinsta-instrumentbrädan. Klicka bara på Verktyg och klicka på ”Rensa cache”.
2. Cachning med ett Plugin
Om ditt webbhotell inte tillhandahåller cachning kan du använda ett tredjeparts-plugin för WordPress-cachning. Baserat på vår erfarenhet rekommenderar vi något av följande:
- WP Rocket (premium)
- Cache Enabler (gratis)
- W3 Total Cache (gratis)
Du kan också kolla in några ytterligare alternativ i vårt djupgående inlägg om WordPress-cacheplugin.
Vi stöder också WP Rocket på Kinsta! Vi tillåter vanligtvis inte cachepluggar i vår miljö eftersom de inte kommer överens med vår inbyggda cachningslösning. Men från och med WP Rocket 3.0 kommer deras sidcachningsfunktioner automatiskt att stängas av när de körs på Kinsta-servrar.
Detta gör det möjligt för Kinsta-klienter att använda vår snabba cachning på servernivå, men fortfarande utnyttja de fantastiska optimeringsfunktionerna WP Rocket har att erbjuda.
Ingen Cachning vs Cachning
Hur mycket hjälper cachning? Beviset finns i pudding.
Vi körde några hastighetsprov med Kinsta servernivå cachning så att du kan se skillnaden det gör, både vad gäller total hastighet och TTFB.
Ingen Cachning
Vi körde först fem tester på Pingdom utan cache aktiverat och tog medeltalet.
Ingen Cachning TTFB
Det är också viktigt att notera skillnaden i TTFB utan och med cachning. TTFB i Pingdom representeras av det gula ”väntar”-fältet. Som du kan se är TTFB utan cache 192 ms. Du kan se att den inte serverar från cacheminnet eftersom x-kinsta-cache rubriken visar ett MISS.
Med Cachning
Vi aktiverade sedan cachning på servernivån och körde fem test på Pingdom och tog medeltalet.
Som du kan se minskade cachning på servernivå vår sidladdningstid med 33,77 %! Och det är utan något extra arbete involverat. Den webbplatsen vi testat är också ganska optimerad, så större o-optimerade webbplatser kommer se ännu större skillnader.
TTFB med Cachning aktiverad
Om vi nu tittar på TTFB med cachning aktiverad, kan vi se att den är under 35 ms. Du kan se att den servar från cacheminne eftersom x-kinsta-cache-rubriken visar en HIT.
CDN-cachen är också lika viktigt som cacheminne från din WordPress-värd. Vi kommer att dyka mer in i CDN längre fram.
Problem med cachning och medlemsskapssidor
Medlemskapswebbplatser innehåller mycket icke-cachebart innehåll och sidor som ständigt ändras. Saker som inloggningssidan för medlemmar i communityt (som kan bli träffad ständigt beroende på platsens storlek), utcheckningssidor för digitala varor eller kurser och diskussionsforum är vanliga synder och smärtpunkter, eftersom dessa inte typiskt kan cachas.
Det slutar dock inte där. På vanliga WordPress-webbplatser är inte WordPress-kontrollpanelen cachad för ”inloggade” användare. Det här är bra när du bara har några författare och administratörer, men när du plötsligt har tusentals medlemmar som använder kontrollpanelen, orsakar det omedelbart prestandaproblem, eftersom inget av detta kan fungera från cacheminnet på servern. Det betyder att du behöver kraften och arkitekturen bakom kulisserna för att ge stöd. Delade webbhotell kommer vanligen att falla sönder under dessa omständigheter.
Objektscachning för Högst Dynamiska Webbplatser
När det gäller WordPress-medlemswebbplatser är dina vanliga cache-inställningar vanligtvis inte tillräckligt, eftersom de inte alltid utnyttjar det fullt ut. Det här är där objektscachning kommer in.
Objektscachning lagrar resultaten av databasförfrågningar så att nästa gång den specifika biten av data behövs kan den levereras från cacheminnet utan att fråga databasen. Detta ökar PHP-exekveringstiden och minskar belastningen på din databas. Detta blir extremt viktigt med medlemskapswebbplatser! Med WordPress kan du implementera objektscachning på ett par olika sätt:
- En tredjeparts cachning-lösning som W3 Total Cache
- Redis (rekommenderas)
- Memcached
Vi erbjuder Redis som tillägg på Kinsta så att du kan dra full nytta av konstant objektscachning för dina medlemssidor.
Analysera Cache
Kommer du ihåg den där x-kinsta-cache–rubriken vi nämnde ovan? Beroende på din webbleverantör eller cache-lösning kan rubriken heta något annorlunda. Varje gång en förfrågan görs till din WordPress-webbplats har rubriken ett värde, som HIT, BYPASS, MISS och EXPIRED. Det här låter dig se hur din cache fungerar.
Att öka din WordPress-webbplats cacheträff-förhållande är viktigt eftersom du vill att så mycket som möjligt av din webbplats ska serveras från cachen. I Kinsta kan du analysera data i vårt MyKinsta-analysverktyg och Kinsta-cacheloggarna för att avgöra om det finns cache-BYPASSing-GET-förfrågningar som kan cachas eller POST-förfrågningar som kan elimineras.
Cachekomponentstapeln (som visas nedan) låter dig se statusen för varje förfrågan, vare sig det var en HIT, BYPASS, MISS eller EXPIRED. Du kan filtrera data efter senaste 24 timmar, 7 dagar eller 30 dagar.
Cachekomponentdiagrammet ger dig en överblick över ditt cachningsförhållande. Ju fler begäranden du tjänar från cache desto bättre. Som du kan se i exemplet nedan, har denna WordPress-webbplats ett 96,2 % HIT-cache-förhållande. Vilket är bra!
Den översta cachebypasseringsdelen visar 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.
Bildoptimering är ett måste
Bildoptimering är en annan enkel sak du kan göra som har en betydande inverkan på dina totala sidladdningstider. Detta är inte valfritt; varje webbplats borde göra detta!
Stora bilder sakta ner dina webbsidor vilket skapar en mindre än optimal användarupplevelse. Optimering av bilder är processen att minska deras filstorlek, antingen med hjälp av ett plugin eller med ett skript, vilket i sin tur snabbar upp sidans laddningstid. Destruktiv och förlustfri komprimering är två vanliga metoder.
Enligt HTTP Archive utgör bilderna i genomsnitt 34 % av den totala webbsidans vikt, augusti 2019. Så efter videoklipp, som är mycket svårare att optimera, är bilder överlägset den första platsen du bör börja! Det är viktigare än JavaScript, CSS och Typsnitt. Och ironiskt nog är ett bra bildoptimeringsarbetsflöde en av de enklaste sakerna att genomföra, men många webbplatsägare förbiser detta.
Bilder utgjorde i genomsnitt 54 % av en sida totala vikt i december 2017. Så det verkar som att webben som helhet blir bättre vid bildoptimering! Men 34 % är fortfarande ett tal som inte kan ignoreras. Om du inte har något videoinnehåll på din webbplats är bilderna fortfarande din # 1 smärtpunkt för sidvikt.
Att hitta balansen (Filstorlek och Kvalitet)
Det främsta målet med att formatera dina bilder är att hitta balansen mellan den lägsta filstorleken och acceptabel kvalitet. Det finns mer än ett sätt att utföra nästan alla dessa optimeringar. Ett av de mest grundläggande sätten är att komprimera dem innan de laddas upp till WordPress. Vanligtvis kan detta göras i ett verktyg som Adobe Photoshop eller Affinity Photo. Eller använd den nya onlineappen Squoosh från Google. Men dessa uppgifter kan också utföras automatiskt med hjälp av plugin, som vi kommer att gå in mer på nedan.
De två primära sakerna att tänka på är filformatet och typen av komprimering du använder. Genom att välja rätt kombination av filformat och kompressionstyp kan du minska din bildstorlek med så mycket som 5 gånger. Du måste experimentera med varje bild eller filformat för att se vad som fungerar bäst.
Innan du börjar ändra dina bilder, se till att du har valt den bästa filtypen. Det finns flera typer av filer du kan använda:
- PNG – producerar bilder av högre kvalitet, men har också en större filstorlek. Skapades som ett förlustfritt bildformat, även om det också kan vara förlust.
- JPEG – använder destruktiv och förlustfri optimering. Du kan justera kvalitetsnivån för en bra balans mellan kvalitet och filstorlek.
Helst bör du använda JPEG (eller JPG) för bilder med mycket färg och PNG för enkla bilder.
Du bör även överväga att använda WEBP-bilder på din webbplats.
Men vad gäller för GIF? Animerade GIF är alltid roliga, men de dödar webbprestanda. En massa GIF-filer är över 1 MB i storlek. Vi rekommenderar att du behåller dessa för sociala medier och Slack. Om det finns en som du inte kan leva utan i ditt blogginlägg, ta en titt på hur du kan komprimera animerade GIF-filer.
Kompressionskvalitet vs. Storlek
Här är ett exempel på vad som kan hända att du komprimerar en bild för mycket. Den första använder en mycket låg kompressionshastighet, vilket resulterar i högsta kvalitet (men större filstorlek). Den andra använder en mycket hög kompressionshastighet, vilket resulterar i en mycket lågkvalitativ bild (men mindre filstorlek). Obs! Den ursprungliga bilden är orörd 2,06 MB.
Som du kan se är den första bilden ovan 590 KB. Det är ganska stort för ett foto! Det är generellt bäst om du kan hålla en webbsidas totalvikt under 1 eller 2 MB i storlek. 590 KB skulle vara en fjärdedel av det redan. Den andra bilden ser hemsk ut, men så är det bara 68 KB. Vad du vill göra är att hitta ett bra medium mellan din komprimeringshastighet (kvalitet) och filstorleken.
Så vi tog bilden igen med en medelhög kompressionshastighet, och som du kan se nedan ser kvaliteten fortfarande bra ut, och filstorleken är 151 KB, vilket är acceptabelt för ett högupplöst foto. Detta är nästan 4x mindre än det ursprungliga fotot med låg komprimering. Vi försöker hålla de flesta av våra bilder under 100 KB-gränsen för bästa prestanda.
Destruktiv vs. Förlustfri Optimering
Det är också viktigt att förstå att det finns två typer av kompression du kan använda, destruktiv och förlustfri.
Destruktiv komprimering innebär att du eliminerar några data i din bild. På grund av detta betyder det att du kan se nedbrytning (kvalitetsminskning eller vad vissa refererar till som pixelerade). Så du måste vara försiktig med hur mycket du minskar din bild. Inte bara på grund av kvalitet, men också för att du inte kan ångra processen. Naturligtvis är en av de stora fördelarna med destruktiv komprimering och varför det är en av de mest populära komprimeringsmetoderna att du kan minska filstorleken ganska mycket.
Förlustfri kompression, till skillnad från destruktiv, minskar inte bildens kvalitet. Hur är detta möjligt? Det görs vanligtvis genom att ta bort onödiga metadata (automatiskt genererade data som produceras av enheten som tar bilden). Den största nackdelen med den här metoden är dock att du inte ser en signifikant minskning av filstorleken. Med andra ord kommer det att ta upp mycket diskutrymme efter en tid.
Du kommer att vilja experimentera med vad som fungerar bäst för dig. Men för de flesta användare rekommenderar vi att du använder destruktiv komprimering på grund av att du enkelt kan komprimera en bild över 70 % (ibland även över 90 %!) utan mycket kvalitetsförlust. Multiplicera detta med 15 bilder på en sida, och det kommer att spela en viktig roll för att minska din webbplats laddningstid.
Bildkomprimeringsplugin
Den goda nyheten är att det finns några fantastiska WordPress-bildkomprimeringsplugin som du kan använda för att automatisera hela processen. Här är några plugin som vi rekommenderar:
- Imagify (destruktiv och förlustfri – optimerar bilder externt)
- WP Smush (destruktiv och förlustfri – optimerar bilder externt)
- Optimole (destruktiv och förlustfri – optimerar bilder externt)
Det viktigaste när du väljer ett bildoptimeringsprogram är att använda en som komprimerar och optimerar bilder externt på sina servrar. Detta minskar i sin tur belastningen på din webbplats. Alla ovanstående gör det här.
Om du är nyfiken använder vi Imagify-pluginet på Kinsta-webbplatsen. Den komprimerar automatiskt bilder när vi laddar upp dem till WordPress mediebiblioteket. Så vi behöver aldrig oroa oss för något. Med tiden kan du få en känsla för vilken bildkomprimeringsnivå du vill använda. Det erbjuder Normal, Aggressive och Ultra.
Vi använder Aggressive-nivån vid Kinsta och brukar se 60-70 % besparingar beroende på bilden. Obs! Vi använder mycket mer PNG än JPEG på grund av att de flesta av våra bilder är ikoner och illustrationer, inte foton.
Hur mycket snabbare kommer din WordPress-webbplats att vara om du använder bildkomprimering? Allt beror på storleken på dina ursprungliga bilder och vad de är efter komprimering. Men vi körde några hastighetstest och fann att en kvalitetskomprimeringslösning kan sänka sidladdningstiden med över 80 %!
Latladdning
Om du har mycket bilder kan du kanske överväga att latladda dem. Det här är en optimeringsteknik som laddar upp synligt innehåll men försenar nedladdning och återgivning av innehåll som visas längre ner.
Kolla in vår guide om hur du implementerar latladdning i WordPress. Detta kan vara särskilt viktigt på blogginlägg med massor av gravatar-ikoner från kommentarer. Google släppte också nyligen sina rekommendationer för latladdning.
Ytterligare Bildoptimeringstips
Här är några slutliga bildoptimeringstips att ta med sig.
- Tid då vi laddade upp bilder som endast var kolumnbreddens storlek eller DIV är över. Responsiva bilder fungerar direkt i WordPress (sedan version 4.4) och kommer automatiskt visa mindre bildstorlekar till mobila användare.
- SVG kan vara ett annat bra alternativ till att använda bilder. Alla de handritade illustrationer som du ser på Kinsta-webbplatsen är SVGs (vektorer). SVGs är vanligtvis mycket mindre i filstorlek, men inte alltid. Kolla in vår handledning om hur du använder SVG på din WordPress-webbplats.
- Använd webbfonter istället för att placera text inom bilder – de ser bättre ut när de skalas och tar mindre plats. Och om du använder en teckensnittsgenerator kan du optimera dem ännu mer. Kolla in hur vi minskade storleken på vår ikonteckensnittsfil med hela 97,59% med hjälp av en teckensnittsgenerator.
Finjustera din Databas
Härnäst är några tips om hur du finjusterar din WordPress-databas. Precis som en bil behöver din databas ses över då och då eftersom den kan bli uppblåst.
Medlemskapswebbplatser gör det speciellt svårt eftersom de vanligtvis genererar mer komplexa förfrågningar, vilket i sin tur ger ytterligare latens vid hämtning av informationen från MySQL-databasen. Mycket av detta beror på alla extra rörliga delar och stora mängder data sidor som dessa har. Det kan också bero på webbplatser som starkt är beroende av sökfrågor för navigering eller använder WP_Query.
För att inte tala om, har du också stora mängder samtidiga användare som kontinuerligt förfrågar databasen.
Använd InnoDB MySQL Lagringsmotor
Många äldre webbplatser använder fortfarande MyISAM-lagringsmotor i sin databas. Under de senaste åren har InnoDB visat sig fungera bättre och vara mer tillförlitlig.
Här är några fördelar med InnoDB över MyISAM:
- InnoDB har lås på radnivå. MyISAM har bara full tabell-låsning. Detta gör att dina förfrågningar kan bearbetas snabbare.
- InnoDB har vad som kallas referensintegritet som innebär att stödja utländska nycklar (RDBMS) och förhållandebestämmelser, MyISAM har det inte (DMBS).
- InnoDB stöder transaktioner, vilket innebär att du kan spara och sedan ångra dig. MyISAM gör det inte.
- InnoDB är mer tillförlitligt eftersom det använder transaktionsloggar för automatisk återställning. MyISAM gör det inte.
Så nu kanske du undrar, kör du InnoDB eller MyISAM? Om du kör på en ganska ny WordPress-webbplats finns chansen att du redan använder InnoDB MySQL-lagringsenheten. Men med äldre WordPress-webbplatser kanske du vill göra en snabb check. Vissa webbplatser kan till och med ha en salig blandning av MyISAM- och InnoDB-tabeller, där du kan se förbättringar genom att konvertera dem överallt.
Följ dessa enkla steg nedan för att kontrollera.
Steg 1
Logga in på phpMyAdmin och klicka på din MySQL-databas.
Steg 2
Gör en snabbsökning eller sort av kolumnen efter ”Typ”, och du kan se vilken lagringsmotor som dina tabeller använder. I det här exemplet nedan kan du se att två av tabellerna fortfarande använder MyISAM.
Om du hittade några, då är det nog dags att flytta dem till InnoDB. Vi rekommenderar alltid att du når ut till din värd och frågar om de kan göra det åt dig. Vid Kinsta konverteras varje kunds databastabell automatiskt till InnoDB av vårt migrationslag.
Men du kan alltid följa dessa handledningar nedan för att konvertera dina MyISAM-tabeller till InnoDB manuellt:
Radera och begränsa sid- och inläggsrevideringar
När du sparar en sida eller ett inlägg i WordPress skapas det som kallas en revidering. Detta sker i både utkast och redan publicerade inlägg som uppdateras. Revideringar kan vara till hjälp om du behöver återgå till en tidigare version av ditt innehåll.
Men revideringar kan också skada prestandan på din WordPress-webbplats. På stora sidor kan detta mycket snabbt bli till tusentals rader i din databas som inte nödvändigtvis behövs. Och ju fler rader du har desto större är din databas i storlek, vilket tar upp lagringsutrymme. Medan index skapades för detta ändamål ser vi fortfarande detta problem lamslå WordPress-webbplatser. Det finns ett par saker du kan göra.
1. Ta bort gamla revideringar
Om du har en äldre WordPress-webbplats med många sidor och inlägg kan det vara dags att göra en snabb rengöring och ta bort de gamla revideringarna. Du kan göra det med MySQL, men med alla de svåra kodstyckena som flyter omkring på webben rekommenderar vi att du gör en säkerhetskopia av din webbplats och använder ett gratisplugin som WP-Sweep.
Ett annat av våra favoritplugin, WP Rocket, har också en databasoptimerings-funktion för att rensa ut revideringar.
Om du är kunnig i WP-CLI finns det några kommandon som du kan använda för detta.
Logga in på din server via SSH och kör följande kommando för att få och se hur många revideringar som finns i databasen
wp revisions list
Om du får ett fel, kan du först behöva installera wp-revisions-cli-paketet med följande kommando:
wp package install trepmal/wp-revisions-cli
Du kan sedan köra följande kommande för att rensa upp revideringarna:
wp revisions clean
2. Begränsa revideringar
En annan bra strategi och en som vi använder vid Kinsta är att begränsa antalet revideringar som kan lagras per inlägg eller sida. Även inställningar som max tio, kommer hjälpa revideringarna från att bli för många speciellt om du gör en hel del uppdateringar.
För att begränsa revideringar kan du lägga till följande kod i din wp-config.php-fil. Koden nedan måste infogas ovanför ”ABSPATH” annars fungerar det inte. Du kan ändra numret till hur många revideringar du vill behålla lagrat i din databas.
define('WP_POST_REVISIONS', 10);
Eller så kan du använda ett plugin som Perfmatters för att begränsa revideringar.
3. Inaktivera revideringar
Och sist men inte minst kan du också inaktivera revisioner på din webbplats helt och hållet. Om du tar denna väg rekommenderar vi starkt att du följer det första alternativet ovan för att ta bort ändringar och sedan inaktivera dem efteråt. På så sätt är din databas helt fri från alla gamla revideringar och inga nya kommer att läggas till framöver.
För att inaktivera revideringar kan du lägga till följande kod i din
wp-config.php file. -fil. Koden nedan måste infogas ovanför ”ABSPATH” annars fungerar det inte.
define('WP_POST_REVISIONS', false);
Eller så kan du använda ett plugin som Perfmatters för att inaktivera revideringar.
Städa upp din wp_options-tabell och autoladdade data
Tabellen wp_options blir ofta förbisedd när det gäller övergripande WordPress och databasprestanda. Speciellt på äldre och stora webbplatser kan det här enkelt orsaka långsamma förfrågningstider på din webbplats på grund av autoladdade data som finns kvar från plugin och teman från tredje part. Lita på oss; vi ser det här varje dag!
Tabellen wp_options innehåller alla typer av data för din WordPress-webbplats, till exempel:
- Webbadress, hemadress, administratörs e-post, standardkategori, inlägg per sida, tidsformat etc.
- Inställningar för plugin, teman, widgets
- Temporärt cachade data
Tabellen innehåller följande fält (kolumner):
- option_id
- option_name
- option_value
- autoload (det här är det vi bryr oss om när det gäller prestanda)
En av de viktiga sakerna att förstå om wp_options-tabellen är autoladdningsfältet. Detta innehåller ett ja eller ett nej-värde (flagga). Detta kontrollerar i huvudsak huruvida det laddas av funktionen wp_load_alloptions() eller ej. Autoladdade data är data som laddas på varje sida på din WordPress-webbplats. Precis som vi visade dig hur du inaktiverar vissa skript från laddning över hela webbplatsen, gäller samma idé här. Autoload-attributet är som standard inställt på ”ja” för utvecklare, men inte alla plugin ska teoretiskt ladda deras data på varje sida.
Problemet som WordPress-webbplatser kan stöta på är när det finns en stor mängd autoladdade data i wp_options-tabellen. Detta är typiskt ett resultat av följande:
- Data autoladdas av ett plugin när det ska ställas in på ”no.” Ett bra exempel på detta skulle vara ett plugin för kontaktformulär. Behöver det laddas på varje sida eller bara kontaktsidan?
- v
wp_options-tabellen. Detta kan innebära onödiga autoladdade data-förfrågningar efter varje begäran. - Plugin och temautvecklare laddar data i
wp_options-tabellen i stället för att använda egna tabeller. Det finns argument på båda sidor av detta, eftersom vissa utvecklare föredrar plugin som inte skapar ytterligare tabeller. Dock var intewp_options-tabellen utformad för att hålla tusentals rader.
Hur mycket är för mycket autoladdade data? Detta kan naturligtvis variera, men helst vill du att detta ska ligga mellan 300 KB och 1 MB. När du börjar närma sig 3-5 MB-intervallet eller mer, är det troligtvis saker som kan optimeras eller tas bort från autoladdning. Och allting över 10 MB bör åtgärdas genast. Det betyder inte alltid att det kommer att orsaka ett problem, men det är ett bra ställe att börja.
Eftersom det här är ett sådant problem har vi en helt separat handledning som du borde läsa om hur du bäst kan felsöka autoladdade data, samt hur du rensar det.
Rensa upp Transienter
Om du inte använder objektcache lagrar WordPress transienta poster i wp_options-tabellen. Vanligtvis ges dessa en utgångstid och bör försvinna över tid. Det är dock inte alltid fallet. Vi har sett några databaser där det finns tusentals gamla transienta poster. Faktum är att vi på en sida behandlade några korrupta transienta poster där över 695 000 rader genererades i wp_options-tabellen. Usch!
Det är också viktigt att notera att transienter inte ska autoladdas som standard. Du kan använda en förfrågning som nedan för att se om det finns några autoladdade transienta data.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Ett bättre och säkrare alternativ skulle vara att använda ett gratisplugin som Transient Cleaner eller Delete Expired Transients som kan städa upp endast de utgångna transienterna från din wp_options-tabell. Det verkar emellertid som att det nu finns en funktion i WordPress, läggs till i 4.9, som automatiskt städar upp utgångna transienter. Så förhoppningsvis sker det automatiskt på din webbplats nu.
WP Rocket har också möjlighet att rengöra transienter i dess optimeringsalternativ för databaser.
Rensa WordPress-sessioner
En annan vanlig fråga som vi har sett är att cron-jobb ibland blir osynkade eller inte aktiveras ordentligt, och därför blir inte sessionerna rengjorda. Det kan sluta med att du får massor av _wp_session_-rader i din databas. I det här exemplet slutade den aktuella sajten med över 3 miljoner rader i deras wp_options-tabell. Och tabellen hade vuxit till över 600 MB i storlek.
Du kan använda en förfrågning som nedan för att se om du har det problemet:
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
I de flesta fall kan du sedan säkert radera dessa (som ett cron-jobb skulle ha gjort), men följande kommande:
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Efter att städat upp alla överblivna _wp_session_ rows hade tabellen mindre än 1000 rader och var reducerad till 11 MB i storlek.
Det fixade också topparna webbplatsen fick i MySQL.
Lägg till ett Index till Autoladdning
Om rensning av din wp_options –tabell inte räckte, kan du försöka lägga till ett ”index” i autoladdningsfältet. Detta kan i huvudsak hjälpa det att söka mer effektivt. Det fantastiska laget över på 10up utförde några testscenarier på e wp_options-tabell med ett typiskt antal autoladdade poster för att visa hur att lägga till ett autoladdningsindex för wp_options-förfrågningar kan öka prestanda.
Vi rekommenderar också att kolla in dessa två resurser från WP Bullet:
Att använda Redis som permanent Objektcache för WordPress
Redis är en minnesdatastrukturslagring med öppen källkod. I samband med WordPress kan Redis användas för att lagra värdena som genereras av WordPress ’native object cache permanent så att cachade objekt kan återanvändas mellan sidladdningar.
Genom att använda en permanent objektcache, som Redis, möjliggör återanvändning av cachade objekt istället för att kräva att MySQL-databasen ska ställas in en andra gång för samma objekt. Resultatet är att Redis kan minska belastningen på en webbplats MySQL-databas, samtidigt som sidans responstid reduceras och webbplatsens förmåga att skala och hantera ytterligare trafik ökar.
Högt dynamiska webbplatser (WooCommerce, medlemskapswebbplatser, forum, diskussionsforum, bloggar med extremt aktiva kommentarsystem) som inte kan utnyttja sidcachning är potentiella kandidater för ett permanent alternativ för cachning av objekt som Redis.
Om du är en Kinsta-kund, erbjuder vi ett Redis-tillägg. Kolla in hur du lägger till Redis i din värdplan.
Använd Elasticsearch för att snabba upp WordPress Search
Elasticsearch är en fulltextssökmotor med öppen källkod. Det används för att indexera och söka data otroligt snabbt.
I samband med WordPress kan Elasticsearch användas för att påskynda förfrågan till WordPress-databasen. Detta görs genom att bygga ett index över innehållet i webbplatsens databas och sedan använda Elasticsearch för att söka i indexet mycket snabbare än en MySQL-förfrågan kan utföra samma sökning.
Om du har tid och förmåga kan Elasticsearch integreras med en WordPress-webbplats av en mycket kunnig WordPress och Elasticsearch-utvecklare. Om din webbplats använder relativt standard användning av WP_Query kan Elasticsearch också integreras genom att installera ElasticPress, ett gratis WordPress-plugin från 10up, tillgängligt från WordPress.org, som automatiskt integreras med WP_Query-objektet för att generera sökresultat med Elasticsearch i stället för MySQL.
Vilken webbplats som helst som använder sig av WP_Query kan dra nytta av Elasticsearch. Exempel på webbplatser som kan dra nytta av Elasticsearch:
- Sidor där sökning är det primära navigationssättet.
- WooCommerce-webbplatser med ett stort antal beställningar där webbplatsadministratörer måste kunna söka regelbundet i listan över beställningar.
- En webbplats med ett stort antal inlägg där MySQL-förfrågningar ger oacceptabelt långsamma resultat.
Avaktivera icke-kritiska funktioner som är databasintensiva
Det här kan verka lite uppenbart, men det kan göra en jättestor skillnad om du inaktiverar icke-kritiska plugins och temafunktioner som är databasintensiva.
- Populära och eller relaterade inläggs-widgets och plugin är hemska. De har vanligtvis tunga förfrågningar över hela webbplatsen.
- Bildoptimeringsplugin som komprimerar bilder med din server. Du bör alltid använda ett optimeringsprogram för bildoptimering som optimerar bilder externt.
Om du besöker Kinsta-bloggen och skrollar ner till slutet av ett inlägg, märker du att vi har vad vi kallar ”handplockade” relaterade artiklar. Dessa väljs av oss manuellt och tilldelas inlägget. Detta minskar förfrågan till nästan ingenting och kommer inte att skada prestandan på hela din webbplats. Tar det mer arbete? Ja, men det kan bli ännu bättre eftersom du kan välja vad du vill att läsare ska se.
Så hur gjorde vi det här? Vi använde den fantastiska pluginet Advanced Custom Fields och tilldelade sedan dessa fält till vår bloggposttyp. Detta gör att vi kan söka och tilldela allt relaterat innehåll som vi vill ha till alla våra blogginlägg (se nedan).
Vi rekommenderar också att du håller dig borta från plugin som lägger till en visnings/inläggsräknare till din webbplats, om du inte behöver det. Undvik exempelvis saker som ”792 inlägg” bredvid en användares avatar i foruminlägg eller ”5 243 visningar” när du listar foruminlägg. När du har en lång diskussion, kommer dessa räknare ta enorm med resurser från din databas. I allmänhet, minimera användningen av räknare och använd dem endast om det behövs.
Detta gäller också många sociala räknare. Till exempel, på denna sida nedan kan du se att svarstiden från det populära pluginet Social Warfare är 30x mer än nästa plugin under den. Cachning är aktiverat, men självklart har detta plugin en betydande prestandaförgift. Efter att inaktivera plugin-enheten på webbplatsen förbättrades laddningstiden direkt och responsen på WordPress adminkontrollpanelen förbättrades.
Använd ett Innehållsleveransnätverk (CDN)
CDN är kort för innehållsleveransnätverk. Dessa är ett nätverk av servrar (även kända som POPs) som finns runt om i världen. De är utformade för att vara värd för och leverera kopior av ditt WordPress-webbplats statiska (och ibland dynamiska) innehåll som bilder, CSS, JavaScript och videoströmmar.
Först och främst vill du inte förvirra ett CDN med din WordPress-värd. Dessa är helt separata tjänster. Ett CDN är inte en ersättning för din värdleverantör, utan snarare ett ytterligare sätt att öka din webbplats hastighet. Medan vår hosting här på Kinsta är blixtsnabb, kan ett CDN göra din webbplats ännu snabbare.
Hur ett CDN fungerar
Hur fungerar ett CDN exakt? Tja, till exempel när du hostar din webbplats med Kinsta måste du välja en fysisk datacenterplats, till exempel USA, Europa, Asien-Stillahavsområdet eller Sydamerika.
Låt oss säga att du väljer US Central. Det innebär att din webbplats ligger fysiskt på en ”värdserver” i Council Bluffs, Iowa. När människor över i Europa besöker din webbplats kommer det att ta längre tid för den att ladda mot någon som besöker den från t.ex. Dallas, TX.
Varför? Eftersom data måste resa ett längre avstånd. Detta är vad som är känt som latens. Latens avser tid och eller fördröjning som är inblandad i överföringen av data över ett nätverk. Ju längre avstånd desto större latens.
Typer av CDN
Det finns två olika typer av innehållsleveransnätverk:
- Traditionellt CDN
- Omvänt Proxy CDN
Traditionellt CDN cachar en kopia av allt innehåll och media, men en begäran från klienten görs fortfarande direkt till din webbleverantör. KeyCDN och CDN77 är exempel på traditionella CDN.
Ett omvänt proxy-CDN är något annorlunda. Medan det fortfarande fungerar som ett CDN, avlyssnar det alla inkommande förfrågningar och fungerar som en mellanliggande server mellan klienten och din värd. Cloudflare och Sucuri är exempel på omvänt proxy-CDN. Det här är en anledning till att du måste rikta din DNS direkt till dessa leverantörer istället för din värd.
Fördelen med dessa är att de fungerar som en mellanliggande server, de kan tillhandahålla starka webbapplikationsbrandväggar som kan hjälpa till att blockera den dåliga trafiken från att någonsin träffa din WordPress-webbplats och eller värdleverantör. En nackdel till detta är att de kommer med lite extra kostnader när det gäller prestanda jämfört med ett traditionellt CDN. Men med ytterligare prestanda och säkerhetsfunktioner kan detta hävdas som försumbart.
Nedan är ett exempel på vad som hände efter att Sucuri aktiverades på en kunds webbplats. Som du kan se hade det en dramatisk inverkan på hur mycket dålig trafik som kom igenom. I slutändan kan dessa typer av tjänster hjälpa dig att spara på dina värdkostnader.
CDN Hastighetstest
Tidigare talade vi om de stora fördelarna med WordPress-cachning. Tja, CDN-cachning är också super kraftfull. Detta beror på att CDN-enheter normalt har mycket mer serverplatser än webbhotell. Det innebär att de kan cacha alla dina tillgångar (bilder, JS, CSS) närmare dina besökare och servera dem med blixtsnabba hastigheter.
Låt oss göra några snabba tester för att se hur mycket snabbare din webbplats kan vara med ett CDN.
Utan CDN
Vår testwebbplats är hostad på Kinsta och ligger fysiskt i Iowa, USA datacenter. Vi körde först fem hastighetsprov i Pingdom (utan CDN aktiverad) och tog medeltalet. Viktigt: Vi använder platsen i Europa – Storbritannien – London i Pingdom för att visa den verkliga kraften hos ett CDN. Den totala laddningstiden var 1,03 s.
Med CDN
Vi aktiverade sedan vår CDN och körde fem ytterligare hastighetsprov i Pingdom. Vår totala laddningstid är nu 585 ms. från Pingdom-testplatsen i Europa – Storbritannien – London. Så genom att använda CDN kunde vi sänka våra sidladdningstider med 43,2 %! Det är enormt.
Anledningen till en sådan drastisk skillnad är att CDN:t har ett datacenter i London. Det betyder att alla tillgångar är cachade på den platsen och redo att serveras med minimal latens.
TTFB utan CDN
Kom ihåg att det gula fältet i Pingdom står för väntetiden, vilket är tid för första byte (TTFB). På våra hastighetsprov utan CDN var den genomsnittliga TTFB på tillgångar runt 98 ms.
TTFB med CDN
När vi aktiverat CDN, sjönk den genomsnittliga TTFB på tillgångar till i genomsnitt 15 ms. Så genom att använda ett CDN sjönk vår genomsnittliga TTFB med 84,69 %. Detta beror främst på att tillgångarna serverades direkt från CDN:s cache.
Hur du aktiverar ett CDN
Att aktivera ett CDN på din WordPress-webbplats behöver inte vara svårt, det är ganska enkelt! Följ bara dessa steg.
Steg 1
Välj en CDN-leverantör och prenumerera på deras tjänst. Dessa debiteras vanligtvis månatligt eller efter dataanvändning. De flesta leverantörer kommer att ha en räknare för att uppskatta dina kostnader.
- Om du är intresserad av att aktiver KeyCDN själv rekommenderar vi att du läser den här artikeln på CDN för dummies. Varje CDN-leverantör bör också ha dokumentation för att hjälpa dig att komma igång.
- Vi har djupgående handledning om hur man installerar Cloudflare och hur man installerar Sucuri.
Steg 2
Om du använder ett traditionellt CDN kan du använda gratisplugin som CDN Enabler, WP Rocket eller Perfmatters för att integrera den med din WordPress-webbplats. Dessa plugins kopplar automatiskt dina tillgångar till CDN. Det behövs inget arbete från din sida för att få ditt innehåll på CDN; det här är helt hands-off! Omvända proxy-CDN:er kräver vanligtvis inga plugin, men ibland har de dem för att aktivera ytterligare funktioner.
Hur du aktiverar Kinstas CDN
Gillade du de här CDN-testen ovan? Vi använde KeyCDN i dessa test. Den goda nyheten är att vår Kinsta CDN drivs av KeyCDN. Det är ett HTTP/2 och IPv6-aktiverat innehållsleveransnätverk med 200+ platser, för att turboladda dina tillgångar och media runt om i världen. För närvarande inkluderar servade regioner Amerika, Sydamerika, Europa, Afrika, Asien och Australien.
Om du är en Kinsta-klient, inkluderar vi gratis CDN-bandbredd på alla våra värdplaner. Du kan aktivera Kinsta CDN i två enkla steg.
Steg 1
Logga in först på din MyKinsta-instrumentpanel. Klicka på din webbplats och sedan på Kinsta CDN-fliken.
Steg 2
Klicka sedan på ”Aktivera Kinsta CDN”. Efter några minuter distribueras CDN automatiskt, och dina tillgångar kommer att fungera från cache runt om i världen. Det är allt som krävs. 😄
Ytterligare CDN-optimeringar
Här är några extra CDN-optimeringar som du kanske vill kolla in eller tänka på.
- Om du har många kommentarer kan gravatarer generera många begäranden. De laddas från
secure.gravatar.com. Kolla in den här guiden om hur du laddar gravatarer från ditt CDN istället. Vi gör detta på Kinstas hemsida. 👍 - Du kan hosta dina anpassade webbtypsnitt från ditt CDN eller till och med Google-teckensnitt på ditt CDN. Kolla in vår djupgående handledning om lokala teckensnitt.
- Se till att ladda din favicon från ditt CDN. Även om det är litet, räknas varje förfrågan!
Lasta av Media och Email Vid Behov
Allt som genererar en förfrågan påverkar din webbplats på ett eller annat sätt. För webbplatser med hostar hundratusentals filer eller stora medier kan det vara klokt att lasta av detta helt. Avlastning är annorlunda än att servera via ett CDN. Med ett CDN ligger det ursprungliga data fortfarande hos din värd, CDN har helt enkelt flera kopior av det.
När cachen löper ut på dina CDN-tillgångar, frågar den din värd om de senaste kopiorna av filerna. CDN:er är avsedda att lagra filer under långa perioder. Men på grund av det faktum att de har så många POP-enheter, kan det hända att en stor efterfrågan pågår eftersom cachen löper ut i olika regioner.
När du avlastar media eller filer betyder det att du faktiskt flyttar dess ursprungliga fysiska plats från din värdleverantör. Så medan det kan tyckas att filerna serveras från din webbplats, är de verkligen helt placerade någon annanstans. Förutom att minska ytterligare frågor tillbaka till värden är den främsta orsaken att också spara på diskutrymme.
Lasta av Media till Amazon S3
En av de mest populära avlastningslösningarna är Amazon S3. Amazon S3 är en lagringslösning, och en del av Amazon Web Services många produkter. Vanligtvis används detta för stora webbplatser som antingen behöver extra säkerhetskopior eller levererar stora filer (nedladdningar, program, videor, spel, ljudfiler, PDF-filer, etc.). Amazon har bevisad förmåga att vara väldigt pålitlig, och på grund av sin enorma infrastruktur kan de erbjuda mycket låga lagringskostnader. Några av S3s kunder inkluderar Netflix, Airbnb, SmugMug, Nasdaq, etc.
Eftersom de helt och hållet handlar med masslagring kan du nästan garantera att prissättningen blir billigare än din WordPress-värd. Avlastning av media till AWS kan vara ett bra sätt att spara pengar och är gratis under ditt första år (upp till 5 GB lagring). Dessutom, eftersom begäran om dina media serveras direkt från Amazon, innebär det mindre belastning på din WordPress-webbplats, vilket innebär snabbare laddningstider.
Kolla in vår djupgående handledning om hur du avlastar WordPress-media till Amazon S3. Du kan också använda ett CDN med de avlastade medierna för det bästa av båda världar.
Lasta Av Media till Google Cloud Storage
En annan populär avlastningslösning är Google Cloud Storage. Eftersom Kinsta drivs av Google Cloud Platform är vi stora fans av deras teknik och infrastruktur. På grund av Googles massiva infrastruktur och det faktum att de hanterar lagring i mängder, kan de erbjuda mycket låga lagringskostnader. Några av deras kunder inkluderar Spotify, Vimeo, Coca-Cola, Philips, Evernote och Motorola.
Kolla in vår djupgående handledning om hur du avlastar WordPress-media till Google Cloud Storage.
Lasta av Transaktionella och marknadsförings-email
Oavsett om du tror det eller inte, påverkar e-postmeddelanden din server och serverresurser. Med vissa värdar, särskilt delade värdar, kan missbruk av detta till och med få dig att stängas av. Detta blir speciellt ett problem för dem som försöker skicka massutskick. Det här är anledningen till att tredjeparts e-postleverantörer finns och varför många hostingföretag blockerar e-postleverans på standardportar helt och hållet. Vi rekommenderar aldrig att du använder ditt webbhotell för e-post.
Om du skickar nyhetsbrev eller mass-email rekommenderar vi alltid följande alternativ för att få de bästa resultaten:
- Använd en tredjeparts professionell e-postmarknadsförings-programvara som inte ingår i WordPress
- Använd en transaktionsleverantör av e-posttjänster (HTTP API eller SMTP) tillsammans med WordPress
Andra fördelar med att använda en tjänst från tredje part är:
- Bättre leverans av e-post. Låt e-postleverantörerna göra vad de gör bäst!
- Mindre chans att bli svartlistad.
- Det kanske inte alltid är möjligt att ställa in DMARC-poster med din webbleverantör.
Email Marketing Tools
Några exempel på marknadsförings-email inkluderar nyhetsbrev, produkt- och funktionsmeddelanden, försäljning, evenemangsinbjudningar, påminnelser ombord osv. Här är några e-postmarknadsverktyg vi rekommenderar:
- MailChimp – Vi använder MailChimp på Kinsta.
- MailerLite
- Drip
Transaktionella Email-tjänster
Några exempel på transaktions-e-postmeddelanden inkluderar köpkvitton från WooCommerce eller EDD, meddelanden om kontoskapande, leveransmeddelanden, appfelmeddelanden, lösenordsåterställningar, etc. Om du är en Kinsta-klient förlitar vi oss på en tredjeparts SMTP-leverantör för att säkerställa hög leveransbarhet . Men beroende på din volym rekommenderar vi alltid att flytta den här från platsen. Här är några e-posttjänster för transaktioner som vi rekommenderar:
- SendGrid – We use SendGrid at Kinsta.
- Mailgun – Se hur du konfigurerar Mailgun i WordPress.
- SparkPost
Hur du hittar Flaskhalsar och Långsamma Plugin
Nu dyker vi in i några tips om hur man hittar flaskhalsar på din WordPress-webbplats och vad du kan göra åt det.
Använd New Relic för att identifiera långsamma plugin och databasförfrågningar
Det finns några bra verktyg på marknaden som kan hjälpa dig att hitta och identifiera långsamma databasfrågor och plugin som förbrukar mycket tid. Vi är stora fans av New Relic på Kinsta och använder det dagligen. New Relic är ett PHP-övervakningsverktyg som du kan använda för att få detaljerad resultatstatistik på din webbplats.
Om du är en Kinsta-klient kan du till och med lägga till din egen New Relic-licensnyckel på vår MyKinsta-instrumentpanel.
Använd dock New Relic med försiktighet eftersom det påverkar webbplatsens prestanda. Det lägger till JavaScript på din webbplats. Vi rekommenderar att du aktiverar det när du behöver felsöka prestanda och sedan inaktiverar det efteråt.
Hitta långsamma plugins
När ett WordPress-plugin orsakar generell tröghet kommer symtomen att variera beroende på vilken aktivitet pluginprocessen utför. Men i många fall kommer du att upptäcka att ett långsamt plugin påverkar varje sida på en WordPress-webbplats. När det gäller webbplatsen vars data du ser på bilden nedan observerades övergripande långsamhet på varje front-endsida på webbplatsen. Här är vad New Relic hade att säga om utförandet av plugins på webbplatsen.
Omedelbart kan du se att adinjector-pluginget förbrukar mer än 15 gånger så mycket tid som det näst långsammaste pluginet.
När du ser data som detta kan det vara frestande att omedelbart avvisa pluginet som dåligt kodad eller på något sätt ineffektiv. Även om detta ibland är fallet är det inte alltid fallet. Felkonfigurerade plugin, databashastighet eller externa resurser som är svaga att reagera kan leda till att ett plugin spenderar mycket tid.
Så när du ser ett plugin som svarar långsamt, är det en bra idé att kolla flera andra skärmar i New Relic för att hitta ytterligare information. Transaktionerna, databaser och externa resurser bör alla kontrolleras innan du beslutar att avaktivera pluginet.
Övergripande Långsamhet orsakad av en överväldigad databas
En dåligt optimerad databas kan orsaka generell långsamhet på en WordPress-webbplats. Tidigare gick vi över många olika saker du kan göra för att åtgärda detta. I New Relic kommer denna databasrelaterade långsamhet sannolikt att dyka upp på två ställen:
- Först får du se en stor mängd MySQL-aktivitet i översikten.
- För det andra ser du att en eller flera databastabeller använder mycket tid under fliken Databaser.
Med början i översiktsskärmen kan en webbplats med en kämpande databas se ut så här:
För att få bättre grepp av vilken databastabell eller -förfrågan som orsakar problemet, gå till fliken Databaser.
Fliken Databaser pekar ut tabellen och typen av förfrågan som förbrukar mest tid. Om du väljer en av posterna i listan kan du se mer detaljer, inklusive några exempelfrågor.
I det här fallet pekar data på autoladdade data i wp_options-tabellen. Kom ihåg att vi gick över det tidigare. Visst nog, en snabb analys av wp_options-tabellen bekräftar att nästan 250 MB data är autoladdat från den här tabellen, vilket gör denna webbplats till en uppenbar kandidat för databasunderhåll och optimering.
Se till att kolla in vår djupgående handledning om hur du använder New Relic för att felsöka prestandafrågor på din WordPress-webbplats.
Använd gratispluginet Query Monitor
Du kan också använda gratispluginet Query Monitor för WordPress. Använd den för att identifiera och felsöka långsamma databasförfrågningar, AJAX-anrop, REST API-förfrågningar och mycket mer. Dessutom rapporterar pluginet webbplatsinformation, till exempel skriptavhängigheter och beroenden, WordPress-krokar som avfyrades vid sidgenerering, värdmiljöinformation, villkorliga sökord taggade med den aktuella sidan och mycket mer.
Pluginet utvecklades av John Blackbourn, en WordPress-kärnutvecklare som för närvarande är utvecklare hos Human Made och tidigare anställd av WordPress VIP – med andra ord någon som känner till WordPress i stor utsträckning. Query Monitor lades till i WordPress-pluginkatalogen under 2013 och har för närvarande över 10 000 aktiva installationer – en imponerande summa för ett utvecklingsplugin. Pluginet användarbedömning av fem ut fem stjärnor hjälper till att förklara dess popularitet bland utvecklare.
Kolla in vår kompletta handledning om hur du använder Query Monitor.
Använd Staging-webbplatser utan att störa produktionssidor
Vi vet inte vad vi skulle göra utan stagingmiljöer. Dessa kan vara ovärderliga när det gäller felsökning av prestandafrågor. Lyckligtvis har Kinsta ett-klick-staging-miljöer. Om din WordPress-värd inte erbjuder staging-miljöer kan du också använda ett plugin som WP Staging, även om det inte är så enkelt.
När du har startat en stagingwebbplats är det första du kan göra att inaktivera alla dina plugin. Eftersom det här är en kopia av din levande webbplats behöver du inte oroa dig för att förstöra någonting. Det är överlägset ett av de enklaste sätten att begränsa problem. Gå bara till Plugin, välj dem alla och välj ”Avaktivera” från bulkalternativen.
Efter det har du möjlighet att övervaka svarstiderna i New Relic eller Query Monitor och se vad som händer. I det här exemplet föll svarstiderna omedelbart tillbaka till det normala på sajten, så vi visste att det var en av pluginsen som orsakade ett problem. Du kan sedan aktivera dem en efter en, upprepa samma process tills du hittar den skyldige.
Här är ett exempel på vad som hände när vi aktiverade det plugin som orsakade problemet. Laddningstider (webbtransaktionstider) gick omedelbart tillbaka upp.
Vad ska du göra när du hittar det plugin som orsakar långsamheten? Här är vad vi rekommenderar:
- Uppdatera dina plugins och teman till den senaste versionen om du inte redan har det.
- Nå ut till utvecklaren av pluginet eller temat och be dem om hjälp.
- Hitta ett alternativt plugin som kan leverera samma funktionalitet.
- Kanske är det din PHP-version som orsakar ett problem. Ändra din PHP-motor till en lägre version och se om pluginet eller temat då fungerar.
Du kan också anställa en WordPress-utvecklare för att åtgärda problemet. Om det är prestationsrelaterat måste vi ge en personlig eloge till Mike Andreason på WP Bullet. Han är en Codeable-utvecklare på heltid som specialiserat sig på prestationsoptimering, som har hjälpt många kunder här på Kinsta med komplexa installationer ta sin plats till nästa nivå.
Kolla dina Felloggar
Att kontrollera felloggar är aldrig kul, men kan avslöja mycket om prestandafrågor med WordPress-plugin. Om du är en Kinsta-kund kan du enkelt se dina felloggar, cacheloggar och åtkomstloggar direkt från MyKinsta-instrumentpanelen.
Du kan också aktivera felloggar genom att lägga till en kod i din wp-config.phpfil. Först vill du ansluta till din webbplats via SFTP. Hämta sedan din wp-config.php så att du kan redigera den. Obs! Gör alltid en säkerhetskopia av den här filen först!
Hitta raden som säger /* That's all, stop editing! Happy blogging. */ och precis före det, lägg till följande (som sett nedan):
define( 'WP_DEBUG', true );
Om den ovanstående koden redan finns i din wp-config.php-fil men är inställd på ”false”, ändrar du den till ”true”. Det här aktiverar felsökningsläget. Obs! Du kommer också att se varningar eller fel i din WordPress-admin om de finns.
Du kan sedan aktivera felsökningsloggen för att skicka alla fel till en fil genom att lägga till följande kod strax efter WP_DEBUG-raden (se nedan):
define( 'WP_DEBUG_LOG', true );
Spara dina ändringar och ladda upp det här till din server. Felen kommer då att loggas till debug.log-filen i din /wp-content/-mapp. Om du av någon anledning inte ser den här filen kan du alltid skapa en.
Använd MyKinsta Analytics
Om du är en Kinsta-klient kan du dra nytta av de prestanda-insikter vi har byggt in i vårt MyKinsta Analytics-verktyg.
Under prestationsövervakningsdelen kan du se din genomsnittliga PHP + MySQL-svarstid, PHP-genomströmning, AJAX-användning, högsta genomsnittliga uppströmstid och högsta maximala uppströmstid.
Genomsnittlig PHP + MySQL-svarstid
När du besöker din WordPress-webbplats används PHP och MySQL för att kompilera och fråga de uppgifter du ser på sidan. I det här diagrammet visas den genomsnittliga svarstiden för PHP-motorn och MySQL-motorn för alla icke-cachade dynamiska förfrågningar. Att känna till dessa svarstider kan hjälpa dig att felsöka långsamhet.
PHP-genomströmning
Genomströmning anger antalet transaktioner per sekund som en applikation kan hantera, och i denna rapport refererar det till PHP-genomströmning från din WordPress-webbplats. Med andra ord visar det hur många gånger en PHP-tillgång begärdes.
AJAX-användning
AJAX är ett kundskript som kommunicerar till och från en server/databas utan att behöva en postback eller en fullständig siduppdatering. När det gäller WordPress har många av er säkert sett detta i dina hastighetsprov. De två främsta problemen med AJAX inkluderar plugin som orsakar toppar och CPU-problem på back-end.
Se till att kolla in vårt djupgående inlägg om hur du diagnostiserar hög Admin-AJAX-användning på din WordPress-webbplats.
AJAX-användningsrapporten i MyKinsta-analys kan vara ett bra sätt att hjälpa dig att felsöka dessa typer av problem, eftersom du kan se om du har vissa AJAX-toppar under vissa perioder. I det här diagrammet visas antalet admin-ajax-förfrågningar. Du kan sedan använda några av de tips som vi nämnde ovan för att begränsa var de kommer ifrån.
Högsta genomsnittliga PHP + MySQL-svarstid
Den här listan visar de högsta genomsnittliga svarstiderna från PHP och MySQL. Dessa siffror kan vara enstaka toppar, så det rekommenderas att jämföra denna lista med ”Högsta Maximala Uppströmstid.”
Högsta Maximala Uppströmstid
Uppströmstid är den totala tiden som tas för Nginx (och uppströmsservrar) att behandla en förfrågan och skicka ett svar. Tiden mäts i sekunder, med millisekundsupplösning. Läs mer om Nginx-mätvärden.
Din webbplats kan vara hackad
Om du har problem med att spåra en prestandafråga kan det vara så att din webbplats hackats, infekterats med skadlig kod eller genomgått en DDoS-attack. Detta kan påverka din webbplats hastighet och till och med responsen på din WordPress adminkontrollpanel. I dessa fall rekommenderar vi följande:
- Implementera en proxyserver och WAF som Cloudflare eller Sucuri.
- Blockera dåliga IP-adresser med hjälp av ovanstående tjänster eller om du är en Kinsta-klient kan du också blockera IP-adresser från vår MyKinsta-instrumentpanel.
- Du kan också genomföra geoblockering. Vissa länder är verkligen dåliga när det gäller kvaliteten på den trafik de genererar. Om du är under attack kan du behöva blockera hela landet, antingen tillfälligt eller permanent.
Felsökning med felkoder (HTTP Statuskoder)
HTTP statuskoder är som en kort not från webbservern som kläms fast på toppen av en webbsida. Det är inte en del av webbsidan. Istället är det ett meddelande från servern som låter dig veta hur det gick när begäran om att visa sidan mottogs av servern. Dessa kan vara ovärderliga när det gäller felsökning!
Det finns över 40 olika statuskoder, men nedan är de vanliga som vi ser WordPress-användare som kämpar med.
429: ”För många förfrågningar.” Genereras av servern när användaren har skickat för många förfrågningar under en viss tid (hastighetsbegränsning). Detta kan ibland hända genom att bots eller skript som försöker komma åt din webbplats. I det här fallet kanske du vill försöka ändra din WordPress inloggningsadress.
500: ”Det uppstod ett fel på servern och begäran kunde inte slutföras.” En generisk kod som helt enkelt betyder ”internt serverfel”. Något gick fel på servern och den begärda resursen levererades inte. Den här koden genereras vanligen av tredje parts-plugin, felaktig PHP, eller till och med att anslutningen till databasen bröts. Kolla in våra handledningar om hur du åtgärdar felet att upprätta en databasanslutning och andra sätt att lösa ett internt 500-serverfel.
502: ”Bad Gateway.” Denna felkod innebär normalt att en server har fått ett ogiltigt svar från en annan. Ibland tar en förfrågan eller begäran för lång tid, så det avbryts eller dödas av servern och anslutningen till databasen raderas. Kolla in vår djupgående handledning om hur du fixar felet 502 Bad Gateway.
503: ”Servern är inte tillgänglig för att hantera den här förfrågan just nu.” Förfrågan kan inte slutföras just nu. Den här koden kan returneras av en överbelastad server som inte kan hantera ytterligare förfrågningar.
504: ”Servern som fungerade som en gateway slutade vänta på att en annan server skulle svara.” Koden återvände när det finns två servrar som är inblandade i behandlingen av en förfrågan och den första servern slutar vänta på att den andra servern ska svara. Läs mer om hur du fixar 504 fel.
Du kan också gräva i dessa HTTP-svarskoder i vårt MyKinsta Analytics-verktyg. Vår svarskodsdetaljrapport gör det möjligt att se en översikt över fördelningen av HTTP-statuskoder som visas för de begärda resurserna.
Svarstatistikrapporten låter dig se det totala antalet omdirigeringar som händer, fel, framgångsfrekvens och felförhållande. Varje WordPress-webbplats kommer normalt att ha ett litet felprocentförhållande; det här är helt normalt.
Det finns sedan detaljerade rapporter för varje typ av felkod, till exempel 500 fel, 400 fel, omdirigeringar, etc.
Rekommendationer för Back-End-Optimering
Nu dyker vi ner på några sätt som du kan påskynda WordPress genom att optimera back-end. Back-end innebär vanligtvis allt som hanteras helt av servern, till exempel PHP, HTTP-cacherubriker, GZIP-komprimering etc.
Skapa en lätt 404-sida
Vi har sett med egna ögon hur högst dynamiska webbplatser vanligtvis genererar många 404 fel. Din webbplats kan generera mer än du tror! Vårt MyKinsta-analysverktyg kan hjälpa dig att bestämma det exakta antalet (se nedan).
Anledningen till att dessa fel är dåliga är att många 404-sidor är mycket resursintensiva. För en högst dynamisk WordPress-webbplats, bör du undvika en tung 404-sida. Skapa en enkel 404-mall som undviker att fråga databasen vidare, om möjligt. Och självklart, tillbringa lite tid och åtgärda 404-fel eftersom det inte bara är resursintensivt, det är helt enkelt dåligt för användarupplevelsen.
Förutom att utnyttja en lätt 404-sida, rekommenderar vi även att det implementeras en särskild sidcache-regel för 404-sidor. På Kinsta cachelagrar vi automatiskt 404-sidor i 15 minuter. Om vår webbserver upptäcker att en ny sida med samma URL-adress som en cache-lagrad 404-sida har skapats, rensar vi automatiskt bort cachen. Om din WordPress-webbplats inte kan cache-lagra 404-sidor, rekommenderar vi att du ber din host lägga till denna förmåga till din webbserver.
Öka PHP-Workers
PHP workers kan vara en term som du aldrig hört talas om, men de är hur många värdar, inklusive Kinsta, hanterar begränsning av förfrågningar (i stället för att begränsa dig med CPU eller RAM, vilket vanligtvis är vad delade hosting-leverantörer gör).
PHP-workers bestämmer hur många samtidiga förfrågningar din webbplats kan hantera vid en given tidpunkt. För att uttrycka det enkelt hanteras varje ocachade förfrågan på din webbplats av en PHP-worker. Om du till exempel har 4 förfrågningar som kommer till din webbplats på exakt samma gång och din webbplats har 2 PHP-workers, kommer två av dessa förfrågningar att behandlas medan de andra två måste vänta i kön tills de två första är färdiga med bearbetningar.
Kom ihåg att vi diskuterade tidigare att ett av de största problemen med WordPress-medlemskapswebbplatser är alla de ocachade förfrågningarna. Det är därför som PHP-workers blir mycket viktiga eftersom de måste göra arbete för varje förfrågan. Därför kommer dessa webbplatser normalt att kräva ytterligare PHP-workers för att säkerställa att varje förfrågan behandlas utan förseningar och slutförs framgångsrikt.
Vad händer om du kontinuerligt maximerar dina PHP-workers? I grunden börjar kön att trycka fram på äldre förfrågningar som kan resultera i 500 fel på din webbplats. Vart och ett av Kinstas webbhotellsplaner innehåller ett fördefinierat antal PHP-workers. Om du har problem med att uppskatta vad din webbplats kan behöva, kan du alltid chatta med vårt försäljnings- eller supportteam.
Använd GZIP-Komprimering
GZIP är ett filformat och ett program som används för filkomprimering och dekompression. GZIP-komprimering är aktiverad på servern och möjliggör ytterligare minskning av storleken på din HTML, stylesheets och JavaScript-filer.
När en webbläsare besöker en webbplats kontrollerar den att se om webbservern har GZIP aktiverad genom att se om content-encoding: gzip HTTP-rubriken existerar. Om rubriken är detekterad, servar den de komprimerade och mindre filerna. Om inte, servar den upp de o-komprimerade filerna. Om du inte har GZIP aktiverad kommer du med största sannolikhet att se varningar och fel i hastighetstestverktyg som Google PageSpeed Insights och GTmetrix.
Att aktivera GZIP-komprimering kan hjälpa till att minska storleken på din webbsida, vilket kan minska tiden för att ladda ner resursen, minska dataanvändningen för klienten och förbättra tiden att först rendera dina sidor. Det här är ganska standard nu över de flesta webbhotell, men inget överraskar oss längre.
Aktivera Hotlinking-skydd
Konceptet hotlinking är ganska enkelt. Du hittar en bild på internet någonstans och använder webbadressen till bilden direkt på din webbplats. Denna bild kommer att visas på din webbplats men den kommer att serveras från den ursprungliga platsen. Det här är väldigt bekvämt för hotlänkaren, men det är faktiskt stöld eftersom det använder den länkade webbplatsens resurser. Det är som om vi skulle sätta oss i bilen och köra bort med bensin vi stulit från vår grannes bil.
Hotlinking kan vara tära enormt på resurser för målservern. Tänk dig att du är på en delad WordPress-värd och plötsligt Huffington Post länkar till dina bilder. Du kan gå från ett par hundra förfrågningar per timme på din webbplats till ett par hundra tusen. Detta kan till och med resultera i en avstängning av ditt värdkonto. Det här är en anledning att inte bara använda en högpresterande värd (som kan hantera problem som detta), men också för att aktivera hotlinking-skydd, så det inte händer.
Kolla in vår handledning om hur du förhindrar hotlinking.
Minimera Omdirigeringar och Lägg till dem på Servernivå
För många omdirigeringar är alltid något du behöver se upp för. Enkla omdirigeringar som en enda 301-omdirigering, HTTP till HTTPS eller www till icke-www (vice versa) är okej. Och många gånger behövs det på vissa områden på din webbplats. Men varje omdirigering har en kostnad på webbplatsens prestanda. Och om du börjar stapla omdirigeringar ovanpå varandra är det viktigt att inse hur de påverkar din webbplats. Detta gäller för omdirigering av sidor och inläggs-omdirigeringar, omdirigeringar av bilder, allting.
En omdirigering kommer att generera en 301 eller 302 på svar-rubrikstatusen.
Hur mycket påverkar omdirigeringen din webbplats? Låt oss göra ett litet test. Först kör vi ett hastighetstest på vår kontaktsida: https://perfmatters.io/contact/. Som ni ser nedan får vi en total laddningstid på 417 ms.
Vi ändrar sedan webbadressen något och kör ett annat hastighetstest för att se effekten av flera omdirigeringar. http://www.perfmatters.io/contact. Som du kan se tar samma sida nu 695 ms. att ladda. Det är en ökning med 66 %. Usch!
Att använda gratis WordPress-plugin för att genomföra omdirigeringar kan ibland orsaka prestandaproblem eftersom de flesta använder sig av wp_redirect-funktionen, vilket kräver ytterligare kodkörning och resurser. Vissa av dem lägger också till autoladdade data till ditt wp_options-tabellen, vilket ökar en redan uppblåst databas. Lägg till dem på servernivå där de ska utföras. Vi tillåter dig att göra det på MyKinsta med vårt omdirigeringsreglerverktyg.
Du kan också se en fullständig sammanfattning av hur många omdirigeringar som händer på dina webbplatser i vårt MyKinsta-analysverktyg. Se totalt antal 301, 302 och 304.
Kolla in vårt djupgående inlägg om WordPress-omdirigeringar och de bästa metoderna för snabbare prestanda.
Tappa inte kontrollen över dina Cron-Jobb
CRON-jobb (WP-Cron) används för att schemalägga upprepade uppgifter för din WordPress-webbplats. Men med tiden kan dessa komma ur kontroll och orsaka prestandafrågor. Du kan använda gratispluginet WP-control för att kontrollera ett handtag på alla Cron-jobb som händer på din webbplats.
Vi har också sett prestationsproblem med den inbyggda Cron-hanteraren för WordPress: WP-Cron. Om en webbplats inte har tillräckligt med PHP-workers, kommer ibland en begäran att komma in, WordPress kommer att skapa cronen, men cronen måste vänta på workern och sitter därmed bara där. Ett bättre tillvägagångssätt är att inaktivera WP-Cron och använd systemets cron istället. Detta rekommenderas till och med i den officiella pluginhandboken.
För att inaktivera WP-Cron, lägg till följande i din wp-config.php-fil, precis före raden som säger ”That’s all, step editing! Happy blogging.” Obs! Det här inaktiverar det från att köra vid sidladdning, inte när du åberopar det direkt via wp-cron.php.
define('DISABLE_WP_CRON', true);
Du måste då schemalägga wp-cron.php från din server. Om du är en Kinsta-klient är system-cron redan aktiverade och körs var 15: e minut som standard. Du kan också öka frekvensen genom att nå ut till vårt supportteam. Om du är bekant med SSH kan du hantera server-cron från kommandoraden.
Lägg till Cache-Kontroll och Expires-Rubriker (Avgör cache-längd)
Varje skript på din WordPress-webbplats behöver ha en HTTP-cacherubriker kopplad till den (eller den borde). Detta bestämmer när cachen på filen löper ut.
För att åtgärda detta måste du försäkra dig om att din WordPress-värd har rätt cache-control-rubrik och expires-rubrikinställningar. Om du inte gör det kommer du med största sannolikhet att se varningar om att behöva lägga till expires-rubriker eller utnyttja webbläsarens cachning i hastighetstestverktyg.
Medan cache-control-rubriken slår på cachen på klientsidan och anger maximal ålder för en resurs används expires-rubriken för att ange en specifik tidpunkt som resursen inte längre är giltig. Medan båda rubrikerna kan användas tillsammans behöver du inte nödvändigtvis lägga till båda rubrikerna. Cachekontrollen är nyare och vanligtvis den rekommenderade metoden.
Kinsta lägger automatiskt till HTTP-cacherubriker på alla serverns förfrågningar, och om du använder ett CDN, kommer de med största sannolikhet att lägga till dessa rubriker för dig också.
Om servern saknar dessa rubriker kan du manuellt lägga till dem.
Lägga till Cache-Control Rubriker i Nginx
Du kan lägga till cache-control-rubriker i Nginx genom att lägga till följande på din serverconfigs serverplats eller block.
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}Lägga till Expires-rubriker i Nginx
Du kan lägga till expires – rubriker i Nginx genom att lägga till följande i ditt serverblock. I det här exemplet kan du se hur du anger olika utgångstider baserat på filtyper.
location ~* \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* \.(pdf|css|html|js|swf)$ {
expires 2d;
}Lägga till Cache-Control-rubriker i Apache
Du kan lägga till cache-control i Apache genom att lägga till följande i din .htaccess-fil. Delar av kod kan läggas till överst eller längst ner i filen (före # BEGIN WordPress eller efter # END WordPress).
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>Lägga till Expires-rubrik i Apache
Du kan lägga till expires-rubriker i Apache genom att lägga till följande i din .htaccess file.
.htaccess file.
## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##Det är också viktigt att notera att du bara kan lägga till HTTP-cacherubriker på resurser på din server. Om du får en varning om det kanske du behöver utnyttja webbläsarens cachning på begäran av tredje part, det finns inget du kan göra, eftersom du inte har förfrågan över deras server. Vanliga syndabockar inkluderar Google Analytics-skript och marknadsföringspixlar, som Facebook och Twitter.
Om du försöker fixa det här med Google Analytics-skriptet kan du hosta det lokalt eller på ditt CDN (även om det inte stöds officiellt) med ett plugin som Perfmatters eller WP Rocket.
Lägg till Last-Modified och ETag Rubriker (Validera Cache)
Därefter har vi ytterligare två uppsättningar av rubriker, last-modified och etag.
Medan cache-control och expires-rubriker hjälper webbläsaren att avgöra om filen har ändrats sedan den sista gången den begärdes (eller snarare, de validerar cacheminnet).
Headern last-modified och etag validerar båda och bestämmer längden på lagringen och bör vara inkluderad på varje ursprungsservers svar. Om dessa inte är ordentligt inställda kan du få en varning om att du måste ”Ange cache-validering.”
Om rubrikerna inte hittas kommer det att generera en ny begäran om resursen varje gång, vilket ökar belastningen på din server. Genom att använda cachnings-rubriker säkerställs att efterföljande förfrågningar inte behöver laddas från servern, vilket sparar bandbredd och förbättrar prestanda för användaren.
Kinsta lägger automatiskt till ovanstående rubriker på alla serverns förfrågningar, och om du använder ett CDN, kommer de med största sannolikhet att lägga till dessa rubriker för dig också. Precis som med cache-control och expires-rubriker, kan du inte manuellt ställa in dessa HTTP-rubriker på externa resurser.
Last-modified-rubrik
Last-modified-rubriken skickas vanligtvis automatiskt från servern. Det här är en rubrik som du inte behöver lägga till manuellt. Det skickas för att se om filen i webbläsarens cache har ändrats senast den senaste gången den begärdes. Du kan titta på rubrikförfrågan i Pingdom eller använda Chrome DevTools för att se värdet på den senast ändrade rubriken.
ETag-rubriken
ETag-rubriken är också mycket lik den senast modifierade rubriken. Det används också för att validera cachen för en fil. Om du kör Apache 2,4 eller senare läggs ETag-rubriken automatiskt till med Fileetag-direktivet. Och så långt som Nginx går, har ETag-rubriken blivit aktiverat som standard sedan 2016.
Du kan aktivera ETag-rubriken manuellt i Nginx med följande kod.
etag onLägg till en Vary: Accept-Encoding-rubrik
vary: Accept-Encoding-rubriken bör inkluderas i varje ursprungsserverrespons, eftersom det berättar för webbläsaren huruvida klienten kan hantera komprimerade versioner av innehållet eller inte. Om det inte är korrekt inställt kan du få en varning om att du måste ”Ange en Vary: Accept-Encoding-Rubrik.”
Låt oss till exempel säga att du har en gammal webbläsare utan gzip-komprimering och en modern webbläsare med den. Om du inte använder vary: Accept-Encoding-rubriken kan din webbserver eller CDN cacha den okomprimerade versionen och leverera den till den moderna webbläsaren av misstag, vilket i sin tur skadar prestandan på din WordPress-webbplats. Genom att använda rubriken kan du se till att din webbserver och eller CDN ger den lämpliga versionen.
Kinsta lägger automatiskt till ovanstående rubriker på alla serverförfrågningar, och om du använder ett CDN, kommer de med största sannolikhet att lägga till dessa rubriker för dig också. Precis som med de andra cacherubrikerna som vi har diskuterat ovan kan du inte manuellt ställa in denna rubrik på externa resurser.
Lägg till Vary: Accept-Encoding-Rubrik I Apache
Du kan lägga till vary: Accept-Encoding-rubriker i Apache genom att lägga till följande i din .htaccess-fil.
<IfModule mod_headers.c>
<FilesMatch ".(js|css|xml|gz|html)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>Lägg till Vary: Accept-Encoding-Rubrik i Nginx
Du kan lägga till vary: Accept-Encoding-rubriker i Nginx genom att lägga till följande kod till din config-fil. Alla Nginxkonfigurationsfiler hittar du i /etc/nginx/ katalogen. Den primära konfigurationsfilen är /etc/nginx/nginx.conf.
gzip_vary on
Ändra WordPress Minnesbegränsning i wp-config.php
Som anges i WordPress Codex, med WordPress Version 2.5, tillåter alternativet WP_MEMORY_LIMIT att du anger hur mycket minne som kan konsumeras av PHP. Denna inställning kan vara nödvändig om du får ett meddelande som ”Tillåten minnesstorlek xxxxxx bytes uttömd”.
Som standard försöker WordPress att öka minnet som allokeras till PHP till 40 MB för en enda webbplats och 64 MB för multisite. De definierar minnesgränserna i filen ./wp-includes/default-constants.php, på raderna 32 – 44 (källa).
Du har då också PHP memory_limit på servern från din webbleverantör. Det här är två olika saker. Vid Kinsta ställer vi standard-memory_limit till 256M. Om du stöter på felet med uttömda minnesstorleken kan du försöka öka PHP-minnesgränsen i WordPress.
Lägg till följande i wp-config.php file, precis före raden som säger ”That’s all, stop editing! Happy blogging.”
define( 'WP_MEMORY_LIMIT', '256M' );
Jan Reilink har också ett bra blogginlägg som beskriver WordPress-minnesgränsfrågan mer detaljerat. Han ger också en variation på koden du kan använda. I stället för att ange mängden manuellt kan du ställa in det till PHP memory_limit-värdet.
define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );
Tips på Front-End-Optimering och Externa tjänster
Nu dyker vi ner i några sätt som du kan påskynda WordPress genom att optimera front-end. Front-end innebär vanligtvis allt som hanteras helt av klientens webbläsare, till exempel CSS, JavasScript, bilder etc. Det här inkluderar även att analysera externa tjänster som du har laddat på din webbplats och hur de påverkar din totala laddningstid.
Två av de viktigaste målen du bör ha när det gäller optimering av fronten är:
- Minska din totala webbsidestorlek. Storleken på din CSS, JavaScript, bilder är viktiga. En 4 MB-webbplats kommer vanligtvis att ladda mycket långsammare än en 1 MB-webbplats. Paul Calvano har dock en bra artikel om sidviktens påverkan på laddningstiden och hur viktigt det är att se till att det inte är det enda du spårar eftersom det ibland kan vara vilseledande.
- Minska HTTP-förfrågningar och externa tjänster. Med HTTP/2 kan flera förfrågningar och svar nu skickas samtidigt med en enda TCP-anslutning. Även om detta är fantastiskt för prestanda, kan minskning av HTTP-förfrågningar fortfarande hjälpa till att påskynda din WordPress-webbplats. Detta inkluderar också att minska det totala antalet externa förfrågningar och tjänster. Var och en av dessa lägger till ytterligare förseningar som DNS-sökning, TLS-anslutningar och nätverkslatens.
Hastighetstesta din WordPress-webbplats för att få en baslinje
När det gäller att optimera front-end på din webbplats är det alltid bra att börja med en baslinje. Detta innebär vanligtvis att du behöver köra ett hastighetstest. Det finns en mängd olika sätt att göra det här, kolla in vår lista med 15 fantastiska testverktyg för webbplatshastighet.
Kolla in våra djupgående guider om hur du använder Pingdom och hur du använder GTmetrix. Här är några saker att tänka på när hastighetsprovning:
1. PVälj ett verktyg och fortsätt med det
Vi är stora fans av Pingdom, GTmetrix, WebPageTest, PageSpeed Insights och Chrome DevTools. Men det spelar ingen roll så mycket vilket hastighetsprovverktyg du använder, utan att du är konsekvent. De har alla olika sätt att mäta och kvantifiera hastighet, så välj ett verktyg och fortsätt använde det genom alla dina test och optimeringar. Även Google säger att välja en.
2. Bli inte besatt över ett perfekt betyg
Många verktyg som Google PageSpeed Insights har alla någon typ av hastighets- eller prestationspoäng. Det är viktigt att komma ihåg att poängen inte alltid betyder så mycket som din webbplats hastighet och uppfattad prestanda av användaren. Poängen är där för att hjälpa dig att mäta hur bra du ligger till. Men att bli besatt över en perfekt 100/100 eller A-betyg kan i vissa fall vara ett slöseri med tid. Och större webbplatser med många externa skript och annonser kommer aldrig att få ett perfekt betyg, vilket är helt ok.
3. Var du placerar dina test spelar roll
Den plats du väljer när du utför hastighetstesterna spelar en roll. Som vi diskuterade i ett tidigare avsnitt beror det på förhållandet till den datacenterplats du väljer. TTFB, nätverkslatens, allt spelar roll. Testa din webbplats både från en plats som ligger nära ditt datacenter och en som är långt borta. Detta hjälper dig också att se hur mycket en effekt ett CDN kan ha på din WordPress-webbplats.
4. Testa flera gånger på grund av cachning
Som vi gick igenom tidigare i avsnittet om cachning, om cachen nyligen har rensats eller har utgått på din WordPress-värd eller CDN, kommer den att registrera en ”MISS” på HTTP-rubriken. Det innebär att din webbplats eller tillgång inte tjänas från cacheminnet.
För att kunna se hela webbplatsens hastighet måste du se allt laddas från cachen, när din första sida och alla tillgångar registrerar en ”HIT”. Det kräver ibland att du kör ditt hastighetstest flera gånger. Du kan då ta medeltalet.
Låt oss nu gå vidare till några optimeringar som du kan göra på din WordPress-webbplats.
Eliminera Renderingsblockerande JavaScript och CSS
En varning om renderingsblockerande JavaScript och CSS kan visas när du har filer som förhindrar att sidan laddas så snabbt som möjligt. Särskilda JS och CSS är ibland villkorliga, vilket innebär att de inte behöver visa innehåll längst upp på sidan. Du kan hindra dem från att blockeras genom att använda async- och defer-attribut.
Kolla in den här videon för att ta reda på mer om hur du eliminerar renderingsblockeringsresurser:
För att eliminera renderingsblockering av JavaScript och CSS måste du göra följande:
Rensa JS från den kritiska renderingsbanan
Flytta JavaScript ut ur den kritiska renderingsbanan görs vanligen genom att lägga till antingen defer eller async-attributet till HTML-elementet för script som anropar JavaScript-resurser.
- Asyncattributet berättar för webbläsaren att hämta resursen direkt utan att sakta ner HTML-parsning. När resursen är tillgänglig är HTML-parsning pausad så att resursen kan laddas.
- Deferattributet berättar att webbläsaren håller på att ladda ner resursen tills HTML-parsning är klar. När webbläsaren har slutfört HTML-filen kommer den sedan att ladda ner och göra alla uppskjutna skript i den ordning de visas i dokumentet.
Optimera leverans av CSS-resurser
Optimering av leveransen av CSS innebär i huvudsak att du behöver räkna ut hur det inte ska blockera rendering.
- Identifiera de stilar som krävs för att göra det övergripande innehållet och leverera dessa stilar i linje med HTML.
- Använd CSS på villkorligt sätt endast på enheter när det behövs.
- Ladda resterande CSS asynkront.
Att göra allt ovan kan ibland vara en knepig process och tar definitivt lite finjustering utifrån de skript som du har laddat på din webbplats. Här är ett par WordPress-plugin som kan hjälpa till:
För en mer detaljerad förklaring och handledning, rekommenderar vi att du kolla in vårt inlägg om att eliminera renderingsblockerande JavaScript och CSS.
Kombinera extern CSS och JavaScript i WordPress
Varningen för kombinera extern CSS ses normalt när du använder ett CDN eftersom du hostar dina CSS-filer på en extern domän, till exempel cdn.domain.com. Tidigare var ett snabbt sätt att fixa detta att sammanfoga dina CSS-filer, eller kombinera dem så att de laddas i en enda förfrågan.
Men om du kör över HTTPS med en leverantör som stöder HTTP/2, är denna varning inte längre så relevant som den brukade vara. Med HTTP/2 kan flera CSS-filer nu laddas parallellt över en enda anslutning. Och över 86 % av webbläsarna stöder HTTP/2.
Men det betyder inte nödvändigtvis att optimeringen är helt död. I vissa fall har vi sett att detta fortfarande snabbar upp WordPress-webbplatser. Det beror på storleken på filerna och hur många av dem det är. Därför är det här en optimering som vi rekommenderar att du fortfarande testar på din webbplats.
Ett av de enklaste sätten att kombinera dina externa CSS- och JavaScript-filer är med gratispluginet Autoptimize. Efter att ha kombinerat dem kommer du att se ”autoptimize_xxxxx.css” eller ”autoptimize_xxxxx.js” -filen. Det stöder också att laddning från ditt CDN. Du kan också göra detta med WP Rocket-plugin.
Kolla in vår djupgående guide om hur du kombinerar externa CSS och JavaScript i WordPress.
Använd minifiering på HTML, CSS, och JavaScript
Vi kan minska mängden data som webbläsaren måste ladda ner genom att minifiera HTML, CSS och JavaScript-resurser. Minifiering är processen att ta bort onödiga tecken som kommentarer och blankutrymme från källkoden. Dessa tecken är extremt användbara i utvecklingen, men de är meningslösa för att webbläsaren ska ladda sidan.
Icke-minifierad HTML
Här är ett exempel på icke-minifierad HTML-kod.
Minifierad HTML
Här är ett exempel på minifierad HTML-kod.
Du kan använda gratispluginet Autoptimize eller WP Rocket för att enkelt minifiera dina filer.
Om du är en Kinsta-kund har du tillgång till kodminifieringsfunktionen som är inbyggd direkt i MyKinsta-instrumentpanelen. Den gör det möjligt för våra kunder att snabbt och enkelt aktivera automatisk CSS- och JavaScript-minifiering med ett klick på en knapp och snabba upp webbplatserna utan manuell ansträngning.
Använd domäner utan cookies
Generellt, när du serverar innehåll som bilder, JavaScript, CSS, finns det ingen anledning för en HTTP-cookie att följa med, eftersom det skapar ytterligare overhead. När servern sätter en cookie för en viss domän måste alla efterföljande HTTP-förfrågningar för den domänen innehålla cookien. Denna varning ses normalt på webbplatser med ett stort antal förfrågningar.
Vi har ett djupgående inlägg om hur man hanterar det statiska innehållet från en cookielös-domän-varning. Många gånger kan du ignorera denna varning eftersom nya protokoll som HTTP/2 gör det här mindre viktigt. Kostnaden för en ny anslutning är vanligtvis dyrare än att strömma allt över samma anslutning.
Ett enkelt sätt att åtgärda denna varning är att använda en CDN-leverantör som kan ignorera cookies samt ta bort cookies som helt hindrar klienten från att ta emot svarsrubriken Set-Cookie. KeyCDN är en CDN-leverantör som erbjuder denna funktion. Som standard kan du se följande två alternativ är aktiverade. Detta är ett enkelt alternativ utan att behöva strula med att flytta och konfigurera din webbplats för att leverera statiska tillgångar från en separat underdomän.
Om du kör Cloudflare kan du inte inaktivera cookies på resurser som serveras via deras nätverk. CloudFlare innehåller sin egen säkerhetscookie i din rubrik. Återigen är dessa cookies mycket små och prestandaeffekterna är extremt minimala. Men om du använder CloudFlare, finns det inget sätt att komma runt denna varning.
Ett annat sätt att komma runt detta är att omkonfigurera din WordPress-webbplats för att leverera de statiska tillgångarna från en ny domän eller underdomän.
Avaktivera Inbäddningar i WordPress
När de släppte WordPress 4.4 sammanbakade de funktionen oEmbed i kärnan. Detta gör det möjligt för användare att bädda in YouTube-videor, tweets och många andra resurser på sina webbplatser genom att klistra in en webbadress, vilken WordPress automatiskt konverterar till en inbäddning och ger en live förhandsgranskning i den visuella redigeraren. Med uppdateringen blev WordPress själv en oEmbed-leverantör.
Den här funktionen är användbar för många människor, och du kanske vill hålla den aktiverad. Men vad det betyder är att det också genererar en ytterligare HTTP-begäran på din WordPress-webbplats för att ladda filen wp-embed.min.js. Och det här laddar hela webbplatsen. Medan den här filen bara är 1,7 KB, läggs saker som dessa ihop över tid. Förfrågan i sig är ibland en större affär än innehållets nedladdningsstorlek.
Du kan enkelt avaktivera denna fil från att laddas. Här är tre olika alternativ:
- Alternativ 1 – Avaktivera inbäddningar med plugin
- Alternativ 2 – Avaktivera inbäddningar med kod
- Alternativ 3 – Flytta JavaScript-Inlinen
Avaktivera Emojis i WordPress
På samma sätt som inbäddningar lades i WordPress 4.2, stöd för emojis till kärnan för äldre webbläsare. Det största problemet med detta är att det genererar en ytterligare HTTP-begäran på din WordPress-webbplats för att ladda filen wp-emoji-release.min.js. Och det här laddar över hela webbplatsen. Medan den här filen bara är 10,5 KB, är det värdelöst om du inte använder emojis på din webbplats.
Det finns ett par olika sätt att avaktivera Emojis i WordPress. Du kan göra det med ett gratisplugin eller med kod.
Hur du snabbar upp WordPress Kommentarer eller Avaktiverar Temat
En upptagen kommentarsektion på en webbplats kan orsaka många prestandaproblem. Tänk bara på de resurser som krävs för att få kommentarer att fungera:
- En databas begärs för att dra upp befintliga kommentarer.
- Databasinmatningar skapas för varje ny kommentar.
- Kommentarer och kommentarmetadata tas emot och bearbetas av en besökares webbläsare.
- Externa resurser, till exempel Gravatars, begärs, laddas ner och laddas (kräver separat DNS-sökning).
- I många fall måste stora JavaScript- och jQuery-resurser hämtas och bearbetas så att kommentarsystemet fungerar som det ska.
Här är fyra olika alternativ du kan göra för att snabba på WordPress-kommentarer:
Alternativ 1 – Inaktivera kommentarer
Om din webbplats inte får särskilt många kommentarer och du inte tycker att de lägger till något av värde, kan det vara bättre att inaktivera kommentarer helt och hållet. Kom ihåg att kommentarer kan påverka din SEO eftersom Google normalt räknar dessa som extra innehåll på sidan, så du bör bara godkänna kommentarer av hög kvalitet. Kolla in dessa tre enkla sätt att inaktivera kommentarer:
- Inaktivera Kommentarer från WordPress-alternativen
- Inaktivera Kommenterater med Plugin
- Inaktivera Kommentarer med Kod
Alternativ 2 – Optimera inbyggda WordPress-kommentarer
Ditt andra alternativ skulle vara att optimera det inbyggda WordPress-kommentarsystemet. Ett sätt skulle vara att minska antalet kommentarer som laddades vid den första sidladdningen.
- Gå till Inställningar → Diskussion i administratörsområdet för WordPress.
- Leta efter avsnittet Andra kommentarinställningar.
- Markera kryssrutan bredvid Dela upp kommentarer i sidor och lägg till ett värde för antalet kommentarer du vill visa vid första sidladdningen.
Ett annat alternativ du har är att hosta Gravatars på ditt CDN. Så gör vi på Kinsta.
Som standard, när WordPress-kommentarer laddas, kräver varje enskild unik Gravatar en HTTP-begäran. Så om en sida laddas upp med kommentarer från 50 olika kommenterare, kommer 50 HTTP-förfrågningar att krävas för att ladda ner alla Gravatars. Som du kan tänka dig kan det påverka sidhastigheten. För att inte tala om det faktum att vi har sett den externa DNS-uppslagningen till gravatar.com vara långsam ibland och ibland även göra timeout.
Om du tittar på Gravatars på Kinsta-bloggen kan du se att de laddas från Kinsta.com (inklusive vårt CDN). Kolla in hur du laddar gravatars från ditt CDN.
Alternativ 3 – Använd ett kommentarssystem från tredje part
Ditt tredje alternativ är att använda ett tredjeparts kommentarsystem. Om din webbplats är hostad på en billig, resursfattig delad server kan det med hjälp av ett kommentarsystem från tredje part påskynda sidor med mycket kommentarer. Det är samma idéer som bildoptimering, avlasta arbetet. Men om du hostar hos Kinsta eller ett annat webbhotell med hög kvalitet, hjälper det inte mycket att byta till en tredje part för att hjälpa till med din webbplats hastighet och kan istället sakta ner det.
Hastighetstesta alltid tredjepartens kommentarsystem du vill prova. Ta en titt på alla separata begäran som Disqus genererar (som visas nedan). Medan de flesta av dessa förfrågningar laddas asynkront, kommer du fortfarande att lägga märke till ytterligare laddningstid om du använder Disqus.
Alternativ 4 – Latladda Kommentarer
Ditt fjärde alternativ är att latladda kommentarer så att de inte saktar in den ursprungliga sidåtergivningen. Här är några plugins som du kanske vill kolla in:
- Lazy Load for Comments: Detta plugin låter dig latladda inbyggda WordPress-kommentarer.
- Disqus Conditional Load: Om du vill använda Disqus är detta plugin ett måste för att latladda kommentarer.
Avaktivera WordPress RSS-Flöden
Om du inte använder bloggdelen av WordPress på din webbplats kan du inaktivera WordPress RSS-flöden. Även om detta inte kommer att ha stor inverkan på prestanda, hjälper allt. Det är också en sak mindre att oroa sig för.
Kolla in dessa två olika sätt att inaktivera RSS-flöden i WordPress:
Använd Prefetch och Preconnect
Resursanvisningar och direktiv som prefetch och preconnect kan vara ett bra sätt att påskynda WordPress bakom kulisserna. KeyCDN har en utmärkt artikel och översikt över resursanvisninga.
Prefetch
DNS prefetch låter dig lösa domännamn (utföra en DNS-sökning i bakgrunden) innan en användare klickar på en länk, vilket i sin tur kan bidra till att förbättra prestanda. Det görs genom att lägga till en rel = ”dns-prefetch” -tagg i rubriken på din WordPress-webbplats.
<link rel="dns-prefetch" href="//domain.com">Vanliga saker att använda DNS prefetch för är ditt CDN-URL, Google fonts, Google Analytics, etc.
<link rel="dns-prefetch" href="//cdn.domain.com/">
<link rel="dns-prefetch" href="//fonts.googleapis.com/">
<link rel="dns-prefetch" href="//www.google-analytics.com">Prefetch stöds också av de flesta moderna webbläsare. Kolla in vår handledning om hur du lägger till kod i WordPress-rubriken.
Eller så kan du enkelt implementera DNS-prefetch med hjälp av ett plugin som Perfmatters. Klicka bara på fliken ”Extra” i pluginet Perfmatters och lägg till domäner. Format: //domain.tld (en per rad)
Preconnect
Preconnect låter webbläsaren ställa in tidiga anslutningar före en HTTP-begäran, vilket eliminerar väntetiden och sparar tid för användarna.
Preconnect är ett viktigt verktyg i din optimerings-verktygslåda … det kan eliminera många kostsamma rundresor från din förfrågningsväg – i vissa fall minska begäran-latensen med hundratals och till och med tusentals millisekunder. – lya Grigorik (källa)
Det görs genom att lägga till en rel = ”preconnect” -tagg i rubriken på din WordPress-webbplats.
<link rel="preconnect" href="//domain.com">Ett par exempel på saker du borde använda detta för är din CDN-URL eller Google Fonts.
<link rel="preconnect" href="https://cdn.domain.com">
<link rel="preconnect" href="https://fonts.gstatic.com">Preconnect stöds av de flesta moderna webbläsare, med undantag för Internet Explorer, Safari, IOS Safari och Opera Mini. Kolla in vår handledning om hur du lägger till kod i WordPress-rubriken.
Eller du kan enkelt implementera preconnect med ett plugin som Perfmatters. Klicka bara på fliken ”Extra” i pluginet Perfmatters och lägg till domäner. Format: scheme://domain.tld (en per rad).
Avaktivera Skript på en Per Sida/Inläggs-basis
Ett annat mycket kraftfullt sätt att påskynda WordPress är att gräva genom varje förfrågan som laddas på dina sidor och inlägg. Du kommer sannolikt att hitta skript som laddar hela webbplatsen som inte borde göra det.
Du kan använda ett premiumplugin som Perfmatters som har en ”Skripthanterare”-funktion inbyggd. Detta gör att du kan inaktivera skript (CSS och JavaScript) på en per sida/inläggs-basis, eller till och med hela webbplatsen med ett enda klick. Återigen är denna plugin utvecklad av en teammedlem hos Kinsta.
Några exempel på vad detta kan användas för:
- Det populära pluginet Contact Form 7 laddas på varje sida och postar. Du kan enkelt inaktivera det överallt med ett klick och bara aktivera på din kontaktsida.
- Det populära pluginet Contact Form 7 laddas på varje sida och postar. Du kan enkelt inaktivera det överallt med ett klick och bara aktivera på din kontaktsida.
- Pluginet Innehållsförteckning (TOC) laddas på varje sida och inlägg. Med skriptshanteraren kan du enkelt styra var du vill ladda den.
Varför är några plugin kodade på det här sättet?
Du kanske undrar varför alla plugin-utvecklare inte bara laddar in sina skript när pluginet är detekterat på sidan? Tja, det är lite mer komplicerat än det. Om du till exempel har ett plugin som Contact Form 7, har det också kortkod som låter dig placera det var som helst. Detta inkluderar att släppa det i en widget. Med WordPress är det mycket svårare att förfråga data från dem när du avköar skript i motsats till att förfråga data från post- eller sidmetadata.
Därför beror det ofta på användbarhetsfrågor. Ju mindre chans för ett plugin att brytas, desto mindre support kommer de att behöva ge. Men med många plugin på marknaden finns det sätt att komma runt detta och koda för prestanda om de ville. Tyvärr är det ibland ett stort antal nedladdningar och användare gör kodning för användbarhet en prioritet.
Rundtur i Skripthanteraren
Vi ger dig en liten rundtur i Skripthanteraren. Efter att ha klickat på det i verktygsfältet presenteras alla skript som laddas på den aktuella webbadressen, både JavaScript och CSS-filer. Du har då följande alternativ:
- Status På: (standardinställning)
- Status Av: Inaktivera överallt (du kan sedan välja vilka inläggstyper du vill aktivera den på tillsammans med den aktuella webbadressen)
- Status Av: Avaktivera endast på aktuell webbadress (detta är mycket användbart för att använda på din hemsida)
- Status Off: Undantag (nuvarande URL, posttyp eller arkiv)
Allt grupperas ihop efter plugin eller temanamn. Det gör det väldigt enkelt att inaktivera ett helt plugin samtidigt. Ett WordPress-plugin har vanligtvis både en JavaScript- och CSS-fil. Ett WordPress-tema kan ha 10 + filer.
När du har valt och eller ändrar inställningarna, se till att du trycker på ”Spara” längst ner. Du kan sedan testa i ett verktyg för webbplatshastighet så att skripten inte längre laddas på sidan eller inlägget. Se till att du först rensar cacheminnet! Och om något går fel på din webbplats visuellt kan du alltid återaktivera den i inställningarna för att återgå till normalt.
I ett hastighetstest av woorkup kunde de sänka de totala laddningstiderna med 20,2 %. Endast på deras hemsida kunde de minska antalet HTTP-förfrågningar från 46 till 30. Deras sidstorlek sjönk också från 506,3 KB till 451,6 KB.
För andra sätt att göra avstängning av skript, kolla in vårt blogginlägg om hur du inaktiverar WordPress-plugins från laddning.
Analysera Tredjeparts Prestanda
I grund och botten har allt du kallar externt från din webbplats laddningstidskonsekvenser. Vad som gör det här problemet ännu värre är att några av dem bara är långsamma under en kort period, vilket gör det svårare att identifiera problemet.
En extern tjänst från tredje part kan betraktas som något som kommunicerar med din WordPress-webbplats från utanför din egen server. Här är några vanliga exempel vi möter regelbundet:
- Sociala medieplattformar som Twitter, Facebook och Instagram (widgets eller konverteringspixlar)
- Annat annonseringsnätverk som Google Adsense, Media.net, BuySellAds, Amazon Associates
- Webbplatsanalys och spårningsskript som Google Analytics, Crazy Egg, Hotjar, AdRoll
- A/B-testverktyg som Optimizely, VWO, Unbounce
- WordPress-kommentarsystem som Disqus, Jetpack, Facebook-kommentarer
- Backup och säkerhetsverktyg som VaultPress, Sucuri, CodeGuard
- Sociala delningsverktyg som SumoMe, HelloBar
- CDN-nätverk som KeyCDN, Amazon CloudFront, CDN77 och StackPath
- Externt värd Javascript
Hur mycket påverkar vissa av dessa tredjepartstrackers prestanda? I vår egen fallstudie såg vi att skript från tredje part ökade sidladdningstiden med 86,08 %.
Ghostery mätte också över 500 amerikanska toppdomänerna i Alexa, och resultaten var häpnadsväckande, även om det inte var överraskande för oss. Webbplatser var 2x långsammare när inga trackers blockades alls. Vilket innebär att dessa spårningsskript för tredje part är en av de främsta bidragsgivarna för att sakta ner sidhastigheten på webben.
Du måste vara mycket försiktig på din WordPress-webbplats. Bara ett dåligt tredjeparts API-samtal kan orsaka timeout på hela din webbplats! Ja, det borde inte fungera på det sättet, men i många fall gör det det. Vi har sett det flera gånger än vi kan räkna.
New Relic ger ett utmärkt och enkelt sätt att övervaka dina externa tjänster över tid. I det här exemplet nedan kan vi se externa samtal till twitcount.com, graph.facebook.com och widgets.pinterest.com.
Det är viktigt att när du lägger till en ny funktion eller plugin till din webbplats att du undersöker de externa resurserna som laddas från den. Ju mindre desto bättre!
Optimera alltid med Mobile-First i åtanke
Google började presentera sitt mobile-first-index den 26 mars 2018. Tidigare har Googles kryptering, indexering och rankningssystem använt den stationära versionen av webbplatser. Mobil-first-indexering innebär att Googlebot nu använder mobilversionen av din WordPress-webbplats för indexering och ranking. Detta hjälper till att förbättra sökupplevelsen för mobilanvändare.
När det gäller att optimera din webbplats för mobile-first är hastighet en av de viktigaste faktorerna att fokusera på. Hastighet spelar en viktig roll i allt från användbarhet till avvisningsfrekvenser och bestämmer huruvida potentiella köpare kommer tillbaka till din webbplats. Faktum är att hastighet är en landningssidefaktor för Google Sök och annonser för mobila sökningar.
Dåliga mobila upplevelser leder till att majoriteten av användarna aldrig kommer tillbaka. Enligt den senaste rapportrapporten för Google-sidor var den genomsnittliga tiden en mobilwebbplats tog för att ladda i 2018 15 sekunder. Kan du tänka dig att vänta så länge för att ladda en enda sida? Förvånande.
Användare kräver (och förtjänar) bättre. Enligt samma sidohastighetsrapport lämnar 53 % av de mobila besökarna sidor som tar längre tid än en tre sekunder att ladda.
Långsamma mobila upplevelser dödar inte konverteringar. De förhindrar att du ens får chansen att konverter. När sidladdningstiderna ökar med bara några sekunder ökar sannolikheten för att någon lämnar sidan exponentiellt. Här är några saker att tänka på när du optimerar för mobilen.
Kolla in din mobila trafik
Det är alltid viktigt att ta en titt på hur mycket mobil trafik du får, eftersom det här kan ändra dina prioriteringar lite. Du kan se hur många mobila enheter som besöker din webbplats i Google Analytics under ”Målgrupp → Mobil → Översikt.” Som du kan se på den här webbplatsen är över 67 % av allt trafik från mobilen. Det är mycket!
Om du är en Kinsta-kund kan du även kolla din mobil vs stationär trafik i MyKinsta Analytics. Som du kan se på den här sidan är över 88 % av trafiken från dator. Det är alltid viktigt att kontrollera och inte bara anta. Bara för att alla säger att saker går mobilt betyder inte alltid att det är för din webbplats. Titta på data.
Se till att din webbplats är Responsiv
I 2019, är det bäst att din webbplats är responsiv! Det betyder att det använder mediaförfrågningar för att skala saker automatiskt på mobila enheter. Om du fortfarande inte har gjort det här har du troligtvis redan hamnat bakom konkurrensen. Alla WordPress-teman som vi nämnde tidigare i det här inlägget är fullt responsiv och ser fantastiska ut på alla enheter.
Använd Googles verktyg för mobilvänlighet för att testa och se till att din webbplats överensstämmer med alla krav.
Dubbelkolla att srcset fungerar
Tidigare var det mycket viktigt att ladda upp bilder enligt skala och inte låta CSS ändra storlek på dem. Detta är dock inte längre så viktigt eftersom WordPress 4.4 nu stöder responsiva bilder (inte nedskalade av CSS). WordPress skapar automatiskt flera storlekar av varje bild som laddas upp till mediebiblioteket. Genom att inkludera de tillgängliga storlekarna för en bild i ett srcset-attribut kan webbläsare nu välja att hämta den lämpligaste storleken och ignorera de andra. Se ett exempel på hur din kod ser ut nedan.
På grund av alla tredjeparts bildplugin och anpassningar där ute, har det varit många gånger där vi har sett det här inte fungerar korrekt. Därför är det viktigt att du dubbelkollar att dina bilder korrekt får srcset-attributet tillagt med olika versioner för olika skärmstorlekar. Bildoptimering är lika viktigt nu som alltid.
Google AMP Kan vara en lösning för dig
Google AMP (Accelerated Mobile Pages Project) lanserades ursprungligen i oktober 2015. Projektet bygger på AMP HTML, ett nytt öppet ramverk som helt byggts ut av befintlig webbteknologi, vilket gör det möjligt för webbplatser att bygga lätta webbsidor. För att uttrycka det enkelt, erbjuder det ett sätt att servera en avvecklad version av din nuvarande webbsida
Vi har ett slags kärleks- och hatförhållande med Google AMP, och det gör också mycket av communityt. Vi har testat det här själva och såg inte bra resultat. Men det betyder inte att du inte kommer att göra det. Varje webbplats är annorlunda, och Google AMP förbättras ständigt.
Du kan snabbt komma igång med Google AMP på din WordPress-webbplats med en av följande plugins:
Kolla in vår djupgående handledning om hur du ställer in Google AMP. Och om du behöver det, hur du stänger av Google AMP. Det är inte bara något du kan inaktivera och sedan vara klar.
Sammanfattning
Som du säkert kan se, är vi besatta av alla olika sätt som du kan påskynda WordPress. Att ha en snabb webbplats hjälper till att öka dina rankningar, förbättrar sökbarhet för sökmotorer, förbättrar omvandlingsfrekvensen, ökar tiden på webbplatsen och minskar din avvisningsfrekvens. För att inte nämna det faktum att alla älskar att besöka en snabb hemsida!
Vi hoppas att denna uppsnabbningsguide var till hjälp och att du kunde med dig något och tillämpa det på din WordPress-webbplats. Om så är fallet, vänligen ta en stund och dela med dig av det.
Missade vi något viktigt? Om så är fallet, skulle vi vilja höra om det. Låt oss höra dina snabbare WordPress-tips nedan i kommentarerna.
Lämna ett svar