Din WordPress är långsam? Då ger man bort mycket potential. Inte bara är dina besökare irriterade av de långsamma laddningstiderna, du kan också förlora synligheten på Google. Jag visar dig steg för steg hur du gör WordPress snabbare.

Om du säljer något via WordPress, till exempel med WooCommerce, då finns det tillräckligt med forskning för att bekräfta att långsamma webbplatser gör mindre försäljning i slutet av dagen. Speciellt mobilanvändare avbryter laddningen av en sida om det tar mer än tre sekunder. Snabbare webbplatser är avgörande för ditt företag.

Mätning av hastighet

Om du vill göra en webbplats snabbare måste du först mäta hur snabb/långsam den är innan optimering. Den rena laddningstiden är viktig, men inte nödvändigtvis avgörande. Vissa webbplatser har helt enkelt stora "tillgångar" (till exempel bilder och video) som besökare också vill se eller ladda ner. Snabbare är alltid bättre, men det beror också på besökarnas förväntningar. Till exempel har apple.com notoriskt dåliga prestandapoäng:

Det är inte direkt optimalt. Denna omständighet är dock välgrundad. Apple lägger extrem vikt vid det faktum att dess egna produkter visas i högsta möjliga kvalitet och därför använder enormt stora bilder utan att optimera dem, som den här guiden för WordPress visar. Besökare till Apple accepterar detta och gillar att vänta lite längre på att sidan laddas.

Sammantaget känns Prestandan på Apple-sidorna ganska snabb. Speciellt visningen av de första elementen är vanligtvis blixtsnabb. Dessa mäts under aspekten "First Contentful Paint" (FCP ). FCP bestämmer i uppfattning hur snabbt det "känns" att ladda en sida. Därför spelar FCP en särskilt viktig roll i optimeringen. Värden på 2 till 3 sekunder bör inte överskridas. Under 2 sekunder eller snabbare är bättre.

"Largest Contentful Paint" (LCP) återspeglar laddningstiden för de återstående elementen från huvudinnehållet. Om du kan stanna här under 3 sekunder är du redan ganska bra. Men stora produktbilder och liknande tillgångar kan också väsentligt driva upp detta värde, vilket också är helt okej beroende på syftet.

Fid (First Input Delay) mäter den tid det tar för dina besökare att faktiskt interagera med sidan. Markera till exempel en textpassage, klicka på en länk eller knapp etc. En sida kan till exempel ha en sökruta. Kanske tar den här sidan totalt 10 sekunder att ladda helt. Hur snabbt kan någon klicka på sökrutan och skriva in fältet? Kom ihåg: "Användaren" är inte alltid en människa. Ofta är det också bots som interagerar med sidor. Till exempel Google-boten, som mäter sidans prestanda och införlivar dessa värden i beräkningen av rankningarna.

"Cumulative Layout Shift" (CLS) måste undvikas hela tiden. Om en layout "skiftar" under laddning kan det vara enormt irriterande för dina besökare. Klick på en felaktig knapp kan vara resultatet. I de flesta fall orsakas sådana skift av saknad bredd / höjd för bilder. CLS ska alltid vara 0.

Dessa fyra värden är därför avgörande när man utvärderar hastigheten på en WordPress-webbplats. De är användarcentrerade, dvs. inte råa prestandavärden som tid till första byte, vilket spelar en viktig roll i bedömningen av serverns prestanda eller anslutningen till servern. Detta innebär också att dessa värden bestäms mindre av cachning och urval för WordPress-värd, även om detta också spelar en viktig roll i WordPress-prestanda. Utan snarare genom den smarta strukturen på en sida eller korrekt användning av HTML, CSS och JavaScript.

Prestandaoptimering har blivit ganska komplicerad de senaste åren. Speciellt eftersom Google meddelade att det skulle inkludera dessa användarcentrerade prestandakriterier i rankningsberäkningen. De bästa verktygen för att mäta din WordPress-prestanda:

• PageSpeed Insights genom Google
• GTmetrix (tecken)
• Lighthouse är inbyggt direkt i Google Chromes utvecklarverktyg.
• TREO-webbplatsens hastighet

Personligen gillar jag särskilt TREO eftersom det är snabbt och tydligt. PageSpeed Insights och GTmetrix är extremt detaljerade.

Med dessa förkunskaper och verktygen är du väl rustad att mäta din egen prestation. Om du gör det själv föreslår jag följande procedur:

• Först och främst mäta det ursprungliga tillståndet. Hur snabb är din webbplats före optimering?
• Aktivera eller implementera en optimering.
• Du kan sedan mäta prestandan igen. Har det visat sig ha gjort någon skillnad? Om inte, ta bort optimeringen och prova något annat. Om så är fallet, behåll optimeringen. Testa om allt fortfarande fungerar som tidigare och lägg till ytterligare en optimering.

Många försöker PageSpeed Insights för att nå ett värde av 100. Det är inget fel med det, förutom att det inte är nödvändigt att nå hela poängen. Andra verktyg mäter annorlunda och vad en 100 på PageSpeed Insights det vill säga, det kanske inte är så bra på GTmetrix. Dessutom är det mycket viktigare att gå från en 30 till en 90 än från en 90 till en 100.

Förbättra WordPress-prestanda

Snabbare WordPress Hosting

DE snabbaste värd i varje situation och när som helst existerar inte. Det finns för många faktorer som påverkar leveranstiden och behandlingen av förfrågningar. Följande faktorer gör inte bedömningen lätt:

• Dagtid
• Serveranvändning
• Geolokalisering
• Hastigheten på användarnas anslutning.

Ändå erbjuder varje värd olika paket som kan ha en betydande inverkan på prestandan på en WordPress-webbplats. Nybörjarpaket är vanligtvis billigare och naturligtvis inte så snabba. Därför är en av de första meningsfulla optimeringarna faktiskt en uppgradering av paketet.

Vid Raidboxes till exempel finns det startpaket i hanterad WordPress-värd, som befriar dig från administrativt arbete med WordPress och redan innehåller optimeringar som cachelagring på serversidan. Men också särskilt högpresterande paket i högtrafikerad hosting, till exempel för projekt med mycket höga åtkomstnummer. Även specialpriser för WooCommerce Värd för din webbutik. Det säger sig självt att de större paketen ger en extra prestandaökning.

En sak är klar: Om du betalar mer får du vanligtvis mer prestanda. Naturligtvis gäller detta för alla värdar. Nästan alla prestandajusteringar som används förstärks av tariffuppgraderingar. Men vad kan uppnås utan att byta direkt till en högre tariff?

Använda WordPress-cachning

Bortsett från de enklaste bloggarna använder nästan alla WordPress-webbplatser en mängd andra plugins. Som regel försenar plugins laddningstiden med en bråkdel av en sekund med varje sidvisning. Speciellt om plugin-programmet sätter in element i HTML-koden, som sedan måste laddas dessutom eller utföra ytterligare databasfrågor.

Vad händer om WordPress bara behövde göra dessa ytterligare "uppgifter" en gång per sida och helt enkelt hämtade resultatet av dessa "ytterligare" operationer från cachen nästa gång det kallades? Detta påskyndar avsevärt nästa laddningsprocess, eftersom servern bara behöver leverera en färdig fil. Helst sker inga ytterligare beräkningar, vilket drastiskt förkortar laddningsperioden. Till exempel kan en sida som har en uncacht 5 sekunders inläsningstid levereras inom millisekunder. Att förbättra hastigheten mellan 20 – 100 gånger så snabbt är inte ovanligt med cachning påslagen.

Cachningslösningar är viktiga när du accelererar WordPress-webbplatser. Helst via en serverbaserad lösning, mer om det om en stund. Annars via en av cache-plugins som är mycket populära i samhället:

