Hvordan optimalisere nettstedet ditt for Core Web Vitals (Adsense)

Kappløpet om å forbedre Core Web Vitals er ikke lett. Det blir vanskeligere hvis du stoler på et annonseringsprogram som Google AdSense for å tjene penger på nettstedet ditt.

Nettsteder som kjører Google AdSense har 10 ganger større sannsynlighet for å mislykkes i Core Web Vitals-testen enn det samme nettstedet uten Google AdSense. Dette skyldes for det meste antallet tredjepartsforespørsler og ressurser som Google AdSense legger til nettstedet ditt. De fleste av disse ressursene er uoptimaliserte, store og ikke-brukervennlige.

Utenfor AdSense og annonseringsplattformer, hvis du har mange uoptimaliserte bilder, JavaScript og CSS, spesielt på den synlige delen av nettsiden, er det også stor sannsynlighet for at du mislykkes i Core Web Vitals-testen.

Hvis du har slitt med å bestå Core Web Vitals-testen og forbedre søkemotorrangeringen, finner du praktiske løsninger i denne artikkelen.

Hva er Core Web Vitals?

Core Web Vitals er beregninger drevet av Google Lighthouse som bestemmer hvordan et nettsted gir en god sideopplevelse. Selv om det er mange beregninger når du kjører en test, er de viktigste beregningene Largest Contentful Paint (LCP), First Input Delay (FID) og Cumulative Layout Shift (CLS).

Google har annonsert at disse beregningene fra mai 2021 vil bli en del av rangeringssignalene deres som brukes til å bestemme nettsiders plassering i søkeresultatene.

Oppsummert kan du si at Core Web Vitals ikke var ment å være en terror for webansvarlige, men et middel for å forbedre sideopplevelsen til nettsteder.

Største innholdsrike maling (LCP) : LCP måler tiden det tar for det største synlige bildet eller tekstblokken på en nettside å laste. Hvis den største synlige teksten eller bildet lastes inn raskt, oppfattes det som at resten av bildene og teksten lastes inn raskt. Den nødvendige lastetiden er 2.5 sekunder.

Førstegangsforsinkelse (FID) : FID måler nettsidens interaktivitet. Dette bestemmes av hvor lang tid det tar før nettleseren begynner å behandle hendelseshåndterere etter at en bruker har klikket på nettstedet ditt. Dette kalles ofte førsteinntrykket av nettstedet ditt. Den nødvendige tiden det skal gå er 100 millisekunder.

Kumulativ layoutforskyvning (CLS) : CLS måler layoutforskyvning som skjer på en nettside. Når en nettside lastes inn, og plutselig noe dukker opp eller forsvinner, og siden må tilpasse seg til å være større eller mindre, er det denne forskyvningen som måles. Det er forferdelig for brukeropplevelsen, og jeg er enig. Poengsummen du burde trenge for å bestå er 0.1.

Hvordan optimalisere nettstedet ditt for Core Web Vitals

Følg disse trinnene for å optimalisere nettstedet ditt:

1. Start med en rask webvert

Hvis du har en webvert med en forferdelig responstid, kan det hende at alle andre ting som jeg vil liste opp her, ikke gir ønskede resultater. Jo raskere serveren din svarer på forespørsler, jo bedre.

Hvorfor er en nettvert med rask tid til første byte (TTFB) viktig? Noen vil hevde at TTFB ikke spiller noen rolle, men det gjør det. Det er grunnlaget for alt annet. Hvis du har brukere i byer med tregt internett, vil hvor raskt webverten din kan svare, bety alt. Enhver nettvert kan prestere godt hvis du har brukere primært fra byer med superraskt internett.

Prøv å teste hvordan webverten din vil svare på 3G eller 2G i stedet for 4G. For hvis du får mange brukere til å koble seg til via 3G eller 2G, vil det legge opp til Core Web Vitals-poengsummen din. Så hvert millisekund teller. Forskjellen mellom å få 100 ms i FID og å få 101 ms er at med 100 ms består du, men med 101 ms mislykkes du. Så hvis noen forteller deg at 1 ms ikke betyr noe, kan den personen bare ta feil.

