Sådan optimerer du din hjemmeside til Core Web Vitals (Adsense)

Kapløbet om at forbedre Core Web Vitals er ikke let. Det bliver sværere, hvis du stoler på et annonceringsprogram som Google AdSense til at tjene penge på dit websted.

Websites, der kører Google AdSense, er 10 gange mere tilbøjelige til at mislykkes i Core Web Vitals-testen end det samme websted uden Google AdSense på det. Dette skyldes for det meste antallet af tredjepartsanmodninger og -aktiver, som Google AdSense føjer til dit websted. De fleste af disse aktiver er uoptimerede, store og ikke-brugervenlige.

Uden for AdSense og annonceringsplatforme, hvis du har mange uoptimerede billeder, JavaScript og CSS, især over skillelinjen, så er det også meget sandsynligt, at du fejler Core Web Vitals-testen.

Hvis du har kæmpet for at bestå Core Web Vitals-testen og forbedre dine søgemaskiners placeringspotentialer, vil du finde praktiske løsninger i denne artikel.

Hvad er Core Web Vitals?

Core Web Vitals er metrics drevet af Google Lighthouse, der bestemmer, hvordan et websted leverer en god sideoplevelse. Selvom der er mange målinger, når du kører en test, er de vigtigste målinger Largest Contentful Paint (LCP), First Input Delay (FID) og Cumulative Layout Shift (CLS).

Google har annonceret at fra maj 2021 vil disse metrics blive en del af deres rangeringssignaler, der bruges til at bestemme websidens placeringer i søgeresultaterne.

Sammenfattende kan du sige, at Core Web Vitals ikke var ment som en terror for webmastere, men et middel til at forbedre sideoplevelsen på websteder.

Største indholdsfulde maling (LCP): LCP måler den tid, det tager for det største synlige billede eller tekstblok på en webside at indlæse. Hvis den største synlige tekst eller billede indlæses hurtigt, opfattes det, at resten af ​​dine billeder og tekst indlæses hurtigt. Den nødvendige indlæsningstid for at passere er 2.5 sekunder.

Første inputforsinkelse (FID): FID måler websideinteraktivitet. Dette bestemmes af, hvor lang tid det tager for browseren at begynde at behandle hændelseshandlere, efter at en bruger har klikket på dit websted. Dette kaldes i vid udstrækning det første indtryk af din hjemmeside. Den nødvendige tid til at gå er 100 millisekunder.

Kumulativ layoutskift (CLS): CLS måler layoutskift, der sker på en webside. Når en webside indlæses, og så pludselig dukker noget op eller forsvinder, og siden skal tilpasse sig til at være større eller mindre, er det skiftet det, der måles. Det er forfærdeligt for brugeroplevelsen, og jeg er enig. Den score du skal bestå er 0.1.

Sådan optimerer du din hjemmeside til Core Web Vitals

Følg disse trin for at optimere dit websted:

1. Start med en hurtig webhost

Hvis du har en webhost med en frygtelig svartid, så giver alle andre ting, som jeg vil liste her, måske ikke de ønskede resultater. Jo hurtigere din server reagerer på anmodninger, jo bedre.

Hvorfor er en webhost med en hurtig Time to first byte (TTFB) vigtig? Nogle vil hævde, at TTFB ikke betyder noget, men det gør det. Det er grundlaget for alt andet. Hvis du har brugere i byer med langsomt internet, vil det betyde alt, hvor hurtigt din webhost kan reagere. Enhver webhost kan præstere godt, hvis du har brugere primært fra byer med superhurtigt internet.

Prøv at teste, hvordan din webhost vil reagere på 3G eller 2G i stedet for 4G. For hvis du får mange brugere til at oprette forbindelse via 3G eller 2G, lægger det op til din Core Web Vitals-score. Så hvert millisekund tæller. Forskellen mellem at få 100ms i din FID og at få 101ms er, at med 100ms består du, men med 101ms fejler du. Så hvis nogen fortæller dig, at 1 ms ikke betyder noget, kan denne person bare tage fejl.

