Google PageSpeed ​​Insights er uden tvivl et nyttigt værktøj til webmastere, udviklere og webstedsejere af alle typer. Vi har dog bemærket, at mange mennesker bruger

på besættelse af at optimere deres websteder for at prøve at score 100/100 på denne test.

Sandheden er, at det ikke er sådan, at Google PageSpeed ​​Insights skal bruges, og det er heller ikke en forfølgelse værdig. Når du fokuserer på at implementere platformens anbefalinger i stedet for at nulstille ind nummeret øverst på siden, skaber du meget flere fordele for dit websted.

Dette indlæg er en omfattende guide til at bruge Google PageSpeed ​​Insights til din bedste fordel. Vi dækker, hvordan Google bruger din score, samt hvordan du integrerer de anbefalinger, du modtager.

Lad os komme igang!

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 webstedets ydeevne. Du kan indtaste en hvilken som helst URL og få den analyseret:

google pagespeed insights

Google PageSpeed Insights

Google leverer derefter en samlet score ud af 100 for det websted, du har testet, baseret på adskillige bedste praksis til optimering af effektivitet:

pagespeed insights score

Google PageSpeed Insights-score

Sammen med dette resultat ser du også flere anbefalinger fra Google om, hvordan du forbedrer din ydelse (og derfor også din PageSpeed Insights-score):

Google PageSpeed Insights-anbefalinger

Google PageSpeed Insights-anbefalinger

Fra 2018 beregnes PageSpeed Insights-scoringer via Lighthouse, Googles open source, automatiseret værktøj til forbedring af websidernes samlede kvalitet. Denne platform kan evaluere alle mulige faktorer, herunder ydelse, tilgængelighed, progressive webapps med mere.

For at se Lighthous’ omfattende vurdering af dit websted kan du bruge Googles måleværktøj:

google revisionsværktoj

Google Webmastere Mål revisionsværktøj

Ud over at udføre en præstations-revision, ligesom den, som Google PageSpeed Insights kører, får du scores 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 webstedsejere og -udviklere, der bliver besat af at opnå en perfekt PageSpeed Insights-score. Desværre har disse mennesker en tendens til at overse det vigtigste aspekt af testresultaterne: anbefalingerne.

Selvom du bestemt bør stræbe efter at forbedre dit websteds indlæsningstid så meget som muligt, er det faktisk ikke så vigtigt at få en 100/100 i Google PageSpeed Insights. Til at begynde med er det ikke engang be-all-end-all test for ydeevne.

I modsætning til PageSpeed Insights giver Pingdom Tools dig mulighed for at teste dit websteds ydelse fra forskellige placeringer:

pingdom tools

Resultater af Pingdom Tools speed test

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 matcher nøjagtigt, hvilket viser dig, hvor vilkårlige disse tal kan være.

Det, der virkelig betyder noget, er den faktiske hastighed på dit websted. For at sætte det i perspektiv har vi set websteder 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 skal have indflydelse på din tilgang til speed optimization, er den opfattede ydelse på dit websted. Dine besøgende er ligeglad med, hvad din Google PageSpeed ​​Insights-score er. De vil bare være i stand til at se dit indhold så hurtigt som muligt.

Det egentlige formål med at teste dit websteds ydelse med Google PageSpeed ​​Insights er ikke at opnå en høj score. I stedet er det for at finde problem spots på dit websted, så du kan optimere dem og reducere både dine faktiske og opfattede indlæsningstider.

Sådan bruger Google PageSpeed Insights

Ud over at påvirke dit websteds brugeroplevelse (UX) spiller ydeevne også en rolle i SEO. I betragtning af at PageSpeed ​​Insights køres af verdens største og mest populære søgemaskine, er det en grund til, at din score muligvis har en vis effekt på din placering af Search Engine Results Page (SERP) (i det mindste på Google selv).

Virkeligheden er, at Google bruger PageSpeed ​​Insights til at bestemme placeringer – slags. Websteds hastighed er en rangerende faktor, enkel og enkel. Din ydelsestest score 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 på dine PageSpeed-resultater. At ramme en 100/100 garanterer ikke dig en topplads på SERP’erne.

Læn dig tilbage, slap af og øg din sides hastighed – vi tager os af WordPress-cache, så du ikke behøver at gøre det. Prøv Kinsta gratis.

