Google PageSpeed Insights Fel

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

Google PageSpeed Insights är idealisk för att ge dig en snabb översikt över optimeringspotentialen på din webbplats. Idag ska jag visa dig hur du använder denna potential och ökar din PageSpeed-poäng. Du bör dock inte slaviskt följa Google-resultaten. Eftersom PageSpeed-felmeddelandena inte alltid är användbara.

För en tid sedan, i ett av sina blogginlägg, skrev min kollega Caspar Hübinger, låt oss säga, mycket tydliga ord för sinGoogle PageSpeed Insightsresultat som hittats. Och han kritiserar inte bara verktyget, men också användningen av verktyget av användarna. För om du inte vet hur man tolkar och fixar de enskilda optimeringsförslagen kan du snabbt förlora dig själv i den meningslösa jakten på 100 betyg. Men det vore oklokt. Eftersom utopiska höga Google PageSpeed-betyg vanligtvis är slöseri med tid. Viktigare är optimeringen av laddningstiden.

Idag ska jag visa dig hur du får de viktigaste felmeddelandena från Google PageSpeed Insights tolka och optimera sidan i enlighet därmed.

Men innan jag visar dig hur du tolkar de enskilda felmeddelandena och åtgärdar felen, skulle jag först vilja gå tillbaka till hur man googlar Google PageSpeed Insights används på rätt sätt. Eftersom vi ofta har upplevt att användare var starkt fixerade på sin PageSpeed-poäng utan att ha laddningstiden för sin sida i åtanke.

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".

Google PageSpeed-felmeddelanden är inte alltid korrekta och viktiga

Du bör aldrig förlita dig enbart på Googles resultat eller felmeddelanden PageSpeed Insights lämna. Eftersom Google-verktyget inte mäter det viktigaste karakteristiska värdet för din sida: Sidinläsningstiden. För att mäta dessa korrekt rekommenderar jag Webpagetest.org.

Bara om du har sidinläsningstiden i åtanke från början när du optimerar din sida kan du göra meningsfulla uttalanden om optimeringens framgång. Eftersom målet med all optimering alltid bör vara en förbättrad användarupplevelse. Vid prestandaoptimering är detta naturligtvis sidans inläsningstid och den upplevda sidinläsningstiden.

MÄRKA!

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

Från användarens perspektiv är en snabbare sidinläsningstid och mindre sidstorlek alltid en fördel. Den genomsnittliga användarens tålamod och uppmärksamhetsintervall fortsätter att minska (som denna studie från Microsoft visar) - detta är avgörande för e-handel i synnerhet - och fler och fler besökare kommer via mobila enheter. Redan 2016 fick 56 procent av tyskarna regelbundet tillgång till 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å optimeringspotential på din webbplats och tillåter bara några slutsatser om användarupplevelsen. Det låga informativa värdet av Google PageSpeed-felmeddelandena förstärks av det faktum att verktyget inte kan immobiliseras i vissa områden eller bara kan lugnas ner med betydande ytterligare ansträngning.

Till exempel kommer hänvisningen till webbläsarkache alltid att visas när externa resurser – inklusive Googles egna tjänster – integreras. Men dessa resurser kan inte täckas av webbplatsens webbläsarkacheing. Felmeddelandet har ingen relevans för användarupplevelsen på din webbplats, men produceras av själva verktygets logik. I värsta fall tolkas dock meddelandet som om ingen webbläsarkache är aktiv alls.

Så följ inte i första hand Google-betyget, utan laddningstiden. Detta är den enda riktigt viktiga kvantiteten.

Men hur är det med min Google-ranking?

Exemplet på bristen på webbläsarkacheing gör det mycket tydligt varför du inte borde oroas av ett förmodligen dåligt PageSpeed-resultat.

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

Typiskt Google PageSpeed Insights-Felmeddelanden: Webbläsarkacheing 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 besöker vår webbplats på PageSpeed Insights , denna punkt är kritad upp. Detta innebär att vi vet att denna faktor alltid snedvrider våra resultat negativt och därför helt enkelt ignorerar den.

För SEO på din webbplats betyder det: Även för rankningen på Google är laddningstiden och användarupplevelsen mycket viktigare än det konkreta PageSpeed-betyget.

För om du optimerar laddningstiden för din sida 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 relaterade på ett visst sätt.

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

Men nu till optimeringsstegen!

Felmeddelande 1: Komprimera CSS

Enligt vår erfarenhet är detta ett av Googles mest kyliga 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 kompileras (eller i fallet ovan att detta redan har gjorts). En sådan minskning minskar antalet tecken i dokumenten. Detta krymper filstorleken. Kommentarer, blanksteg och formatering tas till exempel bort.

