Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Tobias Schüring Senast uppdaterad den 21 oktober 2020
11 Min.
Google PageSpeed Insights Fel
Senast uppdaterad den 21 oktober 2020

Google PageSpeed Insights är utmärkt för att snabbt ge dig en översikt över din webbplats optimeringspotential. Idag ska jag visa dig hur du använder den här potentialen och ökar din PageSpeed-poäng. Men du bör inte slaviskt följa Googles resultat. Eftersom felmeddelandena i PageSpeed inte alltid är användbara.

Kollegan Caspar Hübinger har för en tid sedan i ett av sina blogginlägg ,låt oss säga, mycket tydliga ord för hansGoogle PageSpeed Insights resultat hittades. Och han kritiserar inte bara verktyget, utan också användningen av verktyget av användarna. För om du inte vet hur du tolkar och fixar de enskilda optimeringsförslagen kan du snabbt gå vilse i den meningslösa jakten på ett 100-betyg. Men det vore oklokt. Eftersom utopiska höga Google PageSpeed-betyg vanligtvis är slöseri med tid. Viktigare är optimeringen av laddningstiden.

Jag ska visa dig idag hur du får Googles viktigaste felmeddelanden PageSpeed Insights tolka och optimera sidan i enlighet därmed.

Men innan jag visar dig hur du tolkar de enskilda felmeddelandena och korrigerar felen, vill jag gå tillbaka till hur du Google PageSpeed Insights används på rätt sätt. Eftersom vi ofta har sett att användare var kraftigt fixerade på sin PageSpeed-poäng utan att hålla ett öga på sin sidas laddningstid.

Om du inte är intresserad av det här avsnittet hoppar du bara över det och lär dig direkt hur du fixar felmeddelandet "Komprimera CSS".

Felmeddelanden på Google PageSpeed är inte alltid korrekta och viktiga

Du bör aldrig fokusera enbart på Googles resultat eller felmeddelanden PageSpeed Insights Lämna. Eftersom Google-verktyget bara inte mäter den viktigaste egenskapen på din sida: sidans laddningstid. För att mäta dem korrekt rekommenderar jag Webpagetest.org.

Endast om du håller ett öga på sidinläsningstiden från början när du optimerar din webbplats kan du göra meningsfulla uttalanden om optimeringens framgång. Eftersom målet med en eventuell optimering alltid bör vara en förbättrad användarupplevelse. Vid prestandaoptimering är detta naturligtvis sidinläsningstiden och den upplevda sidbelastningstiden.

MÄRKER!

Kontrollera alltid sidinläsningstiden först innan du optimerar sidans prestanda. Detta är det enda sättet att bedöma hur framgångsrik optimeringen har varit.

Ur ett användarperspektiv är snabbare sidinläsningstid och mindre sidstorlek alltid en fördel. Den genomsnittliga användarens tålamod och uppmärksamhetsintervall fortsätter att minska(vilket denna Microsoft-studie visar)- vilket är särskilt viktigt för e-handeln - och fler och fler besökare kommer via mobila enheter. Redan 2016 kom 56 procent av tyskarna regelbundet åt internet via smartphones eller surfplattor. Här är anslutningshastigheter och datavolymer inte alltid obegränsade. Smala, snabba sidor är därför lämpliga.

Google PageSpeed ger dock bara indikationer på optimeringspotentialen på din webbplats och tillåter bara några slutsatser om användarupplevelsen. Den låga betydelsen av Google PageSpeed-felmeddelanden förstärks av det faktum att verktyget inte kan vilas i vissa områden eller bara med betydande ytterligare ansträngning.

Referensen till webbläsarcache visas till exempel när externa resurser, inklusive Googles egna tjänster, integreras. Men dessa resurser kan inte täckas av sidans webbläsarcachelagring. Felmeddelandet är därför inte relevant för användarupplevelsen på din webbplats, men produceras av logiken i själva verktyget. I värsta fall tolkas dock meddelandet som om ingen webbläsarcachelagring är aktiv alls.

Så fokusera inte främst på Google-bedömning, utan på laddningstiden. Detta är den enda riktigt viktiga storleken.

Men hur är det med min Google-ranking?

Exemplet med den saknade webbläsarcachen gör det mycket tydligt varför du inte ska oroas av ett förmodligen dåligt PageSpeed-resultat.

Om du till exempel har inkluderat Google Maps eller Google Analytics på din sida kommer de att orsaka följande felmeddelande:

Typiskt Google PageSpeed Insights -Felmeddelanden: Webbläsarcachelagring påstås inte användas korrekt

Detsamma gäller andra tredjepartstjänster. Till exempel vår supportchatt.

Varje gång vi därför tar vår sida till PageSpeed Insights test, denna punkt är kritad upp. Detta innebär att denna faktor alltid snedvrider våra resultat negativt och därför helt enkelt ignorerar den.