Når du velger en webhotell , sørg alltid for å ha et datasenter nærmere de fleste av nettstedets brukere. Du kan finne plasseringen deres ved å se på analysene dine. Hvor kommer de fleste av brukerne dine fra? Velg et datasenter nærmere dem. Jo nærmere, jo bedre.

Jeg har personlig lagt merke til en betydelig endring i et nettsteds feltdata for Core Web Vitals etter å ha byttet webvert. Jeg gjorde ingenting annet.

Hvis du er ute etter en rask webhotell, finnes det mange anbefalinger der ute som utelukkende er drevet av affiliates uten oppriktighet. Hvis du bruker WordPress og har råd til det, anbefaler jeg Kinsta på det sterkeste . De er best for WordPress. Hvis du trenger noe billigere eller ikke bruker WordPress, er Cloudways også veldig effektivt.

2. Bruk et lettvekts- og hastighetsoptimalisert tema

Dette tipset er spesielt nyttig for ikke-kodere og til og med for kodere med kortere tid. Spesielt hvis du bruker WordPress der det er så mange alternativer, sørg for at du bruker et lett og hastighetsoptimalisert tema.

Fordi temaet er som skjelettet til nettstedet ditt, vil kroppen bli ødelagt hvis skjelettet er ødelagt. Det er bare det.

Det finnes en lang liste med beste praksis du bør se etter i et tema. Noen av de vanligste dårlige praksisene er overavhengighet av JQuery, lasting av for mye CSS/JS når det ikke trengs, stor temastørrelse og mer. Du kan alltids bruke et verktøy som Yellow Labs for å teste demoen.

Hvis du bruker WordPress, kan du sjekke ut listen over de raskeste WordPress-temaene.

3. Optimaliser bildene dine

Bildene er kule. De gjør innholdet så tiltalende. Men de kan være en belastning hvis de ikke er optimalisert. Å ha store bilder som 3 MB vil definitivt påvirke hastigheten din. Og hvis disse bildene er synlige når nettstedet ditt besøkes før du ruller, vil de definitivt påvirke LCP-beregningen din.

Sannheten er at uoptimaliserte bilder øker størrelsen på siden din. Jo større sidestørrelsen er, jo lengre tid tar det å laste.

Jeg personlig foretrekker å optimalisere hvert bilde før jeg laster dem opp. Jeg bruker ingen ekstern tjeneste for bildeoptimalisering. Men hvis du bruker WordPress eller lignende CMS, finnes det plugins og løsninger for å optimalisere bilder automatisk. Det finnes også skyløsninger uavhengig av hva du bruker.

4. Fjern eller reduser størrelsen på bakgrunnsbilder

Bakgrunnsbilder er vanligvis veldig store. Og det kan redusere lastetiden din, siden den må lastes først før meningsfullt innhold vises.

Du kan fjerne bakgrunnsbildet fullstendig for å få en raskere nettside. Hvis de er så viktige, bør du vurdere å optimalisere dem til den minste størrelsen som mulig eller bruke mønstre i stedet for bilder.

5. Bruk nettleserbufring

Hvis du har mange lojale lesere, bør du vurdere nettleserbufring. Når en bruker besøker nettstedet ditt for første gang, vil nettleseren bufre det nettstedet. For hvert annet besøk vil den lastes på et øyeblikk. Dette kan forbedre FID og LCP betraktelig fra det andre besøket og oppover.

For WordPress-brukere kan de fleste caching-plugins hjelpe deg med å oppnå dette.

6. Reduser JavaScript og utsett ubrukt JavaScript

Selv om JavaScript er fantastisk, er det ofte gjengivelsesblokkerende. Dette betyr at det kan påvirke lastetiden din og til slutt din FID.

Prøv å forminske JavaScript ved å fjerne mellomrom og kommentarer for å redusere filstørrelsen. Sørg også for at du utsetter ikke-kritisk JavaScript. Dette bør forbedre FID-en din.

For WordPress-brukere finnes det plugins som Autoptimize , WP Rocket og andre som kan gjøre dette for deg.

7. Angi AdSense-størrelsesattributt

Hvis du kjører AdSense på nettstedet ditt og sliter med CLS, kan dette løse alle problemene dine. Det gjorde det for meg, og det burde det for deg.