Genomförande: Även om denna anmärkning fungerar avskräckande är genomförandet mycket enkelt. I det här fallet finns det i princip två möjliga lösningar: Om du passar i CSS själv kan du manuellt minska antalet CSS-filer och använda en stenografi när du skapar dem. Dessutom kan du själv minska CSS-filerna via onlineverktyg som CSS Compressor eller CSS Minifier.

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

Naturligtvis finns det också den bekväma lösningen med CSS-minifieringsplugins i WordPress. Vissa plugins gör direkt ett allsidigt slag och kan komprimera och optimera inte bara CSS, men också JavaScript och HTML.

Ytterligare information

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

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

De ovannämnda Minify-plugins används ofta. Eftersom de är bekväma och tar över komprimeringen och sammanfattningen av CSS (och mycket mer) helt automatiskt. Fram till nyligen var det också mycket meningsfullt att kombinera CSS-filer. Under tiden har detta förändrats: Sedan HTTP / 2-standarden introducerades har webbläsare kunnat ladda flera filer från webbservern samtidigt.

Detta innebär att data inte längre nödvändigtvis behöver kombineras, eftersom HTTP/2 tillåter att flera datapaket utbyts samtidigt. HTTP/2 måste ha konfigurerats av.B värden och kan endast användas med ett SSL-certifikat .

Så innan du bestämmer dig för ett plugin med flera dussin funktioner och konfigurationsalternativ, tänk noga på om du behöver det alls. Särskilt om du vågar optimera CSS själv.

Eftersom ett extra plugin kan göra din webbplats långsammare under vissa omständigheter. Särskilt om de andra funktionerna i allround-plugins inte kan utveckla sin fulla potential.

Felmeddelande 2: Eliminera resurser som blockerar rendering

Detta meddelande driver också svettpärlor i pannan hos många användare, eftersom det inte är riktigt så lätt att implementera och även en av Google PageSpeeds eviga kritikpunkter.

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

Betydelse: En webbplats är byggd i en viss ordning. Denna laddningssekvens kan optimeras. PageSpeed klagar nästan alltid på att CSS-filer blockerar denna optimala laddningsordning. Och även med redan mycket väloptimerade sidor (som fallet caspar Hübinger visar). Ändå kan anteckningen vara mycket värdefull för laddningstidsoptimering. I princip talar den här anteckningen om att JavaScript- eller CSS-kod som är viktig för att ett element ska läsas in, till exempel en bakgrundsfärg, ännu inte är tillgänglig när elementet läses in. Som ett resultat kommer det inte att visas 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 laddad.

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>

Du kan implementera det här optimeringsmåttet på två sätt: Du kan röra koden själv och flytta CSS-koderna till rubriken, eller så kan du låta ett plugin göra jobbet. Återigen hjälper plugins som Better WordPress Minify.

Google PageSpeed Insights Felmeddelanden - Utdrag från plugin bättre WordPress Minify

Till exempel visas Minify-plugin i alternativen som CSS-filer redan har flyttats till rubriken. Du kan också manuellt lägga till fler CSS-resurser här.

Google PageSpeed Insights Felmeddelanden – Utdrag från optimeringsinsticksprogrammet Autoptimize

Plugin Autoptimize är å andra sidan ett allsidigt slag: Du väljer alternativen för alla CSS-filer som inte är uteslutna från processen.

Utdragen från plugins-alternativen visar: Även plugin-varianten kan inte implementeras utan en grundläggande förståelse för processen. Så du måste också bekanta dig med plugins.

Felmeddelande 3: Koda bilder effektivt

Även vid denna tidpunkt klagar PageSpeed Insights ofta runt. Detta fall är dock nästan alltid snabbt och enkelt att implementera 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 i laddningstiden för sin sida. Bilder är 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 en betydande mängd data.

För en bild är sällan bara en bild. WordPress genererar automatiskt flera miniatyrbilder av bilden när du laddar upp. Så om du inte använder originalen på din hemsida, men mindre versioner av dem, dvs miniatyrbilder eller presenterade bilder, bör dessa naturligtvis också optimeras. En bild blir snabbt flera filer, vilket också innebär en flera datainläsningar.

Genomförande: I princip har du två alternativ för att optimera dina bilder. Antingen optimerar du bilderna före uppladdningen eller efter eller under uppladdningen. Den förra kan du göra via online- eller offlineverktyg, det senare gör du via motsvarande WordPress bildoptimeringsplugins.

Om du kan integrera komprimering i arbetsflödet på ett meningsfullt sätt är det vettigt att optimera bilderna innan du laddar upp. 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. Så du sparar dig själv det extra pluginet och håller din webbplats smal.

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