Når det er sagt, kan du stadig sætte dine PageSpeed ​​Insights-resultater til at fungere, når du forbedrer din SEO. For eksempel har mobilsidens hastighed siden 2018 været en rangeringsfaktor for Google. Du vil bemærke, at din ydelsestest indeholder data til både desktop- og mobilversioner af dit websted:

pagespeed insights mobil

Fanen Mobil i Google PageSpeed Insights

Da mere end 73 procent af mobile internetbrugere hævder, at de har stødt på et websted, der tager for lang tid at indlæse, er oplysningerne i fanen Google PageSpeed ​​Insights Mobile uvurderlige. Brug af anbefalingerne her til at reducere indlæsningstider på smartphones og andre enheder bør give dig en konkurrencefordel.

Anbefalinger fra Google PageSpeed Insights (24 måder at forbedre ydelsen)

Vi har talt meget om Google PageSpeed ​​Insights ‘anbefalinger i dette indlæg. De er det rigtige kød af dine resultater og langt mere værdifuld 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 Chrome brugeroplevelses-rapport i de sidste 30 dage.

Der er også to diagrammer, der viser, hvor din gennemsnitlige First Contentful Paint (FCP) og First Input Delay (FID) falder:

field data

Field data fra Google PageSpeed Insights

På billedet ovenfor er vores websteds FCP omtrent det samme som 45 procent af siderne i den 75. percentil, og vores FID er omtrent det samme som 9 procent af det 95. percentil.

Lab data viser specifikke data for en simuleret sidebelastning:

lab data

Google PageSpeed Insights Lab Data

Du vil bemærke, at vores Field Data og Lab Data ikke matcher nøjagtigt. Det er helt normalt. Lab Data oprettes under faste betingelser, mens Field Data bruger faktiske indlæsningshastigheder indsamlet over tid.

Når man ser på det i kombination, 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 vil være opmærksom på disse numre.

Når du har overvejet disse oplysninger, er det tid til at begynde at forbedre dit websteds ydelse med Google PageSpeeds anbefalinger.

1. Fjern ressourcer, der blokerer for render

En af de mere almindelige henstillinger fra Google PageSpeed Insights er at fjerne ressourcer, der blokerer for render:

Fjern render-blocking resources anbefaling

Fjern render-blocking resources anbefaling

Dette henviser til JavaScript- og CSS-scripts, der forhindrer din side i at indlæses hurtigt. Den besøgendes browser skal downloade og behandle disse filer, før den kan vise resten af ​​siden, så at have en masse af dem ‘over folden’ kan have negativ indflydelse på dit websteds hastighed.

Du kan lære mere om dette problem i vores guide til eliminering af render-blokerende scripts. Hvad Google angår, er der to løsninger, du skal overveje:

Du finder en liste over de ressourcer, der er mest påvirket af dette problem under anbefalingen i dine PageSpeed-resultater.

2. Undgå chaining critical requests

Konceptet med chaining critical requests har at gøre med CRP (Critical Rendering Path) og hvordan browsere indlæser dine sider. Visse elementer – som JavaScript og CSS, som vi diskuterede ovenfor – skal indlæses helt, før din side bliver synlig.

Som en del af dette forslag viser Google PageSpeed ​​Insights dig request chains på den side, du analyserer:

undgå kædning requests

Undgå kædning af critical requests recommendation

Dette diagram viser dig den række afhængige requests, 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 afhængige requests såvel som deres størrelser.

Flere metoder til at nå disse mål er dækket af andre henstillinger diskuteret i dette indlæg, herunder:

Derudover kan du optimere rækkefølgen, som aktiver indlæses, for at forkorte CRP. Dette betyder at flytte indhold over skillelinjen 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 er et magisk antal kritiske request chains, som du har brug for at arbejde 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 stilles simpelthen til rådighed for at hjælpe dig med at forbedre belastningstider.

3. Hold antallet af requests lav og størrelser på overførsler små

Jo flere requests browsere skal foretage for at indlæse dine sider, og jo større ressourcer din server returnerer som svar, desto længere tager dit websted at indlæse. Derfor giver det mening, at Google vil anbefale, at du minimerer antallet af krævede requests og mindsker størrelsen på dine ressourcer.

Ligesom anbefalingen om at undgå chaining critical requests, resulterer denne ikke i et ‘pass’ eller ‘mislykket’. I stedet vil du blot se en liste over antallet af anmodninger, der er foretaget, og deres størrelse:

request counts low

Hold requests counts lav og overførselstørrelser lille anbefaling