Når du vælger en webhost, sørg altid for at komme et datacenter tættere på størstedelen af ​​dine webstedsbrugere. Du kan finde deres placeringer ved at se på dine analyser. Hvor kommer de fleste af dine brugere fra? Vælg et datacenter tættere på dem. Jo tættere jo bedre.

Jeg har personligt bemærket en væsentlig ændring i et websteds feltdata for kernewebvitaliteter efter ændring af webhost. Jeg lavede ikke andet.

Hvis du leder efter en hurtig webhost, er der masser af anbefalinger derude, som udelukkende er drevet af tilknyttede selskaber uden oprigtighed. Hvis du kører WordPress, og du har råd til det, kan jeg varmt anbefale det Kinsta. De er de bedste til WordPress. Hvis du har brug for noget billigere eller du ikke bruger WordPress så Cloudways er også meget effektiv.

2. Brug et letvægts- og hastighedsoptimeret tema

Dette tip er især meget nyttigt for ikke-kodere og endda for kodere med kortere tid. Især hvis du bruger WordPress, hvor der er så mange muligheder, så sørg for at bruge et letvægts- og hastighedsoptimeret tema.

Fordi temaet er ligesom skelettet på din hjemmeside, hvis skelettet er knækket, så vil kroppen blive ødelagt. Det er bare det.

Der er en lang liste over bedste praksis, du bør kigge efter i et tema. Nogle af de mest almindelige dårlige fremgangsmåder er overafhængige af JQuery, indlæsning af for mange CSS/JS, når det ikke er nødvendigt, stor temastørrelse og mere. Du kan altid bruge et værktøj som f.eks Gule laboratorier, for at teste demoen.

Hvis du bruger WordPress, kan du tjekke listen over hurtigste WordPress-temaer.

3. Optimer dine billeder

Billeder er seje. De gør indhold så tiltalende. Men de kan være en belastning, hvis de er uoptimerede. At have store billeder som 3 MB vil helt sikkert påvirke din hastighed. Og hvis disse billeder er synlige, når dit websted besøges, før du ruller, vil de helt sikkert påvirke din LCP-metrik.

Sandheden er, at uoptimerede billeder øger størrelsen på din side. Jo større sidestørrelsen er, jo længere tid tager det at indlæse.

Jeg foretrækker personligt at optimere hvert billede, før jeg uploader dem. Jeg bruger ingen ekstern service til billedoptimering. Men bruger du WordPress eller lignende CMS, findes der plugins og løsninger til at optimere billeder automatisk. Der findes også cloud-løsninger, uanset hvad du bruger.

4. Fjern eller reducer størrelsen af ​​baggrundsbilleder

Baggrundsbilleder er normalt meget store. Og det kan sænke din indlæsningstid, da det først skal indlæses, før der vises meningsfuldt indhold.

Du kan helt fjerne baggrundsbilledet for at få en hurtigere hjemmeside. Hvis de er så vigtige, så overvej at optimere dem til den mindst mulige størrelse eller bruge mønstre i stedet for billeder.

5. Brug browser caching

Hvis du har mange loyale læsere, bør du overveje browser-cache. Når en bruger besøger dit websted for første gang, vil browseren cache det pågældende websted. For hvert andet besøg indlæses den på et øjeblik. Dette kan i høj grad forbedre FID og LCP fra det andet besøg og opefter.

For WordPress-brugere kan de fleste caching-plugins hjælpe dig med at opnå dette.

6. Formindsk JavaScript, og udskyd ubrugt JavaScript

Selvom JavaScript er fantastisk, er det ofte gengivelsesblokerende. Det betyder, at det kan påvirke din indlæsningstid og i sidste ende din FID.

Prøv at formindske JavaScript ved at fjerne de hvide mellemrum og kommentarer for at reducere filstørrelsen. Sørg også for, at du udsætter ikke-kritisk JavaScript. Dette burde forbedre din FID.

For WordPress-brugere er der plugins som f.eks Autoptimize, WP Rocket, og andre, der kan gøre dette for dig.

7. Indstil AdSense-størrelsesattribut

Hvis du kører AdSense på dit websted, og du kæmper med CLS, så kan dette løse alle dine problemer. Det gjorde det for mig, og det burde det for dig.