För din webbplats SEO innebär detta att laddningstiden och användarupplevelsen också är mycket viktigare för rankningen på Google än det specifika PageSpeed-betyget.

För när du optimerar sidans laddningstid redigerar du automatiskt många av de områden som är viktiga för Google. En förbättring av laddningstiden och Google PageSpeed-poängen är därför på något sätt relaterade.

Enligt min mening bör du dock inte gå vilse i jakten på 100 i betyg.

Men nu till optimeringsstegen!

Fel 1: Komprimera CSS

Enligt vår erfarenhet är detta ett av Googles mest avskräckande felmeddelanden PageSpeed Insights .

Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Betydelse: Det här felmeddelandet anger att sidans CSS-filer fortfarande kan komprimeras (eller, i fallet ovan, om det redan har gjorts). En sådan minskning minskar antalet tecken i dokumenten. Så här krymper filstorleken. Kommentarer, blanksteg och formatering tas till exempel bort.

Genomförande: Även om denna antydan fungerar avskräckande är genomförandet mycket enkelt. I det här fallet finns det i princip två möjliga lösningar: Om du själv är i plats i CSS kan du manuellt minska antalet CSS-filer och använda en stenografi när du skapar dem. Du kan också minska csS-filer för hand med hjälp av onlineverktyg som CSS Compressor eller CSS Minifier.

Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Naturligtvis finns det också den praktiska lösningen med CSS-minifiering Plugins I WordPress . Några Plugins göra en direkt vändning och kan komprimera och optimera inte bara CSS, men också JavaScript och HTML.

Ytterligare information

En detaljerad förklaring av hur du WordPress HTML, CSS och JavaScript, se den här artikeln.

Med HTTP/2 är det inte nödvändigtvis meningsfullt att sammanfatta CSS

Den ovan nämnda Minify Plugins används i stor utsträckning. Eftersom de är bekväma och tar över komprimeringen och sammanfattningen av CSS (och mycket mer) helt automatiskt. Fram till nyligen var summeringen av CSS-filer också mycket meningsfull. Under tiden är detta annorlunda: Eftersom HTTP / 2-standarden finns kan webbläsare ladda flera filer samtidigt från webbservern.

Det innebär att data inte längre behöver summeras, eftersom http/2 kan utbyta flera datapaket samtidigt. HTTP/2 måste ha konfigurerats av värd .B kan endast användas med ett SSL-certifikat.

Så innan du bestämmer dig för att gå för en Plugin med flera dussin funktioner och konfigurationsalternativ, tänk noga om du behöver det alls. Särskilt om du litar på dig själv för att optimera CSS själv.

Eftersom ytterligare en Plugin kan sakta ner din sida. Särskilt om de andra funktionerna i allround- Plugins inte kan nå sin fulla potential.

Fel 2: Eliminera resurser som blockerar rendering

Detta meddelande driver också svettpärlorna på pannan hos många användare, eftersom det inte är så lätt att implementera och är också en av Google PageSpeeds eviga kritik.

Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Betydelse: En webbsida är byggd i en viss ordning. Den här laddningsordningen kan optimeras. PageSpeed klagar nästan alltid på att CSS-filer blockerar denna optimala laddningsordning. Detta gäller även redan mycket väloptimerade sidor (som fallet Caspar Hübinger visar). Anteckningen kan dock vara mycket värdefull för optimering av laddningstid. I grund och botten talar den här anteckningen om att JavaScript- eller CSS-kod, vilket är viktigt för ett objekt att läsa in, till exempel en bakgrundsfärg, ännu inte är tillgängligt när objektet läses in. Detta visas inte förrän motsvarande CSS-kommando har lästs in. Detta ökar laddningstiden för din sida, men påverkar framför allt användarupplevelsen, eftersom sidan känns längre.

Umsetzung: Eine gängige Lösung ist die Umsetzung einer Daumenregel: CSS in den Header. Das bedeutet, dass du CSS-Code vom Hauptteil des HTML Dokuments, dem <body>, an den Anfang des Dokuments, den <head>, verschiebst und dort als <style> einbindest.

An diesem Beispiel wird deutlich, was ich meine. Der Codeschnipsel unten definiert unsere spezifische Hintergrundfarbe für den Blog. Das <style>-Element wird im head des HTML-Dokuments geladen. So lädt der Seitenhintergrund nicht erst am Ende des Dokuments und erzeugt einen unschönen Farbsprung oder blockiert gar das Rendering.