Der er ikke et ideelt antal forespørgsler eller maksimale størrelser at huske på. I stedet anbefaler Google, at du indstiller disse standarder for dig selv ved at oprette et performancebudget. Dette er et sæt af definerede mål, der kan være relateret til aspekter som:

Oprettelse af et præstationsbudget giver dig et sæt standarder, som du kan holde dig ansvarlig over for. Når du går over dit budget, kan du derefter 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 en i Googles egen guide.

4. Komprimer CSS

CSS-filer er ofte større, end de har brug for, for at gøre dem lettere for mennesker at læse. De kan muligvis indeholde forskellige vognreturer og mellemrum, som ikke er nødvendige for, at computere kan forstå deres indhold.

Minificering af din CSS er processen med at kondensere dine filer ved at fjerne unødvendige tegn, mellemrum og duplikationer. Google anbefaler denne praksis, fordi den reducerer dine CSS-filstørrelser og derfor kan forbedre indlæsningshastigheden:

minify css

Minify CSS-anbefaling

Vi anbefaler at bruge et plugin som Autoptimize eller WP Rocket til at minimere dine CSS-filer.

5. Komprimer JavaScript

Ligesom du kan reducere CSS-filstørrelse gennem minification, gælder det samme for dine JavaScript-filer:

minify javascript

Minify JavaScript-anbefaling

Vi anbefaler at bruge et plugin som Autoptimize eller WP Rocket til at minimere dine CSS-filer.

6. Fjern ubrugt CSS

Enhver kode i dit stylesheet er indhold, der skal indlæses før at din side kan blive synlig for brugerne. Hvis der er CSS på dit websted, som faktisk ikke er nyttigt, lægger det en unødvendig dræning af din præstation.

Derfor anbefaler Google at fjerne ubrugt CSS:

Fjern ubrugt CSS-anbefaling

Fjern ubrugt CSS-anbefaling

Løsningen her er i det væsentlige den samme som for eliminering af render-blokerende CSS. Du kan inline eller udsætte stilarter på den måde, der giver mest mening for dine sider. Du kan også bruge et værktøj som Chrome DevTools til at finde ubrugt CSS, der skal optimeres.

7. Minimer main-thread work

‘The main thread’ er det primære element i en brugers browser, der er ansvarlig for at omdanne kode til en webside, som besøgende kan interagere med. Det analyserer og udfører HTML, CSS og JavaScript. Derudover er det ansvaret for håndtering af brugerinteraktioner.

Dette betyder, at når main-thread fungerer gennem dit websteds kode, kan den ikke også håndtere brugeranmodninger. Hvis dit websteds main-thread arbejde tager for lang tid, kan dette resultere i dårlige UX og langsomme sideindlæsningstider.

Google PageSpeed markerer sider, der tager længere end fire sekunder at gennemføre main-thread arbejdet og præsentere en brugbar webside:

Minimer arbejds anbefaling fra main thread

Minimer arbejds anbefaling fra main thread

Nogle af de metoder, der bruges til at reducere main-thread arbejde, er allerede blevet dækket i andre sektioner af dette indlæg, herunder:

Du kan dog også overveje kodespaltning. Denne proces involverer opdeling af din JavaScript i bundter, der udføres, når de er nødvendige, i stedet for at kræve, at browsere indlæser dem alle, før siden bliver interaktiv.

Webpack bruges ofte til at implementere kodespaltning. Bemærk, at dette er en temmelig avanceret teknik, og begyndere skal normalt foretage det alene.

8. Reducer udførelsestid for JavaScript

JavaScript-udførelse er ofte den mest fremtrædende bidragyder til main-thread arbejde. PageSpeed Insights har en separat anbefaling til at advare dig, hvis denne opgave har en betydelig indflydelse på dit websteds ydelse:

Reducer anbefaling af JavaScript-udførelsestid

Reducer anbefaling af JavaScript-udførelsestid

Ovenstående metoder til reduktion af main-thread arbejde bør også løse denne advarsel i dine PageSpeed-resultater.

9. Reducer serverens responstid (TTFB)

Time to First Byte (TTFB) er et mål for, hvor lang tid det tager for en browser at modtage den første byte med data tilbage fra dit websteds server, når du har fremsat en anmodning. Selvom dette ikke er det samme som din samlede webstedshastighed, er det forståeligtvis godt for dit websteds ydelse at have en lav TTFB.

Derfor er reduktion af serverens responstid blandt Google PageSpeed Insights ‘anbefalinger. Hvis du er i stand til at opnå en lav TTFB, ser du denne meddelelse under Passed audits:

Serverens responstid er lav besked

Serverens responstid er lav besked

Der er flere faktorer, der kan påvirke din TTFB. Nogle strategier til sænkning inkluderer:

Vores indlæg på TTFB er en fremragende ressource til flere detaljer om optimering på dette område.

10. Billeder i korrekt størrelse

Mediefiler såsom billeder kan være et rigtigt væmmelig ved dit websteds ydelse. Korrekt størrelse af dem er en enkel måde at reducere dine belastningstider på:

Anbefaling af korrekt størrelse på billeder

Anbefaling af korrekt størrelse på billeder

Hvis din side indeholder billeder, der er større, end de skal være, bruges CSS til at ændre størrelsen på dem korrekt. Dette tager længere tid end blot at indlæse billederne i den rigtige størrelse oprindeligt, hvilket har indflydelse på din sides ydeevne.

For at løse dette kan du enten uploade billeder i de rigtige størrelser eller bruge ‘lydhøre billeder’. Dette involverer oprettelse af forskellige størrelser til forskellige enheder.

Du kan gøre dette ved hjælp af srcset-attributten, der føjes til <img> -koder for at specificere alternative billedfiler i forskellige størrelser. Browsere kan læse denne liste, bestemme, hvilken mulighed der er bedst til den aktuelle skærm og levere den version af dit billede.

For eksempel kan du sige, at du har et headerbillede, og at du vil gøre det responsive. Du kan uploade tre versioner af den i 800, 480 og 320 pixels i bredden. Derefter anvender du srcset-attributten som denne:

<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-attributten specificerer de forskellige tilgængelige filer, og size-attributten fortæller browsere, hvilken der skal bruges baseret på den aktuelle skærmstørrelse.

11. Udskyd billeder på skærmen

Processen med at udsætte 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 det vises indholdet over folden, vil det kun indlæse dem, der er umiddelbart synlige.

Mindre indlæsning, før siden bliver synlig, betyder bedre ydelse, hvorfor Google anbefaler denne metode:

Udskyd anbefaling fra skærmbilleder

Udskyd anbefaling fra skærmbilleder

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. Kod billeder effektivt

Som vi nævnte tidligere i dette indlæg, har billeder en betydelig indflydelse på dit websteds ydelse. En af de mest basale bedste optimeringsmetoder, du måske vil overveje, er komprimering, som kan hjælpe med at reducere dine filstørrelser, så de indlæses hurtigere. Det er også den primære metode til at følge Googles anbefaling om at effektivt kode billeder:

Kode billedanbefaling effektivt

Kode billedanbefaling effektivt

Nøglen er at opnå de 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 anbefalinger, der har indflydelse på, om du ‘består’ eller ‘mislykkes’ i effektiv kodning af billedrevision inkluderer:

Ud over at komprimere dine billeder kan du følge trinnene til at opfylde disse forslag som beskrevet andetsteds i dette indlæg.

13. Server billede i Next-Gen-formater

Der er nogle billedfilformater, der indlæses hurtigere end andre. Desværre er de ikke dine almindeligt sete PNG– eller JPEG-formater. WebPbilleder er ved at blive den nye standard, og Google PageSpeed ​​vil informere dig, hvis dine billeder ikke overholder det:

Server billeder i anbefaling af næste gen-formater

Server billeder i anbefaling af næste gen-formater

Dette kan virke som en hård anbefaling at møde, da du sandsynligvis allerede har masser af billeder på dit WordPress-sted. 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 i vejledningen, funktionsanmeldelser og endda humoristiske animationer kan alle hæve dine indlæg og gøre dem sjovere og værdifulde for læserne.

Desværre kommer disse fordele til en pris for din ydelse. GIF er krævende at indlæse, og derfor anbefaler PageSpeed Insights at servere videoindhold i stedet:

Brug videoformater til anbefalet animeret indhold

Brug videoformater til anbefalet animeret indhold

Desværre er konvertering af GIF til videoformater ikke det mest enkle af processer. Først skal du beslutte, hvilken type video du vil bruge:

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. For at komme i gang skal du installere FFmpeg. Dette er et open source-værktøj til konvertering af filformater:

ffmpeg

FFmpeg filformat konverteringsværktøj til video og lyd

Åbn derefter din command line interface og kør følgende kommando:

ffmpeg -i input.gif output.mp4

Dette konverterer GIF med filnavnet input.gif til en MP4-video med filnavnet output.mp4. Ændring af format er imidlertid bare begyndelsen. Du skal nu integrere den resulterende video på dit WordPress-sted på en måde, der får den til at se ud som en animeret GIF.

Integrering af videoindhold til animationer

Som du sandsynligvis har bemærket, hvis du nogensinde har set en GIF før, er de er lidt forskellige fra normale videoer. De spiller normalt autoplay og kører på en loop, og de er altid uden lyd. Integrering af din nye MP4- eller WebM-fil på dit WordPress-sted frembringer ikke disse funktioner.

Du kan dog genskabe dem med en meget enkel kode. Upload din video til dit mediebibliotek, og tilføj derefter følgende til den side eller indlæg, hvor du vil inkludere din GIF:

<video autoplay loop muted playsinline>
<source src="output.mp4" type="video/mp4">
</video>

Dette anvender de specificerede attributter på din video, så den vises mere ‘GIF-lignende’. Du skal blot tilpasse filnavnet og typen til at matche den for din ressource. For flere detaljer om dette emne foreslår vi, at du læser Googles guide til konvertering af GIF’er til videoer.

15. Sørg for, at tekst forbliver synligt under Webfont-indlæsning

Ligesom billeder, har fonts en tendens til at være store filer, der tager lang tid at indlæse. I nogle tilfælde skjuler browsere muligvis din tekst, indtil den font, du bruger, indlæses fuldstændigt, hvilket vil resultere i denne anbefaling fra Google PageSpeed ​​Insights:

tekst forbliver synlig under webfont-anbefaling

Sørg for, at tekst forbliver synlig under webfont-anbefaling

Google rådgiver dig om 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 webskrifter i vores indlæg “Sådan ændres skrifter i WordPress” og vores dybdegående guide til at hoste lokale fonts.

16. Enable Text Compression

Google PageSpeed Insights ‘ Enable text compression henviser til brugen af GZIP-komprimering:

Enable text compression anbefaling

Enable text compression anbefaling

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 par muligheder for at følge denne anbefaling.

Den første er at installere et plugin med en GZIP-komprimeringsfunktion. WP Rocket er en bæredygtig 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:


  # 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

Du skal tilføje det efter #END i din .htaccess-fil. Hvis du tilfældigvis har dit WordPress-sted 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 dit websteds tekstkomprimering, foreslår vi, at du bruger et værktøj som GiftOfSpeed:

giftofspeed check

GiftOfSpeed GZIP-komprimeringskontrol

Dette vil lade dig vide, om GZIP-komprimering er implementeret, samt hvilken type server dit websted kører på og et par andre nøgledetaljer.

17. Forbind forbindelsen til påkrævede oprindelser

Chancerne er store for, at du sandsynligvis har mindst en tredjepartsressource på dit websted – Google Analytics er et almindeligt eksempel. Det kan tage tid for browsere at etablere en forbindelse til disse ressourcer, hvilket bremser dine indlæserhastigheder.

Brug af forudgående preconnect-attributter kan fortælle browsere med det samme, at der er tredjeparts-scripts på din side, der skal indlæses. Processen med at anmode om dem kan derefter starte så hurtigt som muligt og forbedre din ydelse.

Hvis Google mener, at din side kunne drage fordel af denne teknik, vil du se Preconnect to required origins forslag:

Forbind forbindelsen til den ønskede oprindelsesanbefaling

Forbind forbindelsen til den ønskede oprindelsesanbefaling

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 browsere, at de er nødt til at oprette en forbindelse til example.com så hurtigt som muligt. Google PageSpeed ​​Insights viser alle relevante ressourcer, som du skal tilføje link-tags med preconnect attributter.

Den anden mulighed er at bruge et plugin for at opnå den samme effekt. Perfmatters inkluderer en forudgående forbindelse-funktion (ansvarsfraskrivelse: Jeg er en af ​​grundlæggerne af Perfmatters). WP Rocket og Pre* Party Resource Hints inkluderer lignende funktionalitet.

18. Forudindlæste nøgleanmodninger

I lighed med anbefalingen Preconnect til påkrævet oprindelse kan du ved at følge dette forslag minimere antallet af anmodninger, som browsere skal foretage til dit websteds server. I stedet for at oprette forbindelse til tredjepartsressourcer, henviser der dog til Preload af nøgleanmodninger om indlæsning af kritiske aktiver på din egen server:

Preload nøgleanmodninger anbefaling

Preload nøgleanmodninger anbefaling

Implementering af denne teknik ligner også meget den foregående anbefaling. Du kan tilføje linkmærker, der angiver ressourcerne, der er anført i PageSpeed ​​Insights til din header.php-fil:

<link rel=“preload” href=“example.com”>

Du kan også indarbejde dette tag ved hjælp af Perfmatters, WP Rocket eller Pre * Party Resource Tips.

19. Undgå flere side redirects

Redirects bruges, når du vil have en URL til at pege til en anden. De er ofte ansat, når du flytter eller sletter en side på dit websted. Selvom der ikke er noget galt i at bruge redirects generelt, forårsager de yderligere forsinkelser i indlæsningstid.

Hvis du har for mange omdirigeringer på dit websted, kan du muligvis se denne anbefaling i Google PageSpeed ​​Insights:

Undgå anbefaling om flere redirects på flere sider

Undgå anbefaling om flere redirects på flere sider

Det eneste, du kan gøre som svar på denne anbefaling, er at sikre dig, at du kun bruger redirects, når du absolut skal. Du kan lære mere om processen med at oprette dem i vores indlæg, “WordPress Redirect – Best Practices for Better Performance”.

20. Server statiske aktiver med en effektiv cache-politik

Hvis du har brugt Google PageSpeed Insights i et stykke tid, kender du muligvis denne anbefaling bedre som cache-advarslen om udnyttelse af browseren. I version 5 er det nu mærket som Serve statiske aktiver med en effektiv cache-politik

Statiske serveraktiver med en effektiv anbefaling af cache-politik

Statiske serveraktiver med en effektiv anbefaling af cache-politik

Dette forslag har et par lag, vi har brug for at gennemgå. Den første er, hvad “caching” betyder. Kort sagt, det er en proces, hvor browsere gemmer kopier af dine sider, så de kan indlæses hurtigere ved fremtidige besøg.

Den mest almindelige måde, WordPress-websteder implementerer cache på, er med plugins. WP Rocket og W3 Total Cache er populære muligheder. Nogle hostingudbydere – inklusive os her på Kinsta – muliggør dog cache via deres servere. Sørg for at kontrollere og se, om dette er tilfældet for din vært, før du installerer et cache-plugin.

Læn dig tilbage, slap af og øg din sides hastighed – vi tager os af WordPress-cache, så du ikke behøver at gøre det. Prøv Kinsta gratis.

Når du har aktiveret cache til dit websted, kan du bekymre dig om den anden del af denne anbefaling, som er din cache-politik ‘effektivitet’. Browsere renser regelmæssigt deres cacher for at opdatere dem med opdaterede kopier.

Ideelt set ønsker du, at denne periode skal være højere end lavere. Hvis du rydder dit websted fra browsercachen hver par timer, besejrer det formålet med at bruge denne teknik i første omgang. Du kan optimere din cache-udløbsperiode vha. Cache-control og udløbet headere.

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";
}

Du skal tilføje dette til din servers konfigurationsfil. I ovenstående eksempel er de specificerede filtyper indstillet til at udløbe efter 30 dage.

Dem med Apache-servere bør i stedet bruge dette uddrag i deres .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 headers.

Du kan tilføje disse 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 skal 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 ##

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"

## 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 sides headere for at spore brugeradfærd, en cache expiration period på kun to timer. Dette er sandsynligt, at hvis opdateringer foretages til platformen, vil brugerne hurtigt have adgang til ændringerne.

Dette script vises på listen over ressourcer, der kræver din opmærksomhed under Serve statiske aktiver med en effektiv cache-politikanbefaling. Da det hører til en tredjepart, kan du ikke ændre udløbsperioden med Cache-Control eller Expires headers.

Hvis dette er det eneste script, der er anført under denne anbefaling, kan du stadig bestå revisionen:

Bestået effektiv cache-policy audit

Bestået effektiv cache-policy audit

Som vi har bemærket i dette indlæg, betyder din PageSpeed-score dog mindre betydning end din faktiske og opfattede præstation. For at tjene denne ressource effektivt kan du overveje at hosteGoogle 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 dette PageSpeed-forslag.

21. Reducer virkningen af third party code

Vi har nu nævnt et par forskellige måder, hvorpå scripts fra tredjepart kan påvirke din præstation negativt og resultere i mislykkede revisioner fra PageSpeed ​​Insights. Det er ideelt at begrænse din tillid til disse værktøjer for at forhindre uheldige virkninger.

I nogle tilfælde er den bedste løsning på et behov, dit websted har, imidlertid at inkorporere et tredjeparts script. Google Analytics er et glimrende eksempel. Andre inkluderer:

I tilfælde, hvor du finder brug af et script fra tredjepart nødvendigt, er det vigtigt at reducere dets indvirkning på dit websteds ydeevne stadig, da dine PageSpeed-analyseresultater vil fortælle dig:

Reducer virkningen af anbefaling fra tredjepart

Reducer virkningen af anbefaling fra tredjepart

For at indlæse tredjepartskode mere effektivt kan du overveje en af de teknikker, vi allerede har nævnt i dette indlæg:

Disse metoder skal minimere indflydelsen på dit websteds ydelse.

22. Undgå enorme netværks-belastninger

Denne anbefaling er især relevant for dine mobile besøgende. Store nyttelast kan kræve brug af flere cellulære data og dermed koste dine brugere penge. Minimering af antallet af netværksanmodninger, der er nødvendige for at nå dine sider, kan forhindre dette:

Undgå en enorm anbefaling af netværks nyttelast

Undgå en enorm anbefaling af netværks nyttelast

Google anbefaler, at du holder din samlede byte-størrelse på 1.600 KB eller mindre. De metoder, der oftest bruges til at nå dette mål, findes i hele dette indlæg, herunder:

Følg de relevante trin for disse strategier, og du bør bestå denne revision uden yderligere indsats.

23. User timing marks og mål

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-ydelse. Hvis du har konfigureret API til dit websted, ser du dine markeringer og mål under denne overskrift i PageSpeed Insights:

user timing

User Timing marks og measures recommendation

Som du kan se, er dette et andet forslag fra Google, der ikke resulterer i et ‘pass’ eller ‘fail’. 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 API til user timing på dit WordPress-sted, kan du lære mere i Mozilla-guiden om emnet.

24. Undgå en overdreven document object model (DOM) størrelse

På enkleste vilkår er DOM, hvordan browsere forvandler HTML til objekter. Det involverer brugen af en træstruktur bestående af individuelle knuder, som hver repræsenterer et objekt. Jo større DOM’s side er, jo længere tager det at indlæse.

Hvis din side overskrider visse standarder for DOM-størrelse, vil den anbefale at reducere antallet af knuder samt kompleksiteten af din CSS-styling:

Undgå en overdreven anbefaling af DOM-størrelse

Undgå en overdreven anbefaling af DOM-størrelse

En almindelig synder, hvis du har “fejlet” denne revision i PageSpeed ​​Insights, er dit WordPress-tema. Tunge temaer tilføjer ofte store mængder af elementer til DOM, og kan også omfatte indviklet styling, der bremser dit websted ned. Hvis dette er tilfældet, skal du muligvis skifte temaer.

Kæmper du med at score 100/100 på #Google PageSpeed? Her er et tip: Bliv ikke besat over din score og fokuser på, hvad der virkelig påvirker din sidebelastning! 🚀📊Click to Tweet

Resumé

Google PageSpeed ​​Insights skal være en hæfteklamme i din webmaster tool box Imidlertid er det sandsynligvis ikke den bedste brug af din tid at fastsætte din score og besætte over at nå den eftertragtede 100/100. Det kan tage dig væk fra andre vigtige opgaver, der kan give mere markante fordele.

I dette indlæg dækkede vi måderne, hvorpå din Google PageSpeed-score gør- og ikke gør noget. Vi delte også nogle korte retningslinjer for at placere platformens anbefalinger til at arbejde på dit WordPress-sted for at forbedre dens ydeevne.

Har du spørgsmål om Google PageSpeed ​​Insights eller optimering af dit websteds ydelse? Spørg væk i kommentarfeltet nedenfor!


Hvis du godt kunne lide denne artikel, så vil du elske Kinstas WordPress hostingplatform. Boost dit website og få 24/7 support fra vores WordPress-ekspertteam. Vores Google Cloud-drevne infrastruktur fokuserer på automatisk skalering, ydeevne og sikkerhed. Lad os vise dig Kinsta-forskellen! Tjek vores planer