• WP snabbaste cache (gratis + betald)
• LiteSpeed Cache (gratis, men fungerar bara med LiteSpeed-webbservern)
• WP-Optimize (gratis + betald)
• WP Super Cache (gratis, från WordPress-tillverkaren)
• Kolibri (gratis + betald)
• WP Rocket (betald, här min handledning på YouTube)
• Cache Enabler (kostnadsfri)
• Borlabs Cache (avgiftsbelagd )
• Hyper Cache (gratis)
• Comet Cache (gratis + betald)

Betalda plugins har vanligtvis fler funktioner. Gratis plugins hjälper dock i de flesta fall att reta ut 90 procent av alla möjliga tidsbesparingar.

Cachning av plugins är dock som ett bandage. De döljer problem som är bättre fixade i första hand. De tar inte nödvändigtvis bort överflödig HTML, de komprimerar inte bildfiler som är för stora, ändrar inte nödvändigtvis den ordning i vilken JS- och CSS-filer är integrerade etc. Även cachade sidor kan fortfarande vara långsamma.

Om du arbetar rent här från början behöver du "faktiskt" inte ett cache-plugin. Åtminstone i teorin. Eftersom cachning i allmänhet naturligtvis avlastar servern och därför alltid rekommenderas. Jag är mer bekymrad här över argumentet för god planering och ren, genomtänkt kod.

Dessutom finns det det faktum att Raidboxes förlitar sig på en särskilt högpresterande cachelagring på serversidan . Så du behöver inte ett extra plugin eller en betald lösning.

Flex-behållare i stället för kolumner och rader i sidbyggaren

Sidbyggare eller webbplatsbyggare är oumbärliga för många byråer eller utvecklare idag, trots allt gör de utformningen av sidor och bidrag mycket enklare.

I över 10 år har det varit standardförfarande i alla populära sidbyggare att skapa layouten med kolumner och rader. Detta leder ofta till en kapslad DIV-sallad:

Detta händer ofta på varje enskild sida, vilket vanligtvis blåser upp koden i onödan och kan också ha negativa effekter på FCP. Detta kan vanligtvis undvikas genom smart planering när du skapar layouten. Tillverkare av webbplatsbyggare börjar nu överväga CSS-standarderna Flexbox och Grid för att skapa layouter. Det är goda nyheter, eftersom det minskar mängden kod.

I den aktuella versionen av Page Builder Elementor kan till exempel behållare aktiveras i inställningarna för Flexbox. Detta ger dig inte bara mer flexibilitet i designen, det minskar också HTML-koden och gör laddningstiderna snabbare.

Ett klick på Direction -> Row justerar behållarna i rad. En enkel struktur med tre behållare kommer inte att förbättra prestandan dramatiskt just nu. Men om alla sektioner, rader och kolumner implementeras med denna nya teknik, kan vinsten vara betydande. Speciellt på många sidor och även när du optimerar FCP och LCP.

Funktionen är fortfarande i alfastadiet av Elementor. Andra byggare har använt detta nya tillvägagångssätt under en tid och alla byggare kommer att erbjuda det i framtiden. Det är därför värt att införliva det nya sättet att arbeta i arbetsflödet så snabbt som möjligt.

Det är mindre viktigt att använda CSS Flexbox och/eller CSS Grid, men att göra utan att kapsla. Teoretiskt sett kan även en tabellbaserad layout från 2000-talet optimeras genom "unboxing".

Rätt WordPress Theme

Det finns tusentals teman för WordPress. De är alla redan optimalt trimmade för prestanda, eller hur? Falsk. De flesta teman fokuserar på att se vackra ut. Detta är också vettigt ur försäljningssynpunkt. Teman väljs huvudsakligen utifrån attraktivitet. Mycket få WordPress-teman lägger verkligen vikt vid att göra mager kod till en prioritet - eller när det gäller sidbyggare: att skapa mager kod.

Ur min synvinkel rekommenderas för närvarande dessa teman och byggare:

