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 kunngjort at fra mai 2021 vil disse beregningene bli en del av rangeringssignalene deres som brukes til å bestemme nettsideplasseringer 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 tilfredsstillende maling (LCP): LCP måler tiden det tar før det største synlige bildet eller tekstblokken på en nettside lastes inn. Hvis den største synlige teksten eller bildet lastes raskt, oppfattes det som at resten av bildene og teksten vil lastes raskt. Den nødvendige lastetiden for å passere er 2.5 sekunder.

Første inngangsforsinkelse (FID): FID måler nettsideinteraktivitet. Dette bestemmes av hvor lang tid det tar før nettleseren begynner å behandle hendelsesbehandlere etter at en bruker har klikket på nettstedet ditt. Dette kalles mye for førsteinntrykket av nettstedet ditt. Den nødvendige tiden for å passere er 100 millisekunder.

Kumulativ Layout Shift (CLS): CLS måler layoutskifte som skjer på en nettside. Når en nettside lastes inn og så plutselig noe dukker opp eller forsvinner og siden må tilpasse seg til å bli større eller mindre, er det skiftet som måles. Det er forferdelig for brukeropplevelsen, og jeg er enig. Poengsummen du bør 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 webverten, sørg alltid for å få et datasenter nærmere flertallet av nettstedets brukere. Du kan finne plasseringene deres ved å se på analysene dine. Hvor kommer de fleste 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 leter etter en rask webvert, er det mange anbefalinger der ute som er drevet utelukkende av tilknyttede selskaper uten oppriktighet. Hvis du kjører WordPress og har råd til det, anbefaler jeg det på det sterkeste Kinsta. De er de beste for WordPress. Hvis du trenger noe billigere eller du ikke bruker WordPress da Cloudways er 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 er en lang liste over beste fremgangsmåter du bør se etter i et tema. Noen av de vanligste dårlige praksisene er overavhengige av JQuery, laster for mange CSS/JS når det ikke er nødvendig, stor temastørrelse og mer. Du kan alltid bruke et verktøy som Gule laboratorier, for å teste demoen.

Hvis du bruker WordPress, kan du sjekke listen over raskeste WordPress-temaer.

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ådene om PageSpeed ​​Insight til utsett bilder utenfor skjermen. Det det rett og slett betyr er å lade inn bildene dine.

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å fjern ubrukt CSS. Hvis en tjeneste du bruker pusher CSS som ikke brukes, er det trygt å fjerne dem.

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 er mange WordPress-plugins som kan hjelpe deg med dette, WP Rocket og Flying Scripts er et eksempel. Denne metoden bryter så vidt jeg vet ikke Google AdSense-retningslinjene.

OBS: Selv om denne metoden kan bidra til å forbedre opplevd hastighet og sidepoeng, 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 betale for beste CDN-er 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 forsinkelse 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 betyr Accelerated Mobile Pages. Ideen med AMP er å optimalisere nettsider for å lastes raskere på mobil. Og selvfølgelig AMP åpen kildekode prosjektet ble 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.