Hvis du har en annonceenhed tæt på overskriften, som er synlig, når en bruger besøger, er et problem, at annoncen muligvis ikke indlæses med det samme. Det kan indlæses, efter at siden allerede er indlæst, og når det sker, sker der et skift i layoutet. Dette er meget almindeligt for responsive annonceenheder. Når det sker, er det umuligt at bestå CLS-metrikken.

Den bedste måde at håndtere dette på er at redigere din AdSense-kode lidt. Ingen bekymringer, det er meget legitimt. Du skal blot angive størrelsesattributten for annoncen, især højden. Når du har gjort det, vil du ikke længere bemærke et layoutskift, når annoncen indlæses.

Nedenfor er et eksempel på en responsiv annonceenhed, jeg brugte på min blog lige under overskriften. Jeg har erstattet mit udgiver-id og annonceplads med XXXXXX. Bemærkede, at jeg tilføjede højde-attributten (min-højde: 300px). I det øjeblik, jeg gjorde det, var alle CLS-problemer væk for altid.

<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>

Hvad dette gør, er at reservere den størrelse på siden. Så hver gang der vises annoncer, er der ingen layoutændring, da du allerede havde indstillet størrelsen.

8. Indstil størrelsesattribut for dine billeder og andre medier

Ligesom med annoncer kan billeder og andre medier forårsage layoutskift, når de indlæses på din hjemmeside. Du læser måske bare noget, så indlæses et billede, og pludselig sker der et layoutskift, det du læste er ude af syne, og alt du ser er noget andet, eller du klikker endda på noget andet ved en fejl.

Du kan undgå alle disse ved at indstille størrelsesattributten til dine mediefiler. Din CLS-metrik vil være glad for, at du gjorde det.

9. Lazy Indlæs billeder.

Du har måske set rådet om PageSpeed ​​Insight til udskyde billeder uden for skærmen. Hvad det blot betyder, er at lade dine billeder lade indlæse.

Hvad lazy loading gør, er at reducere sidestørrelsen og også reducere indlæsningstiden på din side, når en bruger besøger. Hvilket er godt for CWV-målinger.

Dette vil især hjælpe med at forbedre LCP.

10. Optimer CSS ved at minificere og generere kritisk CSS

CSS er det, der får en hjemmeside til at se cool ud, men en stor CSS-fil kan være et stort problem, fordi det vil forsinke gengivelsen af ​​siden til brugeren.

Når en bruger besøger dit websted, vil browseren ved normal adfærd forsinke gengivelsen af ​​din webside til brugeren, indtil den har indlæst, parset og eksekveret al CSS, der refereres til i din websides header. Hvis du har en stor CSS-fil, kan dette være et stort problem. Det vil bremse dit websted.

Kritisk CSS kan hjælpe ved kun at indlæse den CSS, der er nødvendig for, at siden kan indlæses. Mens resten af ​​CSS'en kan indlæses asynkront.

Det kan også hjælpe at formindske din CSS ved at fjerne hvide mellemrum og kommentarer for at reducere filstørrelsen.

Du kan også fjern ubrugt CSS. Hvis en tjeneste, du bruger, pusher CSS, der ikke bruges, er det sikkert at fjerne dem.

Hvis du bruger WordPress, er der plugins som f.eks WP Rocket, LiteSpeed ​​Cache, FlyingPress og andre, der kan hjælpe dig med at opnå dette.

11. Implementer AdSense smart loading

Denne metode kan næsten fuldstændig eliminere alle udfordringer, hvis AdSense er ansvarlig for at bremse dit websted.

Det handler om at indlæse AdSense på en smart måde. AdSense indlæses ikke, før en bruger udfører en handling som at rulle eller klikke. Dette vil i høj grad forbedre indlæsningstiden og alle vitale kerneinternet, der påvirkes af AdSense.

Der er mange WordPress plugins, der kan hjælpe dig med at gøre dette, WP Rocket og Flying Scripts er et eksempel. Denne metode, så vidt jeg ved, overtræder ikke Google AdSense-politik.

Bemærk: Selvom denne metode kan hjælpe med at forbedre opfattet hastighed og sidescore, kan den påvirke din AdSense-indtjening. Jeg anbefaler, at du kører et eksperiment for at være sikker på, om det er det værd

