Google PageSpeed Insights er uden tvivl et nyttigt værktøj til webmastere, udviklere og alle typer websidedesignere. Vi har dog bemærket, at mange mennesker bruger alt for meget tid på, at forsøge at score 100/100 i denne test, når de arbejder på at optimere deres webside.
I realiteten er det slet ikke den måde, at Google PageSpeed Insights skal bruges på, og det er heller ikke værd at stræbe efter. Hvis du derimod vælger at fokusere på, at implementere platformens anbefalinger i stedet for at fiksere på tallene øverst på siden, vil du kunne skabe meget mere værdi for din webside.
Dette indlæg er en omfattende guide til, hvordan Google PageSpeed Insights bruges til din fordel. Vi vil dække, hvordan Google bruger din score, samt hvordan du integrerer de anbefalinger, du modtager.
Lad os komme i gang!
En introduktion til Google PageSpeed Insights
Hvis du endnu ikke er bekendt med Google PageSpeed Insights, er det et værktøj, der bruges til at teste websiders ydeevne. Du kan indtaste en hvilken som helst webaddresse, og få den analyseret:
Google leverer derefter en samlet score på en skala op til 100 for det websted du har testet, baseret på adskillige effektive fremgangsmåder for optimering af ydeevne:
Udover dette resultat, vil du også kunne se flere anbefalinger fra Google om, hvordan du kan forbedre din ydeevne (og dermed din PageSpeed Insights-score):
Fra og med 2018 beregnes PageSpeed Insights-scoringer via Lighthouse, som er Googles open source automatiseret værktøj til forbedring af websiders overordnede kvalitet. Denne platform kan evaluere alle mulige faktorer, herunder ydelse, tilgængelighed, progressive webapps osv.
Hvis du gerne vil se Lighthous’ omfattende evaluering af din webside, skal du bruge Googles måleværktøj:
Ud over at udføre en præstationsbedømmelse, der ligner meget den, som Google PageSpeed Insights kører, vil du også modtage en score for tilgængelighed, bedste praksis og SEO (Search Engine Optimization).
Sandheden om at score 100/100 i Google PageSpeed Insights
Som vi nævnte i begyndelsen af dette indlæg, ser vi mange websideejere og -udviklere, der bliver besat af at opnå en perfekt PageSpeed Insights-score. Desværre har de en tendens til at overse det vigtigste aspekt i forhold til testresultaterne, som i virkeligheden er anbefalingerne.
Selvom du bestemt bør stræbe efter at forbedre din websides indlæsningstid så meget som muligt, er det faktisk ikke så vigtigt at score 100/100 i Google PageSpeed Insights. For det første, er det slet ikke en altafgørende test i forhold til ydeevne.
I modsætning til PageSpeed Insights, giver Pingdom Tools dig mulighed for, at teste din websides ydeevne fra forskellige placeringer:
Du kan også køre test på platforme som GTmetrix (som kombinerer dine score fra PageSpeed Insights og YSlow) og WebPageTest. Chancerne er, at dine score på tværs af disse forskellige værktøjer ikke stemmer helt overens, hvilket viser dig, hvor vilkårlige disse tal kan være.
Det, der virkelig betyder noget, er den faktiske hastighed på din webside. For at sætte det i perspektiv har vi set websider med gennemsnitlige indlæsningstider på under 500 millisekunder (hvilket er ekstremt hurtigt!), Som ikke har en 100/100 score på PageSpeed Insights.
Den anden faktor, der bør have indflydelse på din tilgang til hastighedsoptimering, er den opfattede ydeevne på dit websted. Dine besøgende er ligeglade med, hvad din Google PageSpeed Insights-score er. De vil bare gerne kunne se dit indhold så hurtigt som muligt.
Formålet med at teste din websides ydeevne med Google PageSpeed Insights handler egentlig ikke om, at opnå en høj score. Derimod handler det om, at opfange eventuelle problemer på din webside, så du kan optimere dem og reducere både dine faktiske og opfattede indlæsningstider.
Google anvender PageSpeed Insights på følgende måde
Ud over at påvirke din websides brugeroplevelse (UX) spiller ydeevne også en rolle i SEO. Når an tænker på, at PageSpeed Insights drives af verdens største og mest populære søgemaskine, er det naturligt at tænke, at din score muligvis påvirker din rangering på søgeresultatsiderne (SERP) – i det mindste hos Google.
Google bruger nu også PageSpeed Insights til at bestemme placeringer – på en måde. Websidehastighed er helt enkelt en rangerende faktor. Din ydelsestestscore kan give dig en ret god idé om, hvor du står på denne front.
Google tager dog højde for mere end blot tallet i cirklen øverst i dine PageSpeed-resultater. At ramme en 100/100 garanterer ikke en topplads på resultatsierne.
Når det er sagt, er PageSpeed Insights-resultaterne under alle omstændigheder nyttige, når du arbejder på at forbedre din SEO. For eksempel har den mobile sidehastighed siden 2018 været en rangeringsfaktor hos Google. Du vil bemærke, at din ydelsestest indeholder data omkring både dit websteds desktop- og mobilversion:
Da mere end 73 procent af mobile internetbrugere hævder, at de er stødt på websider, der tager for lang tid at indlæse, er oplysningerne i fanen Google PageSpeed Insights Mobile uvurderlige. Hvis du bruger disse anbefalinger til at reducere indlæsningshastighederne på smartphones og andre enheder, bør det give dig en konkurrencefordel.
Anbefalinger fra Google PageSpeed Insights (24 måder at forbedre ydeevnen på)
Vi har talt meget om anbefalingerne fra Google PageSpeed Insight i dette indlæg, og det er netop dem, som er de væsentlige, da de er langt mere værdifulde end din faktiske score. Derfor har vi dedikeret resten af dette indlæg til dem.
Før vi dykker ned i de individuelle forslag, skal du dog forstå forskellen mellem dine Field data og Lab data. Førstnævnte sammenligner dit websted med andre i Chromes brugeroplevelses-rapport for de sidste 30 dage.
Der findes også to diagrammer, der viser, hvordan din gennemsnitlige First Contentful Paint (FCP) og First Input Delay (FID) ligger:
På billedet ovenfor er vores websteds FCP omtrent den samme som 45 procent af siderne i den 75. percentil, og vores FID er omtrent den samme som 9 procent af det 95. percentil.
Lab data viser specifikke data for en simuleret sideindlæsning:
Du vil bemærke, at vores Field Data og Lab Data ikke matcher helt. Det er helt normalt. Lab Data oprettes under faste betingelser, mens Field Data bruger faktiske indlæsningshastigheder indsamlet over en tidsperiode.
Samlet set, skal Field Data og Lab Data give dig en idé om dit websteds faktiske indlæsningstid. Som vi nævnte tidligere, er dette endnu vigtigere end din samlede PageSpeed-score, så du bør være opmærksom på disse tal.
Når du har taget højde for disse oplysninger, er det tid til at begynde at forbedre din websides ydeevne ved at implementere Google PageSpeeds anbefalinger.
1. Fjern ressourcer til blokering af gengivelse
En af de mere almindelige anbefalinger fra Google PageSpeed Insights er, at man bør fjerne ressourcer til blokering af gengivelse:
Dette vedrører JavaScript- og CSS-scripts, der forhindrer din side i at indlæse hurtigt. Den besøgendes browser skal downloade og behandle disse filer, før resten af siden kan vises, så hvis der ligger en masse ‘over skillelinjen’, kan det have negativ indflydelse på din websides hastighed.
Du kan lære mere om dette problem i vores guide til eliminering af gengivelsesblokerende scripts. Hvad Google angår, er der to løsninger, du skal overveje:
- Hvis du ikke har meget JavaScript eller CSS, kan du integrere dem, for at slippe af med advarslen. Denne proces henviser til at inkorporere din JavaScript og/eller CSS i din HTML-fil. Du kan gøre dette med et plugin som Autoptimize. Dette gør sig imidlertid kun gældende for meget små websteder. De fleste WordPress-websider har nok JavaScript til, at denne metode rent faktisk kan gøre din side langsommere.
- Den anden mulighed er, at udskyde din JavaScript. Denne attribut downloader din JavaScript-fil mens HTML fortolkes, men udfører den først, når tolkningen er afsluttet. Scripts med denne attribut udføres desuden i den rækkefølge hvori de forekommer på siden.
Du kan finder en liste over de ressourcer, der er mest påvirket af dette problem under anbefalingen i dine PageSpeed-resultater.
Se denne video for at finde ud af mere om, hvordan du fjerner render blocking ressourcer:
2. Undgå kæde af kritiske anmodninger
Konceptet med chaining critical requests (kritiske anmodninger) har at gøre med CRP (Critical Rendering Path) og hvordan browsere indlæser dine sider. Visse elementer – som JavaScript og CSS, som vi drøftede ovenfor – skal indlæses helt, før din side bliver synlig.
Som en del af denne anbefaling, vil Google PageSpeed Insight vise dig anmodningskæder for den side, du analyserer:
Dette diagram viser dig en række anmodningskrav, der skal opfyldes, før din side bliver synlig. Det fortæller dig også størrelsen på hver ressource. Ideelt set ønsker du at minimere antallet af anmodningskrav såvel som deres størrelser.
Flere af metoderne til at opfylde disse mål er dækket af andre anbefalinger beskrevet i dette indlæg, herunder:
- Fjernelse af ressourcer til blokering af gengivelse
- Udskydelse af “offscreen”-billeder
- Minificering af CSS og JavaScript
Derudover kan du optimere rækkefølgen, som siden indlæses i for at forkorte CRP. Dette betyder, at indhold over skillelinjen flyttes op til toppen af din HTML-fil. Du kan lære mere om optimering af CRP i vores indlæg, “How to Optimize the Critical Rendering Path in WordPress”.
Det er vigtigt at bemærke, at der ikke findes et magisk antal kritiske anmodningskæder, som du skal arbejde dig ned til. Google PageSpeed Insights regner ikke denne revision som ‘bestået’ eller ‘mislykket’, i modsætning til mange af dens andre anbefalinger. Disse oplysninger kun til rådighed for at hjælpe dig med at forbedre indlæsningshastigheden.
3. Hold antallet af anmodninger og overførselsstørrelser nede
Jo flere anmodninger browseren skal forholde sig til for at indlæse dine sider og jo større ressourcer din server returnerer som svar, desto længere tager det for din webside at indlæse. Derfor giver det mening, at Google anbefaler, at du minimerer antallet anmodninger og mindsker størrelsen på dine ressourcer.
Ligesom ved anbefalingen om, at undgå kritiske anmodningskæder, resulterer denne anbefaling heller ikke i en ‘bestået’ eller ‘dumpet’-status. I stedet vil du blot se en liste over antallet af anmodninger, der er foretaget, og størrelsen på dem:
Der findes ikke et ideelt antal anmodninger eller en maksimal størrelse, man bør huske på. I stedet anbefaler Google, at du indstiller disse standarder på egen hånd ved at oprette et resultatbaseret budget, hvilket er et sæt definerede mål, der kan være relateret til aspekter som:
- Maksimale billedstørrelser
- Antallet af anvendte webfonte
- Hvor mange eksterne ressourcer du ringer op
- Størrelsen på scripts og rammer
Oprettelse af et resultatbaseret budget giver dig et sæt standarder, som du kan holde dig til. Når du følger dit eget budget, kan du træffe beslutninger om, hvorvidt ressourcer skal fjernes eller optimeres for at holde sig til dine forudbestemte retningslinjer. Du kan lære mere om, hvordan du opretter et resultatbaseret budget i Googles egen guide.
4. Komprimering af CSS
CSS-filer er ofte større end nødvendigt for at gøre dem lettere for mennesker at aflæse. De kan muligvis indeholde forskellige returtaster og mellemrum, som ikke er nødvendige for, at computere kan forstå deres indhold.
Minificering af din CSS er en proces, som komprimerer dine filer ved at fjerne unødvendige tegn, mellemrum og duplikationer. Google anbefaler denne praksis, fordi den reducerer dine CSS-filstørrelser, og kan derfor forbedre indlæsningshastigheden:
Disse hastighedsfordele er grunden til, at Kinsta indbyggede en kode minifikationsfunktion i MyKinsta-dashboardet. Kunder kan vælge at tilvælge automatisk kode minifikation for deres CSS- og JavaScript-filer, hvilket gør deres websteder hurtigere uden manuel indsats.
Hvis du ikke er Kinsta-kunde, anbefaler vi at bruge et plugin såsom Autoptimize eller WP Rocket til at formindske dine CSS-filer.
5. Komprimer JavaScript
Ligesom CSS-filstørrelsen kan komprimeres, gør det samme sig gældende for dine JavaScript-filer:
Autoptimize eller WP Rocket kan også klare denne opgave for dit WordPress-websted.
6. Fjern overflødigt CSS
Enhver kode i dit stilark er indhold, der skal indlæses før at din side kan blive synlig for brugerne. Hvis der er CSS på websiden, som faktisk ikke er nyttig, lægger det unødvendigt og trækker din præstation ned.
Derfor anbefaler Google at fjerne overflødigt CSS:
Løsningen her er i bund og grund den samme som for eliminering af blokerende gengivelse af CSS. Du kan integrere eller udskyde stilarter på den måde, der giver bedst mening for dine sider. Du kan også bruge et værktøj som Chrome DevTools til at lokalisere overflødigt CSS, der skal optimeres.
7. Minimer hovedtrådens arbejdsbyrde
‘The main thread (Hovedtråen)’ er det primære element i brugerens browser, der er ansvarlig for at omdanne kode til en webside, som besøgende kan interagere med. Den analyserer og udfører HTML, CSS og JavaScript. Derudover har den ansvaret for håndtering af brugerinteraktioner.
Dette betyder, at når hovedtråden arbejder sig igennem din websidekode, kan den ikke håndtere brugeranmodninger samtidigt. Hvis hovedtrådens arbejde på websiden tager for lang tid, kan dette resultere i dårlige UX og langsom indlæsningshastighed.
Google PageSpeed markerer de sider, hvorpå det tager længere end fire sekunder for hovedtråden at gennemføre arbejdet og præsentere en brugbar webside:
Nogle af de metoder, der bruges til at reducere hovedtrådens arbejde, er allerede blevet dækket i andre sektioner af dette indlæg, herunder:
- Komprimer din kode
- Fjernelse af overflødig kode
- Implementering af cache
Du kan dog også overveje kodedeling. Denne proces involverer opdeling af din JavaScript i bundter, der udføres, når der er brug for det, i stedet for at browseren først skal indlæse dem alle før siden bliver interaktiv.
Webpack bruges ofte til at implementere kodedeling. Bemærk, at dette er en temmelig avanceret teknik, og begyndere bør nok afholde sig fra at gøre dette uden hjælp.
8. Reducer udførelsestid for JavaScript
JavaScript-udførelse er ofte den mest fremtrædende bidragyder til hovedtrådens arbejde. PageSpeed Insights har en separat anbefaling, der advarer dig, hvis arbejdsbyrden påvirker din websides ydeevne:
Ovenstående metoder til reduktion af hovedtrådens arbejdsbyrde bør også fjerne advarslen fra dine PageSpeed-resultater.
9. Reducer serverens responstid (TTFB)
Time to First Byte (TTFB) måler, hvor lang tid det tager for en browser at modtage den første byte med data fra dit websteds server, når du fremsætter en anmodning. Selvom dette ikke er det samme som din samlede webstedshastighed, er det naturligvis godt for dit websteds præstation at have en lav TTFB.
Derfor anbefaler Google PageSpeed Insight at serverens responstid reduceres. Hvis du opnår en lav TTFB, vil du se denne meddelelse under Passed audits:
Der er flere faktorer, der kan påvirke din TTFB. Nogle metoder til sænkning af denne inkluderer:
- At vælge en webhostingudbyder af høj kvalitet, der fokuserer på hastighed
- Brug af temaer og plugins, som ikke er tunge
- Reducer antallet af plugins, der er installeret på dit websted
- Brug af et Content Delivery Network (CDN)
- Implementering af browser-cache
- Valg af en solid DNS-leverandør (Domain Name System)
Vores indlæg om TTFB er en fremragende kilde til flere detaljer omkring optimering på dette område.
10. Korrekt billedstørrelse
Mediefiler såsom billeder kan virkelig trække ned i din websides ydeevne, og derfor er korrekt billedstørrelse en simpel måde at reducere din indlæsningshastighed på:
Hvis din side indeholder billeder, der er større end nødvendigt, bruges CSS til at ændre dem til en korrekt størrelse. Dette tager længere tid end blot at indlæse billederne i den rigtige størrelse oprindeligt, hvilket i sidste ende påvirker din sides ydeevne.
For at løse dette kan du enten uploade billeder i de rigtige størrelser eller anvende ‘responsive billeder’. Dette indebærer oprettelse af forskellige billedstørrelser til forskellige enheder.
Du kan gøre dette ved hjælp af srcset-attributten, der føjes til <img> -koden for at specificere alternative billedfiler i forskellige størrelser. Browserne kan aflæse denne liste og bestemme, hvilken mulighed der passer bedst til den pågældende skærm og levere den version af dit billede.
Lad os for eksempel sige, at du har et headerbillede, og at du vil gøre det responsivt. Du kan uploade tre versioner af billedet i 800, 480 og 320 pixels i bredden. Derefter anvender du srcset-attributter som disse:
<img srcset="header-image-800w.jpg 880w,
Header-image-480w.jpg 480w,
Header-image-320w.jpg 320w"
sizes="(max-width: 320px) 280px,
(max-width: 480px) 440px,
800px"
src="header-image-800w.jpg">srcset-attributter specificerer de forskellige tilgængelige filer, og size-attributter fortæller browseren, hvilken der skal bruges baseret på den aktuelle skærmstørrelse.
11. Udskyd “offscreen”-billeder
Processen med at udskyde billeder på skærmen er mere almindeligt kendt som lazy-loading. Dette betyder, at i stedet for at få browseren til at indlæse hvert billede på en side før indholdet øverst på siden vises, så vil browseren i stedet kun indlæse de billeder, der er umiddelbart synlige.
Hvis der er mindre der skal forudindlæs før siden bliver synlig, vil det give bedre ydeevne, og derfor anbefaler Google at gøre brug af denne metode:
Der er flere WordPress-plugins, der er lavet specielt til lazy-loading, herunder a3 Lazy Load og Lazy Load by WP Rocket. Forskellige plugins til billed- og ydelsesoptimering, såsom Autoptimize, har også doble indlæsningsfunktioner. Se vores komplette guide til Lazy loading af billeder og videoer på WordPress.
12. Effektiv kodning af billeder
Som vi nævnte tidligere i dette indlæg, har billeder en betydelig indflydelse på din websides ydeevne. En af de mest basale, men også en af de bedste optimeringsmetoder du kan bruge, er komprimering, som kan hjælpe med at reducere filstørrelser, så de indlæses hurtigere. Det er også den primære metode, hvis man følger Googles anbefaling om effektivt kodning af billeder:
Målet er, at man opnår den mindst mulige filstørrelser uden at ofre kvaliteten af selve billederne. Plugins som Imagify og Smush kan hjælpe med denne opgave. Du kan lære mere om dem i vores guide til billedoptimering.
Andre emner, der har indflydelse på, om du ‘består’ eller ‘dumper’ revisionen af effektiv billedkodning inkluderer:
- Levering af billeder i den rigtige størrelse
- Implementering af lazy-loading (udskydelse af “offscreen”-billeder)
- Konvertering af billeder til next-gen-filformater, f.eks. WebP
- Brug af videoformater til animeret indhold, f.eks. GIF’er
Ud over at komprimere dine billeder, kan du ligeledes følge trinnene beskrevet andetsteds i dette indlæg med henblik på at imødekomme anbefalingerne.
13. Upload billeder i Next-Gen-format
Der er nogle billedfilformater, der indlæses hurtigere end andre. Desværre er dette ikke de almindeligt anvendte PNG– eller JPEG-formater. WebP–billeder er ved at blive den nye standard, og Google PageSpeed vil informere dig, hvis dine billeder ikke overholder de tilladte standarder:
At imødekomme denne anmodning kan virke som en udfordring, da du sandsynligvis allerede har masser af billeder liggende på din WordPress-side. Heldigvis er der plugins, der kan hjælpe. For eksempel, Imagninify og Smush tilbyder begge en WebP-konverteringsfunktion.
14. Brug videoformater til animeret indhold
GIF’er kan være en effektiv form for visuelt indhold i forskellige situationer. Vejledninger, funktionsanmeldelser og endda humoristiske animationer kan alle være med til at løfte dine indlæg og gøre dem sjovere og skabe mere værdi for læserne.
Desværre skabes disse fordele på bekostning af sidens ydeevne. GIFs er krævende at indlæse, og derfor anbefaler PageSpeed Insights at uploade det som videoindhold i stedet:
Desværre er konvertering af GIF til videoformat ikke det mest enkle proces. Først og fremmest skal du beslutte, hvilken videotype du vil bruge:
- MP4: Producerer lidt større filer, men er kompatibel med de fleste større browsere.
- WebM: Den mest optimerede videotypeformat; dog har den begrænset browserkompatibilitet.
Når du har truffet det valg, der giver mest mening for dit websted, skal du konvertere filformaterne. Den bedste måde at gøre dette på er via kommandolinjen. Til at starte med, skal du installere FFmpeg. Dette er et open source-værktøj til konvertering af filformater:
Åbn derefter kommandolinje-grænsefladen og kør følgende kommando:
ffmpeg -i input.gif output.mp4Dette konverterer GIF’en med filnavnet input.gif til en MP4-video med filnavnet output.mp4. Ændring af format er dog kun begyndelsen. Du skal nu integrere den konverterede video på din WordPress-side på en måde, der får den til at se ud som en animeret GIF.
Integrering af videoindhold med animationer
Hvis du nogensinde har set en GIF, har du sandsynligvis bemærket, er de er lidt anderledes end normale videoer. De afspilles normalt automatisk og kører på en loop, og de er lydløse. Integrering af din nye MP4- eller WebM-fil på din WordPress-side frembringer ikke disse egenskaber.
Du kan dog genskabe dem med en meget simpel kode. Upload din video til dit mediebibliotek, og tilføj herefter følgende til den side eller det indlæg, hvor du vil inkludere din GIF:
<video autoplay loop muted playsinline>
<source src="output.mp4" type="video/mp4">
</video>Koderne vil tilføje de specificerede egenskaber til din video, så den vises mere ‘GIF-lignende’. Du skal blot tilpasse filnavnet og typen til at matche den for din ressource. Hvis du ønsker flere detaljer om dette emne foreslår vi, at du læser Googles guide omkring konvertering af GIF’er til video.
15. Sørg for, at teksten forbliver synlig under indlæsning af webfont
Ligesom billeder, har tekst også en tendens til at være store filer, der tager lang tid at indlæse. I nogle tilfælde skjuler browseren muligvis teksten indtil den tekst du bruger er færdigindlæst, hvilket vil resultere i denne anbefaling fra Google PageSpeed Insights:
Google råder dig til, at løse dette problem ved at anvende Font Display API-swap-direktivet i din @font-face style. For at gøre dette skal du åbne dit stilark (style.css) og tilføje følgende efter src-attributten under @font-face:
font-display: swap
Du kan lære mere om optimering af webtekst i vores indlæg “Sådan ændrer du skrifttyper i WordPress“, samt vores dybdegående guide til hosting af lokale fonts.
16. Aktivering af tekstkomprimering
Google PageSpeed Insights Enable text compression (Aktivering af tekstkomprimering) henviser til brugen af GZIP-komprimering:
I nogle tilfælde (som du kan se på billedet ovenfor) aktiveres tekstkomprimering automatisk på din server. Hvis dette ikke er tilfældet for dit websted, har du et flere muligheder for at imødekomme denne anbefaling.
Den første mulighed er, at installere et plugin med en GZIP-komprimeringsfunktion. WP Rocket er en holdbar løsning, hvis du er villig til at betale for det.
Du kan også komprimere din tekst manuelt. Dette involverer redigering af din .htaccess-fil, som kan være risikabelt, så sørg for, at du har en nylig backup til rådighed.
De fleste WordPress-websteder kører på Apache-servere. Koden til aktivering af GZIP-komprimering ser sådan ud:
<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent
</IfModule>
Den skal tilføjes efter #END i din .htaccess-fil. Hvis du tilfældigvis har din WordPress-side på en Nginx-server, skal du i stedet tilføje følgende kode til din nginx.conf-fil:
36 gzip on;
37 gzip_disable "MSIE [1-6]\.(?!.*SV1)";
38 gzip_vary on;
39 gzip_types text/plain text/css text/javascript application/javascript application/x-javascript;Hvis du gerne vil kontrollere din websides tekstkomprimering, foreslår vi, at du bruger et værktøj som GiftOfSpeed:
Dette vil give dig besked, om GZIP-komprimeringen er implementeret, samt hvilken type server dit websted kører på og et par andre nøgledetaljer.
17. Forudgående forbindelse til vigtige kilder
Der er stor chance for, at du som minimum har en tredjepartsressource på dit websted – Google Analytics er et almindeligt mødt eksempel. Det kan tage tid for browsere at etablere en forbindelse til disse ressourcer, hvilket bremser dine indlæsningshastighed.
Brug af preconnect-attributter kan med det samme fortælle browseren, at der er tredjeparts-scripts på din webside, der skal indlæses. På den måde kan processen med at anmode om disse tredjeparts-scripts påbegynde så hurtigt som muligt, hvilket vil forbedre din ydeevne.
Hvis Google mener, at din side kunne drage fordel af denne teknik, vil du få vist forslaget Preconnect to required origins:
Der er et par måder at gå omkring implementering af denne optimeringsstrategi. Hvis du har det godt med at redigere dine WordPress-temafiler, kan du tilføje et linktag til din header.php-fil. Her er et eksempel:
<link rel=“preconnect” href=“example.com”>I dette tilfælde fortæller tagget browseren, at den er nødt til at oprette forbindelse til example.com så hurtigt som muligt. Google PageSpeed Insights viser alle relevante ressourcer, som du skal tilføje link-tags for med “preconnect”-attributter.
Den anden mulighed er, at bruge et plugin for at opnå den samme effekt. Perfmatters inkluderer en funktion til forudgående forbindelse (ansvarsfraskrivelse: Jeg er en af grundlæggerne af Perfmatters). WP Rocket og Pre* Party Resource Hints har lignende funktioner.
18. Forudindlæsning af nøgleanmodninger
Ligesom med anbefalingen Forudgående forbindelse til vigtig kilde, kan du ved at implementere dette forslag minimere antallet af anmodninger, som browsere skal foretage til din websides server. I stedet for at oprette forbindelse til tredjepartsressourcer, henviser forudindlæsning af nøgleanmodninger til at indlæse kritiske koder på din egen server:
Implementering af denne teknik ligner også meget metoden fra en foregående anbefaling. I din header.php-fil, kan du tilføje link-tags, der specificerer de ressourcer, der er anført i PageSpeed Insights:
<link rel=“preload” href=“example.com”>Du kan også inkorporere dette tag ved hjælp af Perfmatters, WP Rocket eller Pre * Party Resource Hints.
19. Undgå omdirigering af flere websider
Omdirigeringer bruges, når du vil have en URL til at pege over til anden URL. De oprettes ofte, når du flytter eller sletter en side på dit websted. Selvom der generelt set ikke er noget galt i at bruge omdirigeringer, så forårsager de yderligere forsinkelser i indlæsningstiden.
Hvis du har for mange omdirigeringer på din webside, vil du muligvis støde på denne anbefaling i Google PageSpeed Insights:
Det eneste, du kan gøre som svar på denne anbefaling er at sikre, at du kun bruger omdirigeringer, når det er absolut nødvendigt. Du kan lære mere om oprettelse af omdirigeringer i vores indlæg, “WordPress Redirect – Best Practices for Better Performance”.
20. Vis statiske aktiver med en effektiv cachepolitik
Hvis du har brugt Google PageSpeed Insights i et stykke tid, kender du muligvis denne anbefaling bedre som cacheadvarslen om udnyttelse af browseren. I version 5, hedder den nu Vis statiske aktiver med en effektiv cachepolitik
For at imødekomme dette forslag har vi brug for at gennemgå flere punkter. Det første drejer sig om, hvad “caching” egentligt betyder. Kort sagt, er det en proces, hvor browsere gemmer kopier af dine sider, så de kan indlæses hurtigere næste gang du besøger siden.
Den mest almindelige måde WordPress-websider implementerer cache på, er via plugins. WP Rocket og W3 Total Cache er populære muligheder. Nogle hostingudbydere – herunder Kinsta – muliggør cache via deres servere. Undersøg, om din host eventuelt tilbyder samme løsning inden du vælger at installere et cache-plugin.
Når du har aktiveret cache på dit websted, kan du derefter tage dig af den anden del af anbefalingen, som er din cachepolitiks ‘effektivitet’. Browsere renser med regelmæssige tidsperioder deres cacher for at genopfriske dem med opdaterede kopier.
Ideelt set, bør denne tidsperiode hellere være længere end kort. Hvis browsercachen ryddes fra dit websted med et par timers mellemrum, modarbejder det formålet med at bruge denne teknik i første omgang. Du kan optimere udløbsperioden for cachen ved at anvende headerne Cache-Control og Expires.
Tilføjelse af cache-control headers
Brug følgende kode til at tilføje Cache-Control-headers i Nginx:
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}Tilføje dette til din servers konfigurationsfil. I ovenstående eksempel, er de specificerede filtyper indstillet til at udløbe efter 30 dage.
Hvis du anvender en Apache-servere, bør du i stedet bruge dette fragment til .htaccess-filer:
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
Tilføj denne kode før #BEGIN WordPress eller efter #END WordPress. I dette eksempel er cache udløbsperioden indstillet til 84.600 sekunder.
Tilføjelse af expires headers
Cache-kontrol headere er stort set standard nu. Der er dog nogle værktøjer (inklusive GTMetrix), der stadig tjekker for Expires-headere.
Du kan tilføje expires headers til en Nginx-server ved at inkorporere følgende i din serverblok:
location ~* \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* \.(pdf|css|html|js|swf)$ {
expires 2d;
}Du bør indstille forskellige udløbstider baseret på filtyper. Apache-servere producerer de samme resultater, hvis du tilføjer denne kode til din .htaccess-fil:
## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##Endnu en gang skal du tilføje denne kode, enten før #BEGIN WordPress eller efter #END WordPress.
Effektiv caching af Google Analytics
Ironisk nok har Google Analytics-scriptet, som du muligvis har tilføjet til dine sidehoveder for at spore brugeradfærd, en cache-udløbsperiode på kun to timer. Sandsynligvis er det for at brugerne hurtigt kan se ændringerne, hvis platformen opdateres.
Dette script vil blive vist på listen over ressourcer, der kræver din opmærksomhed under Vis statiske aktiver med en effektiv cachepolitikanbefaling. Da det hører til en tredjepart, kan du ikke ændre udløbsperioden med headerne Cache-Control eller Expires.
Hvis dette er det eneste script, der er anført under denne anbefaling, kan du stadig bestå revisionen:
Som vi har nævnt i dette indlæg, har din PageSpeed-score dog mindre betydning end din faktiske og opfattede præstation. For at imødekomme denne ressource effektivt, kan du overveje at hoste Google Analytics lokalt.
Plugins som Complete Analytics Optimization Suite (CAOS) og Perfmatters giver dig mulighed for at gøre dette. Du kan læse mere om processen i vores komplette guide til pågældende PageSpeed-forslag.
21. Reducer indvirkning af tredjepartskoder
Vi har flere gange nævnt, hvordan scripts fra tredjeparter kan påvirke din præstation negativt og resultere i, at du dumper PageSpeed Insights revisioner. I det hele taget, er det bedst at begrænse tilliden til disse værktøjer for at forhindre, at de påvirker siden negativt.
I nogle tilfælde, kan det dog være den bedste løsning for din webside at inkorporere et script fra en tredjepart. Google Analytics er et glimrende eksempel på dette, og andre eksempler inkluderer:
- Deling af knapper og feeds til sociale medier
- YouTube-videointegrering
- iFrames til annoncer og andet content
- Biblioteker til JavaScript, skrifttyper og andre elementer
I tilfælde, hvor du finder brug af et script fra tredjepart nødvendigt, er det dog vigtigt at reducere dets indvirkning på din websides ydeevne, som PageSpeed-analyseresultaterne også vil gøre dig opmærksom på:
For at indlæse tredjepartskode mere effektivt, kan du overveje en af de teknikker, vi allerede har nævnt i dette indlæg:
- Udskyd indlæsningen af JavaScript
- Brug link-tags med forudgående forbindelsesattributter
- Selvhost scripts fra tredjeparter (som vi beskrev omkring Google Analytics ovenfor)
Disse metoder skal gerne minimere negativ indflydelse på din websides ydeevne.
22. Undgå overdreven netværksbelastning
Denne anbefaling er især relevant for dine besøgende, der anvender mobilenheder. Overdreven belastning kan kræve yderligere cellulære data og dermed koste dine brugere penge. Minimering af antallet af netværksanmodninger, der er nødvendige for at få vist din side, kan forhindre dette:
Google anbefaler, at du holder din samlede byte-størrelse nede på 1.600 KB eller mindre. De metoder, der oftest bruges til at imødegå denne anbefaling kan findes i dette indlæg. Disse metoder involverer:
- Udskydelse af CSS, JavaScript og billeder, der ikke er på skærmen
- Minificering af kode
- Komprimering af billedfiler
- Brug af WebP-formatet til billeder
- Implementering af cache
Følg de relevante trin for disse strategier, så bør du bestå denne revision uden yderligere tiltag.
23. Brugertiming og -måling
Denne anbefaling er kun relevant, hvis du bruger User Timing API. Dette værktøj opretter tidsstempler, der hjælper dig med at evaluere din JavaScript-ydeevne. Hvis du har konfigureret API på dit websted, vil du se du dine markeringer og mål under denne overskrift i PageSpeed Insights:
Som du kan se, er dette et andet forslag fra Google, der ikke resulterer i ”bestået eller” eller ‘dumpet’. PageSpeed Insights gør denne information let tilgængelig, så du kan bruge dem til at vurdere områder, der muligvis kræver optimering.
Hvis du er interesseret i at integrere User Timing API på din WordPress-side, kan du lære mere i Mozillas guide om dette emne.
24. Undgå en overdreven “document object model (DOM)”-størrelse
Helt enkelt har DOM at gøre med, hvordan browsere forvandler HTML til objekter. Dette involverer brugen af en træstruktur bestående af individuelle knuderpunkter som hver repræsenterer et objekt. Jo større din sides DOM er, jo længere tager siden at indlæse.
Hvis din side overskrider visse standarder for DOM-størrelse, vil du få en anbefaling om at reducere antallet af knudepunkter samt kompleksiteten af din CSS-styling:
En almindeligt kendt synder, hvis du altså har “dumpet” denne revision i PageSpeed Insights, er dit WordPress-tema. Tunge temaer tilføjer ofte store mængder af elementer til DOM, og kan også inkludere en kompliceret styling, der gør dit websted langsommere. Hvis dette er tilfældet, skal du muligvis skifte tema.
Opsummering
Google PageSpeed Insights bør være fast inventar i din webmaster tool box, men dog er det tidsspild at besætte over at opnå en score på 100 ud af 100, da det kan tage din fokus væk fra andre vigtige opgaver, der kan give mere markante fordele.
I dette indlæg har vi dækket de dele af Google PageSpeed-scoren, der er vigtige, samt de, som er knap så vigtige. Vi delte også nogle korte retningslinjer for, hvordan du kan inkorporere platformens anbefalinger på din WordPress-side for at forbedre sidens ydeevne.
Har du spørgsmål i forhold til Google PageSpeed Insights eller websideoptimering? Spørg løs i kommentarfeltet nedenfor!
Brian har en stor lidenskab for WordPress, har brugt det i over et årti og udvikler endda et par premium plugins. Brian kan lide blogging, film og vandreture. Opret forbindelse med Brian på Twitter.
Virkelig godt indlæg og dybdegående. Og jeg er meget enig i at der gås for meget op i at score højt på PSI.
Der hvor jeg måske lige vil slå et slag eller måske to slag, er det at gå efter en score på 100/100 kan være effektivt hvis man gerne vil lærer at optimere hastigheden, fordi man derfor sætter sig mere ind i tingene, tester meget mere og måske endda opnår 100/100 og ligger i den gode ende af hastigheden.
Det andet er, har man ikke så meget viden om pagespeed insights, så vil man tro at fordi noget er bestået, så er det godt nok. Men det er det ikke. Ofte er en ting bestået, men hvis man ser på de dele af testen som er bestået, så er der alligevel ting man kan forbedre. Det bruger jeg selv i mit arbejde til hverdag, ser på de dele som ikke er bestået også.
Men ja det er en god ide at tænke over hvor grænsen går for optimering af forskellige dele af siden bare for at opnå en score.
Tak for et godt indlæg om emnet.