Følgende artikel hjælper dig med: Optimering af dit nichewebsted til kernewebvitaliteter: Værktøjer, proces og spørgsmål
At optimere dit nichewebsted til Core Web Vitals (CWV) er en taktik, der hjælper med at forbedre en af dine brugeres overordnede sideoplevelse. Google har allerede bekræftet, at sideoplevelse er et signal, de bruger til at bestemme søgemaskineplacering.
Tilbage i maj 2020 annoncerede Google, at CWV med tiden vil blive et af de elementer, de vurderer som en del af deres overordnede sideoplevelsessignaler.
De andre elementer i sideoplevelsen er mobilvenlig, sikker browsing, sikre sider (HTTPS) og påtrængende mellemliggende annoncer (tænk irriterende popups, der dækker skærmen og er svære at lukke).
I denne artikel vil følgende blive dækket:
- Hvad er CWV?
- Hvorfor bekymre sig?
- Værktøjer til test af CWV
- Optimeringstip med og uden displayannoncer
- Almindelige spørgsmål
Jeg har inviteret Keith Mint til at samarbejde om denne artikel. Han driver en portefølje af websteder og blogger også hos Minted Empire. Han har brugt en del tid på at studere og forbedre sine hjemmesider til CWV. Jeg vil også give enhver indsigt i artiklen.
Lad os komme ind i det!
Hvad er kernewebvitaliteterne?
Google har opdelt Core Web Vitals i tre hovedelementer:
- Indlæser – Største indholdsfulde maling (LCP)
- Interaktivitet – Første indgangsforsinkelse (FID)
- Visuel stabilitet – Kumulativt layoutskift (CLS)
Der er allerede en masse definitioner og forklaringer om Core Web Vitals-elementerne på nettet. Jeg vil meget hurtigt opsummere dem i ikke-teknisk sprog:
- LCP – når en side indlæses, er det den tid, det tager for læsbart indhold at blive vist.
- FID – når en side indlæses, hvor hurtigt kan brugeren interagere? Klik f.eks. på en menu.
- CLS – et mål for, hvordan elementerne bliver skubbet (normalt ned) på skærmen, efter at et andet element er indlæst.
Her er en informativ ressource til yderligere læsning om disse faktorer.
Hvorfor gider du optimere til CWV?
Jeg ser to vigtige grunde til, hvorfor niche-webstedsejere bør optimere deres Core Web Vitals.
For det første, som bekræftet af Google, vil det være et rangeringssignal for verdens mest populære søgemaskine.
For det andet kan det forbedre konverteringsraten for den pågældende side ved at være opmærksom på og optimere til brugerens sideoplevelse.
Hvordan komplicerer annoncenetværk optimeringsudfordringen?
Det kan være udfordrende at optimere til vitale kernewebområder. Dette er især tilfældet, hvis dit websted er integreret i et displayannoncenetværk, der anvender sine egne hastighedsoptimeringer.
Når det kommer til hastighedsoptimering, er den største fejl, jeg har set webstedsejere begå, at bruge plugins, der udfører lignende funktioner som den optimeringsteknologi, der bruges af annoncenetværket.
Dette resulterer ofte i konflikter, og det kan vise sig i meget lave webstedshastighedsscore.
Afhængigt af konfigurationen af dit websted og de forskellige lag af teknologi, der er implementeret, kan optimering blive en teknisk hovedpine.
Jeg har for nylig brugt noget tid på at optimere mine egne websteder for kernewebvitals. Jeg var i stand til at få meget høje resultater for mit websted, der ikke har displayannoncer.
Hvad angår mit websted, der kører displayannoncer, havde jeg mere arbejde at gøre, som du vil læse nedenfor.
Værktøjer til test af webstedssidehastighed
Der er masser af tilgængelige værktøjer til at teste ydeevnemålingerne på en webside. De omfatter:
Mens Gtmetrix’s vandfaldsrapport er god til at fejlfinde visse sideproblemer, brugte jeg i stedet for det meste Googles PageSpeed Insights til at køre mine hastighedstests. Det gav mening at optimere til Googles værktøj, fordi det er deres algoritme, som vi i sidste ende forsøger at imponere.
Min tilgang til at optimere mine niche-websteder til kernewebvitale
Jeg har optimeret til hjemmesidehastighed i over et årti nu. Jeg er klar over, at optimeringsprocessen kan være utrolig nuanceret.
Så jeg besluttede at tage en meget enkel tilgang.
Hvert websted er forskelligt, så der er lidt at vinde ved, at jeg deler den nøjagtige indstilling, jeg brugte for hvert plugin eller konfigurationsindstilling. Hvis du blindt følger denne tilgang, er det højst sandsynligt, at noget af funktionaliteten på din hjemmeside brydes. Fejlfinding kan vise sig at være vanskelig.
I stedet vil jeg beskrive den tilgang, jeg tog for at opnå høje scores. Der er meget trial and error involveret.
Jeg startede med at optimere en ikke-niche hjemmeside, jeg ejer. Det er en leadgenerationsvirksomhed med lav månedlig trafik. Det kører på WordPress. Den har ikke displayannoncer. Det er meget minimalt, men ser stadig attraktivt ud for potentielle kundeemner.
Før optimering scorede den typisk mellem 40 og 50 på mobilen og fejlede alle Core Web Vitals.
Efter lidt tilpasning opnåede jeg dette:
Det er fantastisk, men jeg blev ikke så begejstret for det, fordi jeg vidste, at det ville være næsten umuligt at opnå det samme resultat på et websted, der bruger et tredjeparts displayannoncenetværk.
Resultatet viste mig dog, at jeg startede på højre fod i forhold til mit valg af tech stack.
Før jeg kommer nærmere ind på, hvad jeg gjorde for at opnå denne score, er det vigtigt at bemærke, at hver gang jeg kører Googles PageSpeed Insights, fik jeg forskellige resultater.
Jeg kørte PageSpeed Insights ti forskellige gange, altid ved at bruge det samme tilfældigt udvalgte blogindlæg.
Samlet set, ved hjælp af en simpel gennemsnitsberegning, passerer webstedet CWV. Test 2, 3 og 7 mislykkedes imidlertid CWV, fordi den største indholdsfyldte maling (LCP) viste sig mere end 2,5 sekunder.
Det interessante er, at den side, der testes, ikke ændrer sig dynamisk på nogen måde. Der oprettes ingen tredjepartsforbindelser fra siden. Der indlæses f.eks. ingen eksternt hostede skrifttyper.
At dykke ned i de præcise hvorfor og hvordan, hvorfor disse resultater kan være forskellige, ligger uden for denne artikels omfang. Det er ganske vist også over min fatteevne. Helt ærligt, når en side scorer så højt, er det sandsynligvis lige meget, hvorfor scorerne varierer sådan.
Men efterhånden som kompleksiteten af teknologistakken vokser, kan varierende testresultater gøre optimeringer endnu mere nuancerede.
Jeg har kørt hundredvis, hvis ikke tusindvis, af tests. Mobil scorer altid lavere end Desktop. Nu ser jeg ikke engang på Desktop-resultatet, når jeg tester. For mig er det lige meget. Jeg håber, at Google har det på samme måde, da de skiftede til et mobil-først-indeks for noget tid siden.
Lad os dykke ned i de trin, jeg tog for at opnå denne gennemsnitlige PageSpeed Insights-score på 97,4 på mobil.
1. Brug Fast Hosting
Siden blev oprindeligt hostet med SiteGround. Jeg migrerede den til min CloudWays-konto, hvor jeg har en Vultr High-Frequency-server kørende. Det er minimum spec, den laveste mulighed, du i øjeblikket kan vælge, når du tilmelder dig.
Jeg beholdt de originale webstedsfiler og database på SiteGround som backup. Jeg kan ikke understrege nok vigtigheden af at tage backups på forskellige stadier af en optimeringsproces.
Mushfiqs noter: Jeg bruger også Cloudways på en Digital Ocean-server. Cloudways er generelt forbløffende, så uanset hvilken backend-server du bruger, uanset om Digital Ocean, AWS, Vultr, osv., vil ikke gøre en forskel.
2. Brug et Lean-tema
Jeg ændrede WordPress-temaet til GeneratePress Premium (GP).
GP er flot modulopbygget. Jeg aktiverede kun de særlige moduler, jeg havde brug for for at genopbygge udseendet, så det ligner det originale design meget.
Mushfiqs noter: Jeg er også en stærk fortaler for GeneratePress Premium i samarbejde med GenerateBlocks. Hvert websted, jeg køber, bliver redesignet ved hjælp af GeneratePress.
3. Plugins – Fjernelse af oppustethed
Jeg tænkte over hvert plugin, før jeg aktiverede det på webstedet. Det skulle være essentielt for at hjemmesiden kunne fungere korrekt eller en væsentlig del af min salgstragt.
Jeg slap af med Google-skrifttyper og beholdt GeneratePress’ standardsystemskrifttyper. Jeg kan lide og sætter pris på design. Jeg havde ikke forventet at kunne lide udseendet af systemskrifttyper, men de er overraskende klare, og de ser godt ud for mine kræsne øjne.
Hvis et plugin var “fnug”, fjernede jeg det.
Jeg aktiverede Rank Math SEO og aktiverede kun de moduler, jeg ønskede. Jeg deaktiverede Rank Maths Google Analytics-modul, fordi selvom jeg ejer premium-versionen, kunne jeg ikke få deres ‘load ga.js locally’-funktionalitet til at fungere korrekt. Det blev ved med at anmode om analytics Javascript-filen eksternt, uanset hvad jeg prøvede. Mere om dette senere.
Mushfiqs noter: Hvis du erhverver et websted eller har bygget et websted over mange år, bliver plugins tilføjet og aldrig fjernet. Lav en plugin-revision! Fjern eventuelle plugins, der ikke har nogen værdi, og konsolider, hvor det er muligt. For eksempel tilføjer mange webstedsejere et plugin til social deling. For det første vil de fleste nichesider ikke blive delt på sociale medier, så det er umagen værd at fjerne det, indtil webstedet er et ægte brand.
4. Plugins – The Needle Movers
Alle webstedshastighedseksperter vil prædike om vigtigheden af at optimere billeder. Jeg er fuldstændig enig med dem.
Der er mange plugins tilgængelige for at optimere billeder. Jeg har prøvet et par af dem og slået mig ned på ShortPixel.
Jeg bruger ShortPixel med tabsgivende indstillinger til også at tjene WebP-billeder. Hvis du bruger CloudFlare, skal du være opmærksom på, hvilken metode du bruger til at servere WebP-billeder. .htaccess-omdirigeringsmetoden virker ikke med CloudFlare.
PerfMatters plugin
Perfmatters er et glimrende plugin til at kontrollere, hvilke scripts og CSS-filer, der bliver indlæst til hver kategori, posttype eller individuel side/indlæg på dit websted.
Til mit websted var jeg i stand til at bruge størstedelen af optimeringerne. PerfMatters-plugin’et tillod mig også at indlæse Google Analytics’ script lokalt, hvorimod RankMath Pro’s lokale GA-funktionalitet ikke fungerede korrekt for mig. Måske er dette blevet løst i en senere opdatering.
PerfMatters’ Script Manager er et fantastisk værktøj. For at få mest muligt ud af det, skal du først forstå, hvilke scripts og CSS-filer der faktisk er nødvendige for at få dit websted til at fungere, som det skal.
Det er vigtigt at se på, hvordan alle de individuelle JS- og CSS-scripts indlæses, FØR du går i gang med at kombinere og minimere dem. Dette gør det nemmere at håndplukke de enkelte scripts, som du skal deaktivere/aktivere på bestemte sider/indlæg/sektioner/tilpassede indlæg osv. fra Script Manager.
Så bare som et eksempel har jeg nu mit formularscript kun indlæst på min kontaktside. Som lokal virksomhed er kontaktsiden essentiel for min virksomhed i forhold til at samle leads.
Som et andet eksempel har jeg en brugerdefineret posttype sektion, der indlæste scripts og CSS-filer SITEWIDE. Takket være Perfmatters bliver dette nu kun indlæst på den del af webstedet, der faktisk har brug for dem.
Efter lidt finpudsning med at aktivere og deaktivere de enkelte CSS- og JS-filer, var fokus her at sikre, at siden så ud og fungerede korrekt.
Hastighed er endnu ikke et problem.
Da jeg var glad for, at jeg havde de rigtige indstillinger, var næste trin at aktivere og konfigurere Breeze, som er CloudWays’ cachingprogram. Den har lignende funktionalitet som WP Rocket, WP Super Cache, W3 Total Cache, SG Optimizer osv.
Mushfiqs noter: Jeg har ikke personligt brugt Perfmatters (men har gode ting). Jeg bruger det gratis Asset Cleanup Plugin. Dette plugin giver dig mulighed for at fjerne scripts fra bestemte sider.
Breeze Caching Plugin
Jeg brugte Breeze, fordi det er udviklet og designet til at køre på CloudWays-servere. SiteGround bruger SG Optimizer. De er begge anstændige plugins. WP Rocket er også god.
Men for min nuværende stack var Breeze mit foretrukne plugin.
Jeg har slået alle Breeze’s optimeringsindstillinger til. Gzip-komprimering, fuld minifikation med JS- og CSS-filer begge grupperet sammen.
Dernæst testede jeg webstedet inkognito med al caching ryddet. Alt så godt ud og virkede som forventet. Min kontaktformular genererer kundeemner. Det er det vigtigste!
Varnish er et andet servercacheniveau, og dette er aktiveret og konfigureret via Breeze.
Dit kilometertal kan variere i forhold til, hvilke filer du kan formindske eller inkludere i grupperingen. Visse funktioner på hjemmesiden kan gå i stykker. Det er vigtigt at teste og se, hvad du kan slippe af sted med.
Jeg var heldig, at alt fungerede første gang for mig. Det er en fordel ved at gå efter et enkelt design med minimal funktionalitet.
Mushfiqs note: Jeg er en stærk fortaler for at bruge WP Rocket. Det er et betalt premium plugin, og det bliver installeret på alle mine websteder. I slutningen af dagen vil ethvert plugin, der laver webstedscache, gøre jobbet.
5. Integrer en CDN – CloudFlare
Endelig tilføjede jeg CloudFlare (deres gratis version).
Jeg aktiverede CloudFlares APO, som bruger deres kantnetværk til at cache et WP-sted. Jeg er ikke sikker på, at dette faktisk flyttede nålen til min særlige opsætning. Måske ville det have gjort mere, hvis jeg prøvede at indlæse flere fjernhostede Google-skrifttyper.
Mushfiqs note: Cloudflare er et must. Jeg integrerer det på alle mine websteder. Jeg bruger kun den gratis version; du behøver ikke den betalte version til indholdswebsteder.
Sådan optimerer du nichewebsteder til displayannoncer
Det er her det sjove starter!
Min næste opgave var at se, hvordan jeg kunne implementere mine hastighedsforbedringer på et af mine nichewebsteder, der viser tredjepartsannoncer.
Jeg bruger Ezoic. Det er en simpel kendsgerning, at displayannoncer fra enhver udbyder vil gøre et websted langsommere. Periode. Det eneste, vi kan håbe på, er at optimere siden så godt, som vi overhovedet kan. En perfekt score er usandsynlig i dette scenarie.
Først fulgte jeg mine teknikker ovenfor, næsten til en tee. Samme hosting-opsætning, samme WordPress-tema og en meget lignende plugin-stak.
Dernæst, med Ezoic midlertidigt deaktiveret, kørte jeg en hastighedstest ti forskellige gange. Jeg lod et minut gå mellem hver løbetur.
Her er hastighedstestresultaterne:
Jeg er ikke sikker på, hvad der skete med testresultat 6 ovenfor. En CLS på 0,1 eller mindre anses for god. Så mit gennemsnitlige CLS på 0,1 passerer bare.
Af ren nysgerrighed genopfriskede jeg senere test 6’s resultat, og det viste en CLS på 0. Måske var det en fejl i matrixen. Jeg har dog ladet testresultaterne være uændrede.
Nederste linje er, at min nicheside samlet set, uden annoncer, der kører via min integration med Ezoic, består Core Web Vitals baseret på laboratorietests.
Aktivering af Ezoic og vurdering af indvirkningen af displayannoncer på CWV
Dernæst genaktiverede jeg Ezoic på mit websted og tændte deres nye Leap-optimeringsværktøj. Leap erstatter Ezoics Site Speed Accelerator-værktøjssæt.
Leap er i øjeblikket i beta, og efter mange timers tweaking er disse de bedste resultater, jeg var i stand til at opnå:
Den gennemsnitlige score for Largest Contentful Paint (LCP) er 2,6. Det skal være 2,5 sekunder eller hurtigere for at blive betragtet som et bestået.
Det er skuffende at være så tæt på, men måske når Ezoic’s Leap kommer ud af beta, vil det have yderligere optimeringer, der vil gøre det muligt for mit websted fuldt ud at bestå Core Web Vitals.
Fra min test relaterer de muligheder, der er anført på analysesiden af Googles testværktøj til PageSpeed Insights, sig altid til scripts, der indlæses af Ezoic for at vise annoncerne.
Det er ikke perfekt, men jeg anser det for godt nok til et websted, der indlæser personlige displayannoncer.
Almindelige spørgsmål om CWV
Hvornår går Core Web Vitals Update live?
Hvordan indsamles Core Web Vitals-scores?
Core Web Vitals-score er baseret på Chrome-browserens brugeroplevelsesscore over en 28-dages indsamlingsperiode. Deres resultater kan være meget forskellige fra, hvad laboratorietest viser under individuelle kørsler af Googles testværktøj til PageSpeed Insights.
Google har forklaret, at en beståelse i Core Web Vitals kan opnås, hvis en side opfylder de anbefalede mål ved den 75. percentil af alle sideindlæsninger på tværs af mobile og stationære enheder.
Har en dårlig Core Web Vitals en effekt på afvisningsprocenten?
Google har rapporteret, at dårlige Core Web Vitals, der fører til forsinkede sideindlæsningstider, kan have en betydelig negativ indvirkning på afvisningsprocenterne. En undersøgelse har vist, at selv et fald på 2 sekunder fra 1 til 3 sekunder kan øge afvisningsprocenten med 32 %.
Denne artikel går i detaljer og forklarer virkningen af den langsomme indlæsning af sider i den virkelige verden.
Afslutter
Vi har længe vidst, at en hurtigere hjemmeside øger antallet af konverteringer og forbedrer den overordnede brugeroplevelse.
Det er værd at investere lidt tid i at optimere dit nichewebsted til Googles kommende opdatering af sideoplevelse, der forventes i midten af juni. Core Web Vitals vil være en væsentlig komponent i Page Experience, selvom ingen med sikkerhed ved, hvilken indflydelse opdateringen vil have på SERP’erne.
Da det kan være utroligt nuanceret, vil de nemme gevinster være at fokusere på det grundlæggende optimering. Disse grundlæggende funktioner omfatter:
- Hurtig hosting med en anstændig Time To First Byte (brug Cloudways)
- Billed- og skrifttypeoptimering inklusive næste generations billeder og doven indlæsning (brug Shortpixel )
- Minifikation og gruppering af CSS- og JS-filer (Brug WP Rocket, Breeze eller andre caching-plugins)
- Indlæsning af eksterne scriptfiler lokalt, hvor det er muligt
- Forudhenter DNS
- Passende udløber overskrifter
80/20-reglen gælder helt sikkert her. Du vil sandsynligvis opnå 80 % af optimeringsfordelene i de første 20 % af den tid, du bruger. Google har erkendt, at dette er et område i udvikling, og fremtidige tilføjelser til Core Web Vitals kan forventes.
Mushfiqs noter: Google vil også gerne minde udgivere om, at en god sideoplevelse ikke tilsidesætter vigtigheden af at have godt indhold. Udfør de nemme gevinster og udgiv fantastisk indhold!