12. Brug System Stack skrifttype, hvis du kan

Skrifttyper tilføjer ekstra indlæsningstid på ethvert websted. Og for websider uden billeder kan din tekstblok være ansvarlig for din LCP-vurdering. I så fald vil din LCP-score blive direkte påvirket af din skrifttype.

Mens Google Font og Font Awesome fortsætter med at forbedre sig, giver brug af systemstack-skrifttype en betydelig forbedring. Selvom det ikke er så fantasifuldt afhængigt af enheden.

13. Brug et CDN

Hvis du har brugere fra forskellige dele af verden, kan brugen af ​​et CDN hjælpe med at forbedre din hastighed og indirekte dine Core Web Vitals-metrics.

Et CDN i enkel forklaring laver mange kopier af din hjemmeside og gemmer dem i forskellige Point of Presence (POP'er) i forskellige dele af verden. Når nogen anmoder om din hjemmeside, betjener den din hjemmeside fra den nærmeste placering.

Hvis dit websted f.eks. er hostet i USA, og du har en besøgende fra Storbritannien, vil CDN betjene dit websted fra Storbritannien i stedet for at hente dit websted fra USA. Effekten af ​​det vil være hurtig levering. Hastighed.

Du kan tjekke ud bedste CDN'er derude.

14. Konfigurer DNS-prefetching

Hvis du er afhængig af en ekstern service som et CDN til levering af din hjemmeside, så skal du muligvis opsætte en DNS Prefetching for at minimere forsinkelse på grund af DNS-opslag.

DNS-prefetching vil forhåndshente DNS'en, før den kaldes. Så den indlæses på et øjeblik, når den endelig kaldes.

15. Optimer tredjepartsscripts

Tjek for at sikre, at nogle af de tjenester, du bruger på dit websted, ikke tilføjer tredjepartsscripts, der kan gøre dine websteder langsommere.

Du kan erstatte løsningen med tredjepartsanmodninger, hvilket gør dit websted langsommere med en bedre løsning.

Når det kommer til Google AdSense, et andet tredjepartsscript, er der lidt du kan gøre. Den bedste praksis er at bruge maksimalt 3 annoncer samlet på en side. Undgå Matchet indhold, da det giver lav indkomst, men øger indlæsningstiden.

16. Fjern AdSense fra over skillelinjen

Dette råd er baseret på eksperimenter. Hvis alle dine metrics er gode i søgekonsolrapporten undtagen LCP, skal du først sikre dig, at dine billeder og skrifttyper er optimeret. Hvis de er optimeret, og du stadig fejler LCP, er AdSense muligvis ansvarlig.

Hvis du har råd til det, skal du fjerne AdSense fra skillelinjen i en måned og se, om problemet forsvinder.

Hvis du ikke vil fjerne det, kan du forsinke det manuelt eller ved hjælp af et plugin som Flying Scripts.

17. Skift til AMP

AMP betyder Accelerated Mobile Pages. Ideen med AMP er at optimere websider, så de indlæses hurtigere på mobilen. Og selvfølgelig AMP open source projektet blev startet af Google.

Mens AMP oprindeligt var beregnet til at fremskynde mobilsider, kan det også fremskynde desktopsider.

AMP-sider er konsekvent hurtigere end mobil- eller desktopsider, nogle gange med over 100 % ifølge vores observation.

Hvis den eneste indtægtsgenereringsstrategi for dit websted er Google AdSense, kan du overveje at skifte hele dit websted til AMP. Jeg har personligt bemærket, at på en blog, jeg ejer, konverterer AdSense på AMP-sider nogle gange mere end på mobil og computer!

Konklusion

Vitalkerne på nettet kan hjælpe dig med at forbedre dit websted for dine brugere, ikke kun for Google. Det er meget almindeligt at have en god laboratoriedatatestscore, men dårlig feltdatascore.

Dette skyldes sammensætningen af ​​dine brugere. Hvis de fleste af dine brugere kommer fra steder med langsomt internet, har du muligvis gjort et godt stykke arbejde med at optimere, men stadig fejle i feltdata.