• Astra
• GenereraPress
• Blocky
• Kadence

Det här är riktiga metateman, så de tillåter nästan alla tänkbara layoutalternativ, de har ett enormt urval av eleganta layouter och är optimerade för prestanda från grunden. De flesta av dessa WordPress-teman kan kombineras med andra sidbyggare som Elementor. Vissa har sin egen sidbyggare.

Optimera bilder och andra element

De allra flesta webbplatser använder bilder. Större bilder ser ofta bättre ut, men förlänger också laddningstiderna. Mindre är bättre, men oavsett detta finns det många tips att tänka på:

• Maximala dimensioner på mindre än 2 000 pixlar rekommenderas. Större bilder öppnas bättre i ett nytt fönster.
• Rätt format är avgörande. JPEG för fotografiska bilder med många färger och nyanser, PNG och GIF kan vara betydligt mindre för bilder med färre färger. Det är bäst att prova det.
• Vektorgrafik som logotyper och illustrationer ser bra ut som SVG, är oändligt skalbar och även liten. SVG är också vanliga textfiler med instruktioner som gör en grafik. Som textfiler drar de nytta av GZIP-komprimering, mer om det på ett ögonblick.
• Googles WebP-format kan minska JPG-filer med cirka 25 till 34 procent.
• WebP har funnits sedan 2010. Det nya AVIF-formatet minskar WebP med ytterligare 30 procent och uppnår ofta 50 procent besparingar jämfört med JPEG. AVIF har ännu inte fullt stöd för alla webbläsare, men detta växer från månad till månad.

Det finns plugins som konverterar dina bilder till alla format när du laddar upp dem och sedan helt enkelt integrerar den minsta filen. Här är de mest populära pluginsna för WordPress:

• Smush
• Optimus
• EWWW-bildoptimerare
• ShortPixel Image Optimizer
• TinyPNG
• Galenskap
• Föreställ dig
• reSmush.it
• Kraken.io Bildoptimerare
• WP Komprimera
• Komplettera automatiskt
• WP Avlasta media
• Optimole
• Hammy
• Robin bildoptimerare
• WP Komprimera
• Galenskap

WP Compress har ett mycket tydligt gränssnitt och gör komprimeringsuppgifter i bakgrunden. Förlängningen är inte precis billig, men väldigt bekväm. Om du hellre vill komma igång med ett gratis plugin bör du titta närmare på Imsanity.

De flesta optimerare har en premiummodell som begränsar antingen efter bildstorlek eller antal bilder. Undantaget är Robin. Ska du betala för ett sådant plugin alls? Det beror på hur mycket kontroll du behöver. Alternativt är det möjligt att optimera bilderna själv med skrivbordsverktyg, eller på kommandoraden (optimera, komprimera bilder) eller online innan du laddar upp (TinyPNG, Shortpixel).

De flesta plugins skapar också bilder i olika, mindre dimensioner. Beroende på upplösningen av användarwebbläsaren är en betydligt mindre fil direkt integrerad, vilket återigen leder till betydande prestandavinster.

Lat laddning gör att en bild bara laddas när dina besökare bläddrar till där den visas på sidan. De flesta bildoptimerare stöder detta, även om det också finns gratis plugins, till exempel Lazy Load från WP Rocket och Lazy Loader. Videor kan också eller bör bara laddas när "Nått", se Lazy Load för videor.

Cache-teckensnitt

Förutom avbildningar kan alla andra resurser cachelagras lokalt (på servern). Detta förbättrar inte bara efterlevnaden av internationella dataskyddslagar, det förbättrar också vanligtvis prestanda. Speciellt när teckensnitten är cachade. Sedan laddar webbläsaren ner dem en gång och visar dem direkt nästa gång utan att behöva ladda dem först. Detta fungerar bra, till exempel med WordPress-plugin OMGF Host Google Fonts Locally.

Selektiv inläsning av resurser per sida

Ett särskilt effektivt sätt att få ut mer hastighet är att selektivt ladda CSS- och JS-filer beroende på sida eller inlägg. Det finns flera möjligheter här som leder till målet.

Till exempel använder WordPress-webbplatsen en formulärhanterare som WPForms. Detta plugin laddar sina formulärfunktioner lika på varje sida. Denna funktion krävs dock endast på kontaktsidan. Freesoul Deactivate Plugins är ett plugin som stöder här:

Det möjliggör aktivering eller avaktivering av alla plugins per sida via en matris. Det är också möjligt att använda prestanda plugins som perfmatters , vilket också förhindrar leverans av CSS- och JS-filer. Freesoul undertrycker dock laddningen av hela plugin, det minskar också det arbete som måste göras i bakgrunden på servern.

Tweaks med perfmatters

Är det värt att köpa ett plugin som perfmatters? Thoeretisch alla optimeringar kan också utföras manuellt eller med andra plugins. Det skulle dock vara en vansinnigt hög mängd arbete, särskilt om det måste göras för flera WordPress-webbplatser.

Bara i de normala alternativen har ett plugin som perfmatters rymt mer än två dussin optimeringar. Är de alla vettiga? Detta beror på hur väl wordPress-användare är bekanta med funktionerna. RSS-flödet kan till exempel stängas av, vilket sparar några byte. Men det innebär också att besökare på webbplatsen inte längre bara kan prenumerera på bidragen via RSS-flödet. Så du bör tänka på det noggrant.

Det är fantastiskt hur många spelare WordPress har aktiverat som standard (emojis, dashicons, etc.), de kan säkert inaktiveras för tillfället. Du bör vara mer försiktig när det gäller inställningarna relaterade till databasen. Så det kan teoretiskt förstöra lite arbetstid för att inaktivera revisionerna. Om en cache ändå används är databasoptimeringar vanligtvis inte särskilt viktiga.

Däremot är det vanligtvis en katastrof för prestanda att använda Google Maps på en sida. Dessa kort bör egentligen bara laddas om det är brådskande nödvändigt. Många teman integrerar till exempel en karta på startsidan, vilket inte nödvändigtvis behöver vara fallet. Vid WooCommerce För onlinebutiker kan samtal wc-ajax = get_refreshed_fragments orsaka allvarliga förseningar. Dessa kan stängas av med "Inaktivera kortfragment".

I vilket fall som helst är det värt att titta på dokumentationen av perfmatters och WP Rocket. Om du verkligen vill dyka djupt hittar du ett antal utgångspunkter där. Naturligtvis kan du också helt enkelt köpa en av dessa plugins och spara mycket tid. Men man förstår ganska mindre vad som händer i bakgrunden.

Minification

Minifiering tar bort onödiga tecken, särskilt mellanslag och flikar, från HTML-, CSS- och JS-filer. Det är mer bästa praxis än det ger verkligen en stor prestandaökning. Med Autoptimize kan minifiering slås på eller av mycket enkelt.

Gzip-komprimering och brotli

Jämfört med minifiering nöter komprimering ofta mer än 50 procent av filstorleken på textfiler. Det är definitivt värt att slå på dessa, till exempel komprimeringsalgoritmen Brotli. I de flesta fall är sådan komprimering redan påslagen av webbhotell. Om inte, finns det ytterligare verktyg som lagrar filerna komprimerade i filsystemet. Speciellt för att komprimering av textfiler vanligtvis är mycket effektivare.

Brotli är ett komprimeringsformat utvecklat av Google som är ännu effektivare än Gzip. Naturligtvis används Brotli också av Raidboxes stödd.

Betydande optimeringar för JavaScript och CSS

Speciellt när det gäller optimering för FCP och LCP finns det idag möjlighet att uppnå drastiska prestandavinster via olika plugins och till och med direkt i teman. I mina tester är det ofta de bästa teknikerna för att få en sida i intervallet 90 till 100. Det är den försenade omladdningen av CSS- och JS-filerna.

