Webben är full av tips och tricks om hur du optimerar din WordPress-prestanda. Tyvärr hamnar förklaringar och utvärderingar av relevansen hos de olika justeringsskruvarna snabbt vid sidan av. Vi visar dig de viktiga utgångspunkterna och justeringsskruvarna - i en förnuftig ordning och med sammanhang. På så sätt kan du nå framgång särskilt snabbt.
Under tiden har vi varit värd för många WordPress-projekt. En hel del data har ackumulerats under processen. Och vi får om och om igen frågan om hur laddningstiden för en WordPress-webbplats kan minskas ytterligare. Därför har vi systematiskt bearbetat våra resultat från de senaste åren. Resultatet: 10 åtgärder med vilka du snabbt och enkelt kan optimera din WordPress Pagespeed.
En sak är särskilt viktig: vissa blir snabbt avskräckta av optimeringsförslagen i verktyg som Google PageSpeed Insights. Låt mig berätta: Du vinner inte mest laddningstid med komplicerade optimeringsåtgärder, utan med metoder som är lätta att genomföra.
Optimering av laddningstiden är naturligtvis inget självändamål. Förutom en bättre användarupplevelse ger en kortare laddningstid också fördelar för ditt erbjudandes synlighet i Google. Därför kommer jag också att kort beskriva vad de enskilda optimeringsstegen egentligen handlar om för att skapa ett lämpligt sammanhang.
Teoretiskt sett kan du arbeta dig nedåt från toppen till botten och på så sätt förbättra laddningstiden för din webbplats steg för steg. De första sju punkterna hänvisar förresten också till de typiska förbättringsförslagen från Google PageSpeed Insights, som vi till exempel går in närmare på i den här artikeln.
#1 Caching - den viktigaste prestandafaktorn för snabba laddningstider
Cachelagring innebär att din sida först inte behöver begäras av webbläsaren från webbservern och sedan byggas steg för steg. I stället läses sidan in från en cache, färdig återgivning.
Fördelen med denna cachelagring är uppenbar: WordPress behöver inte beräkna om sidan varje gång du visar sidan. Det WordPress baserat på den mycket långsamma PHP, är en cache elementär här. En av de saker som hindrar PHP från att läsas upp.
I princip finns det två implementeringsvarianter för cacheminnen:
- Om caching-plugins: Majoriteten av användarna använder ett caching-plugin, t.ex. W3 Total Cache eller WP Super Cache. Dessa är ibland enklare, ibland mer komplicerade att installera. I vilket fall som helst krävs det en viss mängd manuellt arbete här.
- Om hostern: Vissa hosters - inklusive Raidboxes - erbjuder caching på serversidan. Detta innebär att du nästan alltid kan klara dig utan caching-plugins. Detta beror på att din värdleverantör redan har konfigurerat cacheminnet åt dig.
Om du har installerat en högpresterande caching har du redan tagit det viktigaste steget mot att optimera WordPress. För mer information kan du ta en titt på vår artikel om grunderna för caching.
#2 WordPress sanering - ordningen måste
Enligt vår erfarenhet är en av de vanligaste orsakerna till långa laddningstider en överbelastad WordPress-installation. Och eftersom denna förbättringspunkt inte nämns av Google PageSpeed Insights kommer den direkt på andra plats på min topp 10.
En rörig WordPress-installation innebär i de flesta fall: För många plugins är installerade. Ju färre plugins, desto snabbare är webbplatsen. Naturligtvis är plugins viktiga och du kan inte klara dig utan dem, men du bör alltid kontrollera vilka plugins du verkligen behöver.
Och: Du bör vara uppmärksam Plugins inte bara för att inaktivera det, utan faktiskt ta bort det helt.
Detsamma gäller Themes : Du behöver inte mer än en.
Bakgrunden är följande: varje plugin och varje tema lägger till PHP-kod på din webbplats. Detta gäller även för inaktiverade insticksprogram. Detta gör din webbplats totalt sett mer omfattande och därmed långsammare (och mer sårbar för attacker). Detta beror på att PHP är ett mycket långsamt skriptspråk. Ju mindre det finns av det, desto bättre.
Plugins och teman som inte längre behövs är ofta rester från funktions- och designtester. Därför är det en bra idé att regelbundet städa upp på dina WordPress-webbplatser och att testa nya funktioner och design i en testmiljö snarare än på själva webbplatsen. På så sätt kan du undvika att samla på dig för många rester av insticksprogram.
#3: den underskattade laddningstidsbromsen
En av de mest effektiva och enklaste åtgärderna för att minska laddningstiden är att minska storleken på bilderna. Här kan du spara stora mängder data. Förlustfri bildkomprimering" minskar filstorleken på dina bilder utan någon synbar kvalitetsförlust. Det innebär att din sida knappt förändras alls, samtidigt som du kan minska dess storlek avsevärt genom bildoptimering.
Bilder utgör ofta den största delen av en webbplats datavolym. Att minska storleken på bilderna bör därför vara ett av de första optimeringsåtgärderna. Du kan antingen optimera bilder manuellt eller använda ett komprimeringstillägg.
Att använda ett insticksprogram är definitivt den smidigare lösningen. Plugins gör det inte bara möjligt att komprimera nya bilder och deras miniatyrbilder, utan de tar också automatiskt hand om alla befintliga bilder på din webbplats. Denna tjänst är dock ofta avgiftsbelagd.
#4 CSS och JavaScript - låter skrymmande, men är lätt att optimera
Den näst största mängden data på din webbplats är vanligtvis JavaScript- och CSS-filer. Det är här som en stor del av rädslan för kontakt dyker upp. Men även utan kodkompetens kan du lätt förstå vad optimering av CSS och JavaScript handlar om. I princip finns det tre saker att göra här:
- Sammanfatta: CSS och JavaScript är dolda i många små enskilda filer. Normalt måste webbläsaren begära varje fil individuellt från webbservern. Detta genererar HTTP-förfrågningar som tenderar att öka laddningstiden för din webbplats. Om skript kombineras minskar dock antalet filer som ska laddas och därmed antalet förfrågningar. Exempelvis blir 53 enskilda förfrågningar endast ett dussin eller så. Självklart kan motsvarande insticksprogram också göra detta åt dig.
- Minska: CSS- och JavaScript-filer är rader av kod som möjliggör vissa funktioner och utformningar på din webbplats. Denna kod skrivs av människor. Men den läses av maskiner. Varför är detta relevant? Mycket av det som en människa behöver för att förstå koden korrekt behövs inte av en dator. Utrymmen, kommentarer och liknande behövs därför inte för att din sida ska kunna byggas korrekt. Det är här plugins som Autoptimize kommer in i bilden. De omvandlar CSS och JavaScript från människoläsbar till maskinläsbar kod. Detta gör de enskilda datapaketen mindre och deras överföring snabbare.
- Komprimera: Efter sammanslagning och minskning är det sista steget att komprimera datapaketen som skickas från webbservern till webbläsaren. Detta innebär att servern minimerar filstorleken på de enskilda förfrågningarna och att webbläsaren packar upp och beräknar dem. Detta är snabbare än att skicka okomprimerade datapaket. Du kan ställa in en sådan GZIP-komprimering t.ex. via caching-plugins, via manuella inställningar i .htaccess eller så har din hoster redan aktiverat komprimering på serversidan.
Även om man inte känner till manuskriptet är det lätt att förstå vad de enskilda åtgärderna innebär. Och för alla tre stegen finns det insticksprogram som gör det möjligt även för icke-proffs att optimera CSS och JavaScript. I vår artikel om optimering av CSS och JavaScript förklarar vi ytterligare detaljer och presenterar olika plugins.
Fyra vinster!
Detta var de fyra områden där mycket laddningstid kan sparas. Med relativt liten ansträngning kan du redan optimera din prestanda - genom cachning, bildoptimering, optimering av CSS & JavaScript och rensning av WordPress kan du redan uppnå betydande förbättringar.
#5 Hosting har en stor inverkan på laddningstiderna
De första fyra optimeringsområdena utlovar en särskilt stor minskning av laddningstiden, men det kan vara förgäves om din hosting saktar ner dig. Det handlar inte så mycket om hårdvarukraven för WordPress, utan snarare om vissa tekniker som visar att en hoster låter dig optimera WordPress i enlighet med detta.
Som en tumregel kan du komma ihåg att ett högpresterande WordPress-hotell bör ha dessa nyckeldata:
- SSD-hårddisk
- PHP-minne på minst 64MB, bättre 128MB
- Datacenter i målgruppens geografiska närhet.
- Nuvarande PHP-version
- HTTP/2 och gratis SSL-certifikat
Sedan är det skillnaden mellan delad hosting och din egen (virtuella) server.
Med delat webbhotell delar du servern och dess datorkraft med andra webbplatser. Vanligtvis några dussin till några hundra. Med en egen server behöver du inte dela beräkningskraften med någon annan. Det ger därför fördelen med säkerhet i fråga om prestanda.
Även om en dedikerad server inte är synonymt med mer prestanda, visar erfarenheten att de billiga värdtarifferna, som bara kostar några euro i månaden, inte kan konkurrera med virtuella servrar när det gäller prestanda.
"*" visar obligatoriska fält
Subtiliteterna - mindre penetration, mer ansträngning
Alla de prestandarelaterade områden som jag har nämnt hittills kan optimeras av nästan vem som helst. Antingen genom plugins, enkla försök och misstag eller köp av motsvarande produkter. Det blir mer komplicerat om du redan har optimerat dessa områden. För då måste du gå djupare in i sidstrukturen. Och enskilda optimeringsåtgärder har inte längre samma effekt.
#6 renderingsblockering - Fel ordning vid inläsning
En punkt som görs av verktyg som Google PageSpeed Insights upprepade gånger klagat på är en belastningsordning som blockerar renderingen.
Problemet blir tydligt med ett exempel: En glidare består av bilder och ett animationskommando som roterar bilderna. Om JavaScript-kommandot laddas först och bilderna sist, har sidan redan funktionen för glidaren, men inte bilderna som ska visas. Sidan kommer därför att ta längre tid att ladda. Detta tillstånd kan förhindras genom rätt laddningssekvens.
Även om det finns tilläggsprogram för att optimera laddningsordningen visar vår erfarenhet att de inte alltid kan optimera din webbplats fullt ut. I själva verket uppnås de bästa resultaten i sådana fall vanligtvis av en webbdesigner som är väl förtrogen med webbplatsen och dess funktioner.
#7 ovanför vikningen - Optimera det synliga området på sidan
Förutom den totala laddningstiden för din webbplats är den upplevda laddningstiden avgörande. Med andra ord den tid som visuellt uppfattas som laddningstid. Denna upplevda laddningstid kan förkortas med några få knep. Till exempel får man intrycket att sidan redan är helt uppbyggd, trots att beräkningar fortfarande pågår i bakgrunden.
Att optimera lastordningen är särskilt viktigt för att optimera detta område, som kallas ovanför vikningen. Detta innebär att prioritera innehåll och funktioner som dina besökare bör se på den första skärmstorleken.
Det kan du till exempel göra genom att optimera laddningssekvensen. Men det finns också plugins som ser till att din sida laddas effektivare. Och endast det synliga området. a3 Lazy Load är ett exempel på sådana plugins. På det här sättet får du fortfarande allt innehåll som visas, men sidans laddningstid kan gynnas av detta, särskilt om det är en bildtung sida.
#8 databas
Förutom bilder och skript kan din databas också bli för stor. Det finns praktiska verktyg som håller din databas snygg och smidig, bland annat insticksprogrammet WP-Optimize.
#9 pingbacks och trackbacks
Som standard interagerar WordPress med andra webbplatser som tillåter pingbacks och trackbacks. Varje gång din webbplats eller ett av dina blogginlägg omnämns på en sådan webbplats meddelas din webbplats automatiskt, vilket belastar databasen ytterligare.
Om du inte behöver den här funktionen (enligt min åsikt är mervärdet ändå försumbart) bör du avaktivera pingbacks och trackbacks. Återigen hjälper WP-Optimize-pluginet till här. För fullständighetens skull måste det dock nämnas här att detta är mer av ett teoretiskt problem. Vi har ännu inte upplevt några allvarliga prestandaförluster av denna anledning.
#10 förhindra hotlinking
Hotlinking innebär att någon länkar direkt till en bild på din server - vilket i praktiken "stjäl" din bandbredd. På en Apache-webbserver kan du förhindra hotlinking genom att lägga till följande kod i .htaccess-filen:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?yourwebsite.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google.de [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google.com [NC]
RewriteRule .(jpg|jpeg|png|gif)$ – [NC,F,L]För att förhindra hotlinking på en NGINX-server lägger du till dessa kodrader i NGINX-konfigurationsfilen:
location ~ .(gif|png|jpeg|jpg|svg|webp)$ {
valid_referers none blocked server_names
*.example.com example.* www.example.org/galleries/ ~\.google\.;
if ($invalid_referer) {
return 403;
}
}Uppdelning av koden:location ~ .(gif|png|jpeg|jpg|svg|webp)$ {
anger de filändelser som du vill skydda från hotlinking, till exempel om du vill skydda PDF-filer skulle kodraden se ut så här:location ~ .(gif|png|jpeg|jpg|svg|webp|pdf)$
{valid_referers none blocked server_names*.yourwebsite.com ~.google. ~.bing. ~.yahoo.;
Dessa rader är lite omfattande, men de hjälper dig att bättre förstå vad du kan göra med denna regel. De här raderna anger vilka domäner som ändå får snabblänka dina filer. I det här exemplet är det yourwebsite.com med alla underdomäner samt Google, Bing och Yahoo.
if ($invalid_referer) {return 403;}
Om en förfrågan kommer in och resursen för förfrågan INTE finns med på din vitlista, returnerar servern ett 403-fel (förbjudet).
Andra metoder för att förhindra hotlinking
Det finns många säkerhetstillägg i den officiella katalogen för WordPress-plugins som du kan använda för att förhindra hotlinking - till exempel All In One WP Security & Firewall. På Raidboxes kan du också förhindra hotlinking via CORS-rubrikerna i inställningarna för din Box . Om du har några frågor om konfigurationen av rubrikerna på din Box kan du kontakta vårt supportteam.
"Och CDN då?"
En av de vanligaste frågorna handlar om ett Content Delivery Network (CDN). Till exempel: "Gör ett CDN min webbplats snabbare för besökare i Tyskland?", "Varför behöver jag egentligen ett CDN?", "Skulle du rekommendera mig att använda ett CDN för min blogg eller butik?". I de flesta fall var svaret dock nej.
För att göra en lång historia kort: En CDN är mest meningsfull om dina användare är geografiskt utspridda. Till exempel om du har kunder i Centraleuropa, Sydamerika och Australien. Om din kärnmålgrupp är begränsad till ett land kan du direkt avfärda en CDN för WordPress-optimering.
Förresten har WordPress-utvecklaren Ernesto Ruge skrivit en mycket bra artikel om det här problemet, som jag bara kan rekommendera dig.
Slutsats: Var inte rädd för komplicerade optimeringssteg
Det finns ofta en rädsla för att komma i kontakt med sådana områden, där det är särskilt lätt att spara laddningstid, eller så försummas de. Andra, som CDN, kommer dock upp gång på gång under konsultationer, trots att de vanligtvis inte har någon som helst effekt på webbplatsens laddningstid.
Därför kan jag bara rekommendera att du först koncentrerar dig på de "lågt hängande frukterna" av WordPress prestandaoptimering. Med relativt liten ansträngning kan du redan göra stora framsteg när det gäller att minska din laddningstid. Och det även om du är en lekman.
Så låt inte råd från verktyg som Google PageSpeed Insights Oroande.
I grunden handlar optimering av laddningstid om endast ett fåtal områden:
- Minska storleken på din webbplats
- Minskning av antalet HTTP-förfrågningar
- Komprimera de enskilda datapaketen
- Optimering av den upplevda laddningstiden
Om du har förstått detta kan du också på ett förnuftigt sätt vrida på de 10 viktigaste skruvarna för optimering av WordPress. Och för mer komplexa optimeringssteg finns det också experter som kan piska din webbplats i form.
Laddningstiden kommer att tacka dig!