Hvis du har en annonseenhet nær overskriften som er synlig når en bruker besøker, er et problem at annonsen kanskje ikke lastes inn umiddelbart. Den kan lastes inn etter at siden allerede er lastet inn, og når den gjør det, er det et skifte i oppsettet. Dette er veldig vanlig for responsive annonseenheter. Når det skjer, er det umulig å passere CLS-metrikken.

Den beste måten å håndtere dette på er å redigere AdSense-koden litt. Ingen grunn til bekymring, det er veldig legitimt. Bare spesifiser størrelsesattributtet for annonsen, spesielt høyden. Etter at du har gjort det, vil du ikke lenger merke et layoutskifte når annonsen lastes inn.

Nedenfor er et eksempel på en responsiv annonseenhet jeg brukte på bloggen min rett under overskriften. Jeg har erstattet utgiver-ID-en og annonseplassen min med XXXXXX. La merke til at jeg la til høydeattributtet (min-høyde: 300px). I det øyeblikket jeg gjorde det, var alle CLS-problemer borte for alltid.

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- Header ad -->
<ins class="adsbygoogle"
     style="display:block; min-height: 300px"
     data-ad-client="ca-pub-xxxxxxxxxxxxxx"
     data-ad-slot="xxxxxxxxxx"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
     (adsbygoogle = window.adsbygoogle || []).push({});
</script>

Det dette gjør er å reservere den størrelsen på siden. Så hver gang annonser vises, er det ingen layoutskifte, siden du allerede hadde angitt størrelsen.

8. Angi størrelsesattributt for bildene og andre medier

Akkurat som med annonser, kan bilder og andre medier forårsake layoutskift når de lastes inn på nettstedet ditt. Det kan hende du bare leser noe, så lastes et bilde inn og plutselig er det et layoutskifte, det du leste er ute av syne og alt du ser er noe annet, eller du klikker til og med på noe annet ved en feiltakelse.

Du kan unngå alle disse ved å angi størrelsesattributtet til mediefilene dine. Din CLS-beregning vil være glad for at du gjorde det.

9. Lazy Last inn bilder.

Du har kanskje sett rådet på PageSpeed ​​Insight om å utsette bilder utenfor skjermen . Det betyr rett og slett at du må laste inn bildene dine sent.

Det lat lasting gjør er å redusere sidestørrelsen og også redusere innlastingstiden på siden din når en bruker besøker. Noe som er bra for CWV-målinger.

Dette vil spesielt bidra til å forbedre LCP.

10. Optimaliser CSS ved å forminske og generere kritisk CSS

CSS er det som får et nettsted til å se kult ut, men en stor CSS-fil kan være et stort problem fordi det vil forsinke gjengivelsen av siden til brukeren.

Når en bruker besøker nettstedet ditt, vil nettleseren ved normal oppførsel forsinke gjengivelsen av nettsiden til brukeren til den har lastet, analysert og utført all CSS som er referert til i overskriften på nettsiden din. Hvis du har en stor CSS-fil, kan dette være et stort problem. Det vil bremse nettstedet ditt.

Kritisk CSS kan hjelpe ved å bare laste inn CSS som er nødvendig for at siden skal lastes. Mens resten av CSS kan lastes asynkront.

Det kan også hjelpe å redusere CSS-en din ved å fjerne mellomrom og kommentarer for å redusere filstørrelsen.

Du kan også fjerne ubrukt CSS . Hvis en tjeneste du bruker sender ut CSS som ikke er i bruk, er det trygt å fjerne den.

Hvis du bruker WordPress, finnes det plugins som WP Rocket , LiteSpeed ​​Cache, FlyingPress og andre som kan hjelpe deg med å oppnå dette.

11. Implementer AdSense smart loading

Denne metoden kan nesten helt eliminere alle utfordringer hvis AdSense er ansvarlig for å bremse nettstedet ditt.

Dette handler om å laste inn AdSense på en smart måte. AdSense blir ikke lastet inn før en bruker utfører en handling som å rulle eller klikke. Dette vil i stor grad forbedre lastetiden og alle viktige nettviktale som påvirkes av AdSense.

Det finnes mange WordPress-pluginer som kan hjelpe deg med dette, WP Rocket og Flying Scripts er et eksempel. Så vidt jeg vet bryter ikke denne metoden med retningslinjene for Google AdSense.