I det kostnadsfria pluginet Autoptimize finns inställningen "Aggregerade JS-filer". Detta är aktiverat som standard. För att dra nytta av verklig acceleration är följande inställningar nödvändiga:

Alternativet "Skjut upp" säkerställer att JavaScript bara laddas om senare i renderingsprocessen. Först läses HTML och resurser in, sedan JS. I praktiken är interaktiva element i synnerhet inte omedelbart tillgängliga under de första sekunderna. Men själva sidan visas blixtsnabbt.

Eftersom JavaScript programmatiskt kan ladda om nästan vad som helst, bör denna teknik behandlas med försiktighet. Mycket kan gå fel här. Detta är också anledningen till att alternativet inte är aktiverat som standard. Prestandavinsten kan vara gigantisk, men efter aktivering måste du kontrollera varje sida för att se om den fortfarande fungerar korrekt.

Detsamma gäller efter varje uppdatering såväl som när du använder nya plugins som kan få sina egna JavaScript-filer att spela. Att aktivera detta alternativ är därför endast möjligt om du kan investera lite tid för granskning efteråt och regelbundet.

Situationen liknar CSS-filerna. Här måste "Eliminera renderingsblockerande CSS" aktiveras. Med CSS-instruktioner finns det ytterligare problem att vissa sidor eller områden på webbplatsen ska se lite annorlunda ut. En del av sidan ser likadan ut (färger, teckensnitt, sidhuvudets position), men en annan del ser annorlunda ut (bild i sidhuvudet, ytterligare information i sidfoten etc.).

Autoptimize hänvisar här till en extern och betald tjänst som försöker lösa detta problem. "Kritisk CSS" är CSS som måste laddas i början. Resten kan laddas om senare.

Plugins som WP Rocket och perfmatters har också en sådan funktion inbyggd. Hur bra detta fungerar beror helt på vilka plugins du vill använda på din egen WordPress-webbplats. Så det är bara möjligt med ett test. Men om det fungerar, då är boosten riktigt stor.

Att få den här funktionen gratis är för närvarande nästan omöjligt eftersom det är ett tufft problem. Eftersom varje webbplats är annorlunda. Även varje undersida på en webbplats är annorlunda och förändras ständigt på grund av uppdateringar. Det enda sättet att få 100 procent prestanda ur detta är att utveckla en djup förståelse för vad som faktiskt händer när varje sida laddas. Endast om du är villig att följa denna utarbetade väg kan du faktiskt nå en 100 för varje sida.

Slutsats - Gör WordPress snabbare

Det finns många justeringar i optimeringen av WordPress-prestanda. Snabb WordPress hosting är viktigt och grunden för allt. Men bara snabb hosting garanterar inte topphastigheter. För detta är det nödvändigt:

• Att göra tillgångarna på webbplatsen så små som möjligt, dvs. att komprimera dem.
• Välj rätt format (t.ex. WebP eller SVG). För att bara ladda så stora bilder som är nödvändiga för respektive syfte (skrivbord kontra surfplatta kontra mobil).
• Aktivera cachelagring eller använd serverbaserad cachelagring: När en resurs har "monterats" kan den läsas in från cacheminnet tills något ändras. Externa resurser som Google Fonts bör också laddas från din egen server.
• Optimera laddningsordningen. Skjuta upp CSS och JS med plugin eller tjänst eller först ladda vad som verkligen är nödvändigt, sedan resten (nyckelord: Kritisk CSS).
• Kasta bort onödig ballast: Behöver du verkligen emojis varje gång du laddar?

Det viktigaste tipset jag kan ge dig från träningen: Cachning och uppskjutning ger vanligtvis 90 procent av prestandan. Så här bör ditt fokus ligga på dina egna optimeringar. Jag önskar dig mycket framgång och en hög hastighet för dina projekt med WordPress och WooCommerce.