<head>
<style type="text/css" id="custom-background-css">
body.custom-background { background-color: #f5faff; }
</style>
</head>

I sin tur kan du implementera det här optimeringsmåttet på två sätt: du kan röra koden själv och flytta CSS-koderna till huvudet, eller så kan du använda en Plugin låt arbetet göra det. Även här, hjälp Plugins Hur Bättre WordPress Minifiera.

Google PageSpeed Insights Felmeddelanden - utdrag från Plugin Bättre WordPress Minify

Myntverket Plugin I alternativen anger till exempel vilka CSS-filer som redan har flyttats till huvudet. Du kan också lägga till fler CSS-resurser manuellt här.

Google PageSpeed Insights Felmeddelanden - utdrag från optimeringsplugin Automatiskt

Den Plugin Autoptimize, å andra sidan, börjar med den allsidige vändningen: Du väljer alternativen för alla CSS-filer som inte är uteslutna från åtgärden.

Utdragen från alternativen för Plugins visa: Plugin-varianten är inte heller genomförbar utan en grundläggande förståelse för processen. Även i Plugins Så du måste jobba dig in.

Felmeddelande 3: Koda bilder effektivt

Vid denna tidpunkt också, PageSpeed Insights ofta runt. Detta fall är dock nästan alltid snabbt och enkelt att genomföra och ger vanligtvis också påtagliga laddningstidsfördelar.

Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Betydelse: Många användare underskattar bildstorlekens roll för sidans laddningstid. Bilder är mycket ofta en av de största laddningstidsbromsarna. Även om endast små mängder data sparas för enskilda bilder kan den totala sparade volymen lägga till upp till en betydande mängd data.

För en bild är sällan bara en bild. WordPress genererar automatiskt flera miniatyrer av bilden vid uppladdning. Så om du inte använder originalen på din hemsida, men mindre versioner av dem, dvs miniatyrbilder eller utvalda bilder,bör de naturligtvis också optimeras. Detta förvandlar snabbt en bild till flera filer, som också har en flera datainläsningar.

Genomförande: I princip har du två sätt att optimera dina bilder. Antingen optimerar du bilderna innan du laddar upp eller efter eller under uppladdningen. Du kan göra det förstnämnda via online- eller offlineverktyg, det senare kan du göra via lämpliga WordPress Plugins för bildoptimering.

Om du kan integrera komprimering i arbetsflödet på ett användbart sätt är det helt logiskt att optimera bilderna innan du laddar upp dem. Det finns onlineverktyg för detta, till exempel Kraken.io. Eller så kan du minska kvaliteten och därmed filstorleken på dina bilder offline, till exempel direkt i Photoshop. Hur du sparar dig själv det extra Plugin och håll din sida smal.

Den bekvämare lösningen är naturligtvis också här en Plugin . Tillägg som Optimus eller Smush optimerar inte bara huvudbilden, utan också alla variationer av den. Dessutom kan Smush också optimera alla dina befintliga bilder efteråt.

Den Plugins arbeta med en så kallad "förlustfri komprimering". Detta innebär att bildernas filstorlek minskas, men deras synliga kvalitet minskar inte.

Fel 4: Aktivera textkomprimering

Det här felmeddelandet från Google PageSpeed är mycket snabbt att åtgärda och kan avsevärt minska laddningstiden för din sida.

Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Betydelse: Du har redan minskat dina bilder och CSS så mycket som möjligt. Bra jobbat! Men det räcker inte. Nu kan du använda en annan komprimeringsmekanism. Du känner förmodligen till processen från att ladda ner stora datapaket: dessa är vanligtvis i zippad, dvs komprimerad form. Detta gör data mindre vid nedladdning och därmed snabbare nedladdning. Datapaketen måste dock fortfarande packas upp efter nedladdningen. Exakt samma sak händer under sidinställningarna: webbservern levererar de komprimerade datapaketen, webbservern packar upp dem. Detta gör dataöverföring snabbare och minskar sidinläsningstiden.

Genomförande: Antingen är datakomprimeringen redan inställd på serversidan, eller så måste du aktivera den själv. Är du RAIDBOXES -Kund, du behöver inte oroa dig för någonting längre. Eftersom vi har den särskilt starka Brotli-komprimeringen aktiv som standard.

Med följande post i HT-anslutningen kan du också aktivera den så kallade GZIP-komprimeringen manuellt. Förutsatt att du har en Apache-webbserver.

<ifModule mod_gzip.c>
 mod_gzip_on Yes
 mod_gzip_dechunk Yes
 mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
 mod_gzip_item_include handler ^cgi-script$
 mod_gzip_item_include mime ^text/.*
 mod_gzip_item_include mime ^application/x-javascript.*
 mod_gzip_item_exclude mime ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
 </ifModule>
 
 <IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/plain
 AddOutputFilterByType DEFLATE text/html
 AddOutputFilterByType DEFLATE text/xml
 AddOutputFilterByType DEFLATE text/css
 AddOutputFilterByType DEFLATE application/xml
 AddOutputFilterByType DEFLATE application/xhtml+xml
 AddOutputFilterByType DEFLATE application/rss+xml
 AddOutputFilterByType DEFLATE application/javascript
 AddOutputFilterByType DEFLATE application/x-javascript
 </IfModule>

Fel 5: Distribuera statiskt innehåll med en effektiv cacheprincip 

Enligt min mening är hänvisningen till webbläsarcache den överlägset mest irriterande på Google PageSpeed Insights . Eftersom du bara kan ställa in webbläsarcachelagring för dina egna resurser. Webbläsarcachelagring är inte möjligt för externa resurser.

Håll käften Google PageSpeed! Åtgärda de viktigaste felmeddelandena

Betydelse: Webbläsarcache innebär att webbläsaren sparar en statisk version av din sida och inte längre behöver fråga webbservern när du besöker den igen, men sidan är redan laddad.

Genomförande: Antingen har din värd redan aktiverat webbläsarcache på serversidan, eller så kan du ställa in den genom att ändra HTACCESS-filen (glöm inte: den här inställningen fungerar bara på Apache-webbservrar). Exempelkoden nedan anger till exempel webbläsarcachen till en månad, dvs.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 60 seconds"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
</IfModule>

Även här gäller följande: Är du RAIDBOXES är webbläsarcachen redan aktiv som standard.

Mina 2 cent: Utan cache är allt ingenting

Tja, nu har du optimerat din sidas bilder, minskat CSS, komprimerat den och lagt den i rätt ordning och fått dina besökares webbläsare att cachelagra sidan. Alla dessa åtgärder förkortar din sidbelastningstid.

Betydelse: Utan en ordentlig cache kommer du dock att ge mycket av den potentialen. Cachelagring är och förblir den överlägset viktigaste prestationsfaktorn. En cache lagrar innehållet i din WordPress och ser till att hela sidan inte behöver laddas om varje gång. I stället levereras en statisk, färdig redigeringsversion av sidan från en cache. I synnerhet kringgås den långsamma PHP och databasen.

Genomförande: Återigen har värden redan konfigurerat en cache på serversidan eller så använder du en cachelagring Plugin . Här är några mycket kraftfulla Plugins , som cachelagrar stora delar av din sida och leder till en betydande minskning av laddningstiden för återkommande webbplatsbesökare.

Den höga styrkan i cachelagring Plugins är också deras största svaghet. Det kan mycket väl vara så att en cachelagring Plugin saktar ner din sida för första gången besökare. Eftersom desto mer komplicerad är din blogg eller sida, desto mer komplicerad och omfattande måste cachemotorn som cachelagrar din blogg vara. Detta är särskilt relevant för butiker.

Om du driver en jämförelsevis enkel webbplats kan minimalistiska lösningar vara bättre än att cachelagga allroundspelare. En av dessa smala Plugins Till exempel Cache Enabler.

Du bör notera att cachelagring Plugins vanligtvis också minska och sammanfatta CSS eller JavaScript. Därför bör du kontrollera om din cachelagring Plugin inte redan Plugins är överflödigt för CSS-optimering.

Om du använder cachelagring på serversidan rekommenderas att du använder cachelagringsfunktionerna i Plugins inaktivera Autoptimize eller testa om de ger en annan prestandafördel alls.

Slutsats: Med några få Plugins flytta mycket

Du har redan märkt det när du läser: För att optimera CSS, bilder och optimera laddningsordningen finns det Plugins , som tar mycket arbete från dig. Men inte allt arbete. Cachelagring Plugins ger snabbt en märkbar effekt, men är ibland mycket omfattande och erbjuder många konfigurationsalternativ och ibland redundanta funktioner.

I vilket fall som helst, bli mer involverad i Plugins som du använder. Endast om du vet vad som händer när du använder vissa funktioner kan du optimera på ett meningsfullt sätt. En överbelastning av sidan med optimering Plugins tenderar att ge lite.

Och du bör vara noga med att mäta dina framgångar korrekt när du optimerar. Oavsett om du är för hand eller via Plugin optimiert. Använda PageSpeed Insights som en första referenspunkt för att identifiera sårbarheterna på din sida. Missa sedan sidans laddningstid före optimering. Först efter denna inspelning av den ursprungliga positionen är det verkligen meningsfullt att optimera din sida steg för steg. För bara om du känner till laddningstiden före optimering och efter varje optimeringssteg kan du också bestämma vad de enskilda optimeringsåtgärderna har medfört.

Som systemadministratör övervakar Tobias vår infrastruktur och hittar varje justeringsskruv för att optimera prestandan hos våra servrar. På grund av sina outtröttliga ansträngningar är han ofta också Slack som ska hittas.

Kommentarer om den här artikeln

Skriva en kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *.