Teknisk SEO

Snabbare WordPress: det som faktiskt hjälper

Snabbare WordPress utan magi: webbhotell, cache, bildoptimering, färre plugins och lättare tema. Åtgärderna i den ordning de faktiskt ger effekt.

Snabbare WordPress handlar mer om att välja rätt på ett par ställen än om att finjustera i timmar, och det märks både för besökarna och i Googles mätvärden Core Web Vitals. Webbhotellet, cachen och bilderna står för nästan hela skillnaden; resten är finlir. Här är åtgärderna i den ordning de brukar ge effekt på sajterna jag granskar och driver själv.

Varför är webbhotellet viktigast?

Allt börjar med hur snabbt servern svarar. Ligger sajten på ett överfullt lågprishotell väntar besökaren innan första byten ens har skickats, och den väntetiden går inte att cacha bort. Mina tumregler: aktuell PHP-version, servrar i Sverige eller närliggande Europa och inbyggd servercache. Känns även adminpanelen trög är det nästan alltid hotellet som är problemet, inte temat. Ett byte låter jobbigt, men de flesta seriösa webbhotell flyttar sajten åt dig utan kostnad.

Vilket cache-plugin ger snabbare WordPress?

Cache betyder att sidan sparas som färdig HTML i stället för att byggas om vid varje besök, och det är den största mjukvaruvinsten på de flesta sajter. Etablerade alternativ som WP Rocket och LiteSpeed Cache gör jobbet; vilket du väljer spelar mindre roll än att du bara kör ett enda. Har webbhotellet egen servercache behöver pluginet främst sköta det cachen inte tar, som att slå ihop och skjuta upp skript. Aktivera, klicka igenom sajten och kontrollera att formulär och varukorg fortfarande fungerar.

Hur mycket betyder bilderna?

Ofta mer än allt annat på sidan tillsammans. En oskalad bild rakt ur kameran kan väga flera megabyte, och tunga bilder högst upp på sidan syns direkt i mätvärdena. Konvertera till WebP, ladda upp i rätt storlek och slå på lazy loading; hela arbetsflödet har fått ett eget inlägg i bildoptimering för SEO.

Måste jag rensa bland plugins och tema?

Ja, men med förnuft. Varje aktivt plugin är kod som ska laddas, och en del lastar in skript och stilmallar på varenda sida trots att de bara används på en. Avaktivera och radera det som inte används, och ifrågasätt det som bara ligger där för att ingen vågat röra det. Ett SEO-plugin är värt sin plats, men ett räcker; vilket och varför kan du läsa om i SEO-plugin till WordPress. Temat då? Sidbyggarteman släpar ofta på mycket last, och ett lättare tema märks tydligt. Men ett temabyte är ett helt projekt, så spara det till nästa gång sajten ändå ska göras om. Och ska den byggas om från grunden är WordPress inte enda vägen; varför jag valde statisk HTML till min egen sajt står i sajten du läser på är byggd i Astro.

Vad gör jag åt typsnitt och tredjepartsskript?

Det är den delen som växer utan att någon märker det. En chattwidget, ett cookieverktyg, en inbäddad karta, en videospelare och ett par spårningsskript; var för sig små, tillsammans en rejäl last som dessutom hämtas från andra servrar än din, med väntetiderna det innebär.

Typsnitten är den enklaste vinsten. Hämtas de från Google Fonts vid varje sidvisning kan du i stället lägga filerna på din egen server, ladda bara de vikter du faktiskt använder och slippa ett externt anrop. Det löser samtidigt en integritetsfråga, eftersom besökarens IP-adress då inte skickas vidare; hur jag tänker kring den sortens frågor står i GDPR och Google Tag Manager.

För resten gäller två saker: ta bort det ingen använder, och skjut upp det som kan vänta tills sidan har ritats upp. En inbäddad video går till exempel att ersätta med en klickbar bild som laddar spelaren först när någon vill se den.

När behövs ett CDN?

Senare än folk tror. Ett CDN kopierar sajtens filer till servrar närmare besökaren, vilket gör nytta när besökarna finns i flera länder eller när webbhotellet står långt bort. För en svensk sajt med svenska besökare på svenskt webbhotell är vinsten liten. Gör det här sist, om alls.

Varför är siffrorna så mycket sämre på mobil?

För att testet simulerar en svagare telefon och ett långsammare nät än den mobil du själv håller i. Det är avsiktligt, och det ligger närmare verkligheten för många besökare än ett skrivbordstest på fiber.

Två sorters data är värda att hålla isär. Labbdata är mätningen som körs där och då, och den svänger mellan körningar; kör om ett par gånger innan du drar slutsatser av en enskild siffra. Fältdata samlas in från riktiga besökare och ligger till grund för Core Web Vitals-rapporten i Search Console. Fältdatan reagerar långsamt, så en förbättring du gör i dag syns där först om några veckor. Bli inte förvånad över det, och rör inte fler saker under tiden bara för att siffran står still.

Hur vet jag att det blev bättre?

Mät innan du rör något. Kör dina viktigaste sidor genom PageSpeed Insights, gör en åtgärd i taget och mät igen; annars vet du aldrig vilken ändring som hjälpte. Låt sedan fältdatan i Search Console bekräfta att det höll. Hur sajten uppför sig på telefon specifikt hittar du i mobilanpassad hemsida. Hastighet är en del av helheten, och resten samlar jag i min tekniska SEO-checklista. Kör sajten fast i trögt trots allt det här tittar jag gärna på den som SEO-konsult. Men börja med webbhotellet och bilderna; det är där timmarna ger mest tillbaka.