Merk: Selv om denne metoden kan bidra til å forbedre opplevd hastighet og sidescore, kan den påvirke AdSense-inntektene dine. Jeg anbefaler at du kjører et eksperiment for å være sikker på om det er verdt det.

12. Bruk System Stack font hvis du kan

Fonter legger til ekstra lastetid på alle nettsider. Og for nettsider uten bilder kan tekstblokken din være ansvarlig for LCP-vurderingen din. I så fall vil LCP-poengsummen din bli direkte påvirket av fonten din.

Mens Google Font og Font Awesome fortsetter å forbedre seg, gir bruk av systemstackfont en betydelig forbedring. Selv om det ikke er så fantasifullt avhengig av enheten.

13. Bruk et CDN

Hvis du har brukere fra forskjellige deler av verden, kan bruk av et CDN bidra til å forbedre hastigheten og indirekte dine Core Web Vitals-beregninger.

Et CDN i enkel forklaring lager mange kopier av nettstedet ditt og lagrer dem i ulike Point of Presence (POPs) i forskjellige deler av verden. Når noen ber om nettstedet ditt, betjener det nettstedet ditt fra nærmeste posisjon.

For eksempel, hvis nettstedet ditt er vert i USA og du har en besøkende fra Storbritannia, i stedet for å hente nettstedet ditt fra USA, vil CDN betjene nettstedet ditt fra Storbritannia. Effekten av det vil være rask levering. Fart.

Du kan sjekke ut de beste CDN-ene der ute.

14. Sett opp DNS-forhåndshenting

Hvis du er avhengig av en ekstern tjeneste som et CDN for levering av nettstedet ditt, kan det hende du må sette opp en DNS-forhåndshenting for å minimere forsinkelser på grunn av DNS-oppslag.

DNS-forhåndshenting vil forhåndshente DNS før den kalles opp. Slik at den laster på et øyeblikk når den endelig kalles.

15. Optimaliser tredjepartsskript

Kontroller at noen av tjenestene du bruker på nettstedet ditt ikke legger til tredjepartsskript som kan redusere hastigheten på sidene dine.

Du kan erstatte løsningen med tredjepartsforespørsler som bremser nettstedet ditt med en bedre løsning.

Når det gjelder Google AdSense, et annet tredjepartsskript, er det lite du kan gjøre. Den beste praksisen er å bruke maksimalt 3 annonser samlet på en side. Unngå Matchet innhold siden det gir lav inntekt, men øker lastetiden.

16. Fjern AdSense fra den synlige delen av nettsiden

Dette rådet er basert på eksperimenter. Hvis alle beregningene dine er gode i søkekonsollrapporten unntatt LCP, må du først sørge for at bildene og skriftene dine er optimalisert. Hvis de er optimalisert og du fortsatt mislykkes i LCP, kan AdSense være ansvarlig.

Hvis du har råd til det, fjern AdSense fra den synlige delen av nettsiden i en måned og se om problemet forsvinner.

Hvis du ikke vil fjerne det, kan du utsette det manuelt eller ved hjelp av en plugin som Flying Scripts.

17. Bytt til AMP

AMP står for Accelerated Mobile Pages. Ideen bak AMP er å optimalisere nettsider for å laste raskere på mobil. Og selvfølgelig ble AMP- prosjektet med åpen kildekode startet av Google.

Mens AMP opprinnelig var ment å øke hastigheten på mobilsider, kan den også øke hastigheten på skrivebordssider.

AMP-sider er konsekvent raskere enn mobil- eller datamaskinsider, noen ganger med over 100 % i henhold til vår observasjon.

Hvis den eneste strategien for inntektsgenerering for nettstedet ditt er Google AdSense, kan du vurdere å bytte hele nettstedet til AMP. Jeg har personlig lagt merke til at på en blogg jeg eier, konverterer AdSense på AMP-sider noen ganger mer enn på mobil og datamaskin!

Konklusjon

Kjernewebviktalene kan hjelpe deg med å forbedre nettstedet ditt for brukerne dine, ikke bare for Google. Det er veldig vanlig å ha en god labdatatestscore, men dårlig feltdatascore.

Dette er på grunn av sammensetningen til brukerne dine. Hvis de fleste av brukerne dine kommer fra steder med tregt internett, kan det hende du har gjort en god jobb med å optimalisere, men fortsatt mislykkes i feltdata.