Bland annat fungerar plugins med en så kallad "förlustfri komprimering". Detta innebär att bildernas filstorlek minskas, men deras synliga kvalitet minskar inte.

Felmeddelande 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 storleken på webbplatsens bilder och CSS så mycket som möjligt. Bra jobbat! Men det är inte allt. För nu kan du använda ännu en komprimeringsmekanism. Du känner förmodligen till processen från att ladda ner stora datapaket: Du har dem vanligtvis i zippad, dvs komprimerad form. Detta gör data mindre vid nedladdning och nedladdning snabbare. Datapaketen måste dock fortfarande packas upp efter nedladdningen. Exakt samma sak händer med sidkonstruktion: Webbservern levererar datapaketen komprimerade, webbservern packar upp dem. Detta gör dataöverföringen 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 Raidboxeskund behöver du 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 HTaccess 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>

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

Enligt min mening är hänvisningen till webbläsarkache den överlägset mest irriterande på Google PageSpeed Insights. Eftersom du bara kan ställa in webbläsarkache för dina egna resurser. Cachelagring av webbläsare är inte möjlig för externa resurser.

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

Betydelse: Cachelagring av webbläsare innebär att webbläsaren lagrar en statisk version av din sida och inte längre behöver begära webbservern vid ett upprepat besök, men sidan är redan laddad.

Genomförande: Antingen har värden redan aktiverat cachelagring av webbläsare på serversidan, eller så kan du ställa in den genom att manipulera HTaccess-filen (glöm inte: Den här inställningen fungerar bara på Apache-webbservrar). Exempelkoden nedan anger till exempel webbläsarens cacheminne till en månad, dvs den statiska versionen av din sida lagras i besökarens webbläsare i en månad.

<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>

Återigen, är du Raidboxesär webbläsarcache-cachelagringen redan aktiv som standard.

Mina 2 cent: Utan cache är allt ingenting

Tja, nu har du optimerat sidans bilder, minskat, komprimerat och satt CSS i rätt ordning och fått besökarnas webbläsare att cachelagra sidan. Alla dessa åtgärder förkortar sidans sidinläsningstid.

Betydelse: Utan en ordentlig cache förlåter du dock mycket av denna potential. Caching är och förblir den överlägset viktigaste prestandafaktorn. En cache cache cachen innehållet på din WordPress-webbplats och säkerställer att hela sidan inte behöver laddas om varje gång. I stället levereras en statisk, dvs redan renderad variant av din sida 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 ett cache-plugin för cachelagring. 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 återvändande webbplatsbesökare.

Den höga styrkan hos cache-plugins är också deras största svaghet. Det kan mycket väl vara så att ett cache-plugin gör din webbplats långsammare för första gången besökare till en början. Eftersom ju mer komplicerad din blogg eller sida är, desto mer komplicerad och omfattande cachemotor som cachelagrar din blogg måste 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 cacheföra allroundspelare. En av dessa lätta plugins är till exempel Cache Enabler.

Du bör notera att cache-plugins vanligtvis också tar över minskningen och aggregeringen av CSS eller JavaScript. Därför bör du kontrollera om ditt cache-plugin inte redan gör plugins för CSS-optimering överflödiga.

Om du använder cachelagring på serversidan är det lämpligt att inaktivera cachelagringsfunktionerna för plugins, till exempel Autoptimize, eller att testa om de ger någon ytterligare prestandafördel alls.

Slutsats: Flytta mycket med bara några plugins

Du har redan märkt det medan du läser: För optimering av CSS, bilder och optimering av laddningsordningen finns det plugins som tar mycket arbete från dina händer. Men inte allt arbete. Cacheing plugins ger också snabbt en märkbar effekt, men är ibland mycket omfattande och erbjuder många konfigurationsalternativ och delvis redundanta funktioner.

Var noga med att titta närmare på de plugins du använder. Bara om du vet vad som händer när du använder vissa funktioner kan du också optimera meningsfullt. Att överbelasta sidan med optimeringsplugins tenderar att vara till liten nytta.

Och när du optimerar bör du se till att mäta din framgång korrekt. Oavsett om du optimerar för hand eller via plugin. Använda PageSpeed Insights som en första referenspunkt för att identifiera de svaga punkterna på sidan. Mät sedan laddningstiden för din sida före optimering. Först efter denna inspelning av den ursprungliga situationen är det verkligen meningsfullt att optimera din webbplats steg för steg. För bara om du känner till laddningstiden före optimeringen och efter varje optimeringssteg kan du också bestämma vad de enskilda optimeringsåtgärderna har medfört.

Tyckte du om artikeln?

Med din recension hjälper du oss att förbättra vårt innehåll ytterligare.

Skriva en kommentar

Din e-postadress kommer inte att publiceras.