Taktikker for utgivervekst i valgkampen | WEBINAR
Taktikker for utgivervekst i valgkampen | WEBINAR
Ved slutten av denne modulen bør du ha en klar forståelse av de ulike komponentene som bidrar til sideopplevelsen, hvorfor de er viktige og hvordan hver av dem kan optimaliseres for å forbedre både nettstedets brukeropplevelse og SEO.
Videoens varighet
17:09
Svar på quiz
Ta quiz for gjeldende modul
Materialer
Klar til bruk maler
Ressurser
Rapporter og ressurser
2.3.1 Hva er sideopplevelse?
Sideopplevelse er et sett med signaler – inkludert Core Web Vitals (CWV-er), mobilvennlighet, HTTPS og retningslinjer for påtrengende mellomliggende annonser – som Google bruker for å ekstrapolere brukeropplevelsen på et nettsted.
Sideopplevelse er en evaluering av et nettsteds ytelse snarere enn innholdet. Selv om Google fortsatt prioriterer innholdsrelevans når de svarer på brukerhenvendelser, er sideopplevelsen i praksis en avgjørende faktor når flere nettsteder tilbyr et lignende dekningsnivå.
De fire sidenes opplevelsessignaler er:
CWV-er måler brukeropplevelse ved å fokusere på hvor raskt en side lastes inn, dens respons på brukerinput og også dens visuelle stabilitet. Det finnes tre målinger for dette:
Googles oppdatering fra april 2015 introduserte søkegigantens mobilvennlighetsmåling, som øker rangeringen av mobilvennlige sider på mobile SERP-er.
Google vil effektivt prioritere nettsteder som sørger for at innholdet deres er lettlest på mobile enheter – det betyr at det ikke er behov for å zoome, berøringspunkter som påloggingsknapper ikke er plassert for nær hverandre, det er ingen horisontal rulling, og innhold som ikke kan spilles av unngås.
Oppdateringen gjelder for individuelle sider, ikke hele nettsteder, og påvirker heller ikke innhold som vises i nettlesere på stasjonære/bærbare datamaskiner.
HTTPS, eller Hypertext Transfer Protocol Secure, er en sikker versjon av HTTP-internettkommunikasjonsprotokollen.
HTTPS, eller HTTP, danner den første delen av hver URL, kjent som «scheme». Denne kommer før domenenavnet, som er den delen av URL-en som kalles «autoritet».
Forskjellen mellom HTTPS og HTTP er at førstnevnte er sikkert, mens sistnevnte ikke er det. Dette betyr i praksis at brukere som logger seg på et nettsted via en HTTP-tilkobling sender sine personlige opplysninger i ukryptert ren tekst.
HTTPS sikrer den forbindelsen, noe som betyr at all data som sendes mellom brukerens nettleser og nettstedets server krypteres underveis. Nettsteder som ønsker sikre forbindelser trenger et SSL-sertifikat, som brukerens nettleser sjekker og verifiserer.
Interstitialer er et annonseformat kun for mobil som bare vises i naturlige pauser i innholdet – for eksempel når en bruker går fra én artikkel til den neste – og dekker skjermen i prosessen.
Mellomliggende annonser blir sett på som påtrengende når de blokkerer eller delvis skjuler brukerens visning av innholdet. Dialogbokser på mobilnettsteder som oppfører seg på lignende måte faller også inn under denne kategorien.
De fleste utgiveres sterkeste ferdigheter er innholdsproduksjon, publisering og markedsføring, noe som gir lite rom for både å forstå og optimalisere de ulike sideopplevelsesgrunnlagene.
Begrensede ressurser betyr at utgivere vil slite med å rettferdiggjøre tiden og pengene som trengs for å grave i bakgrunnen av individuelle nettsider, enn si et helt nettsted.
Selv om utgivere klarer å sette av tid til å håndtere problemet, som vi kan se ovenfor, er sideopplevelse et mangesidig problem som krever en helhetlig tilnærming for å levere meningsfulle ytelsesforbedringer.
Å vite hvilket av de fire siders opplevelsessignalene man skal begynne å jobbe med kan være en hodepine i seg selv.
Sideopplevelsen er utrolig viktig for utgiveres SEO, ettersom godt innhold ikke er nok til å garantere topplassering i SERP-ene.
Google verdsetter fortsatt den beste informasjonen fremfor alt annet, noe som betyr at unikt innhold eller nyhetsscoops vil prestere bra selv om sideopplevelsen er «under pari» . I tilfeller der flere utgivere tilbyr utmerket temadekning, blir imidlertid sideopplevelsen en viktig avgjørende faktor som påvirker SERP-rangeringene.
Hver av de fire sideopplevelsessøylene har en ulik innvirkning på et nettsteds SEO. Den mest umiddelbare effekten kommer fra å fokusere på CWV-er, som vil føre til et nettsted som laster raskere.
Tallrike studier har vist at jo lenger tid det tar for et nettsted å laste, desto raskere mister publikum interessen og desto høyere blir avvisningsfrekvensen.
For eksempel fant en Google-studie fra 2018 at sannsynligheten for avvisning økte med 32 % da sideinnlastingstiden økte fra 1 sekund til 3 sekunder.
En annen Google-studie fra 2020 fant at nyhetssider som besto CWV-testen hadde en 22 % lavere forlatelsesrate enn de som ikke besto. Yahoo! JAPAN forbedret i mellomtiden CLS-poengsummen sin med 0,2 og så en økning på 15,1 % i sidevisninger per økt og en økning på 13,3 % i øktvarighet.
Selv om Google eksplisitt har sagt at de ikke bruker avvisningsfrekvenser som et rangeringssignal , vitner en høy avvisningsfrekvens om faktorer Google bryr seg om – nemlig en sides lastehastighet, responstid og visuelle stabilitet.
Utgivere som retter seg mot målgrupper på mobile enheter må sørge for at nettstedet deres sender mobilvennlige signaler som både Google og Bing kan fange opp. Begge søkemotorene vil prioritere brukervennlige nettsteder når de leverer søkeresultater til mobilbrukere.
Sammenlignet med CWV-er og mobilvennlighet, vil implementering av HTTPS ha en mye mindre innvirkning på en utgivers SEO. Google sa i 2014 at de ville bruke det som et rangeringssignal og begynte å merke alle HTTP-nettsteder som «ikke sikre» i Chrome i 2018. Den største fordelen her er imidlertid forbedret datasikkerhet, spesielt hvis forretningsmodulen din er basert på abonnementsinntekter.
Påtrengende mellomliggende annonser eller dialogbokser kan i mellomtiden begrense nettcrawlers evne til å gjennomsøke og indeksere en side, noe som hindrer søkemotorer i å rangere den, for ikke å få den høyt oppe i søkeresultatene.
Det første steget mot å forbedre sideopplevelsen begynner med å evaluere nettstedets nåværende effektivitet.
Det finnes et bredt utvalg av første- og tredjepartsverktøy for å oppnå dette, men i denne veiledningen skal vi se på Googles førstepartsverktøy.
Vi vet nå at CWV-er er en viktig rangeringsfaktor. Men hvordan måles de? Tabellen nedenfor viser parameterne som optimale CWV-tall bør ligge innenfor for den beste sideopplevelsen.
Nå som vi vet hva vi må måle og hvor mye, kan vi se på hvordan vi kan gå frem for å måle sideopplevelsen.
Nedenfor er en liste over noen av de mest brukte metodene.
Det første alternativet som er åpent for utgivere er uten tvil det mest teknisk utfordrende, og det er ikke et vi vil anbefale å vurdere med mindre du har en god utvikler som kan hjelpe deg med implementeringen.
Vi snakker om å samle inn brukerdata fra nettstedet ditt, en prosess kjent som ekte brukerovervåking (RUM), og deretter analysere resultatene i Google Analytics 4 (GA4). Google har andre verktøy, som PageSpeed Insights (PSI), som bruker datasampling for å evaluere nettstedet ditt. Men hvis målet er å ha et komplett bilde av brukeropplevelsen for nettstedet ditt, trenger du reelle data samlet inn fra nettstedet ditt.
Vi anbefaler å bruke GA4 til denne oppgaven av den enkle grunn at Google har til hensikt å begynne å «avvikle» den forrige generasjonen av Google Analytics, Universal Analytics (UA), fra midten av 2023.
Som utgiver bør du allerede ha opprettet en GA4-konto i påvente av overgangen. Hvis du ikke har det, kan du følge Googles veiledninger for hvordan du enten konfigurerer den for første gang eller hvordan du legger den til et nettsted som allerede har UA .
Når det er gjort, er neste trinn å koble Googles BigQuery-datavarehus til GA4 fra Analytics Admin. Ved å koble BigQuery kan du spørre dataene dine ved hjelp av SQL. Her er en veiledning for hvordan du kobler de to .
Nå som disse trinnene er unnagjort, kan vi legge til Googles bibliotek med nettdata på nettstedet ditt.
Biblioteket, som er et ekstremt lite modulært JavaScript-bibliotek for datainnsamling, er tilgjengelig på GitHub.
Biblioteket kan installeres enten fra det åpne npm-nettarkivet ved å kjøre «npm install web-vitals» i kommandoterminalen din eller via<script> tags on a content distribution network (CDN).
Her er et eksempel på et slikt skript:
Når biblioteket for nettdata er installert, kan brukerdata sendes til Google Tag Manager (GTM) ved hjelp av en tilpasset maltagg anbefalt av Google som Simo Ahava har opprettet og vedlikeholder.
Når taggen er installert, kan CWV-beregningene og tilhørende attribusjonsdata videresende den til GA4.
Når du har konfigurert analyser for å spore GTM-dataene, kan du se hendelsesdata i BigQuery-grensesnittet. Disse dataene kan deretter spørres slik:
Når spørringen er returnert, skal rapporten se omtrent slik ut:
Vi må virkelig understreke igjen at dette er en utviklerløsning og faktisk er mye mer kompleks enn dette. Å ta i bruk denne løsningen vil imidlertid gi deg den mest nøyaktige avlesningen av nettstedets ytelse.
For en mer detaljert forklaring av denne prosessen, sjekk ut Googles veiledning for visning av CWV-er i GA4 .
Selv om dette er den mest nøyaktige tilnærmingen til overvåking av CWV-er, finnes det enklere tilnærminger for å løse dette problemet.
PSI er mindre nøyaktig enn å bruke en GA/RUM-tilnærming, men det blir ofte sitert som et av de viktigste verktøyene for å måle CWV-er – takket være verktøyets brukervennlighet.
Selv om den kanskje bare bruker eksempler på reelle brukeropplevelser hentet fra Chrome User Experience Report (CrUX) i løpet av den foregående 28-dagersperioden, tilbyr PSI et enkelt og lettforståelig brukergrensesnitt . Dette betyr at det er en mye enklere prosess å tolke dataene.
Som du kan se i eksemplet vårt nedenfor, gir en undersøkelse av Forbes' nettsted umiddelbart en mengde informasjon om både utgiverens desktop- og mobilnettsted.
PSI bruker de grønne, gule og røde kategoriene ovenfor når de tildeler karakterene God, Trenger forbedring og Dårlig ytelse.
CrUXs utvalgsmetode betyr at selv om Forbes' vurdering ovenfor tok inn noen brukeropplevelser av nettstedet fra den virkelige verden, kan den ikke ta hensyn til alle nettstedets brukerdata.
Denne utvalgsmetoden blir problematisk for mindre steder, hvorav mange ikke vil vises i CrUXs feltdata.
PSI kan imidlertid fortsatt tilby en virtuell diagnose av nettstedet ditt ved hjelp av laboratoriedata hentet fra Googles åpen kildekode-verktøy Lighthouse . Se eksemplet nedenfor:
Problemet med denne tilnærmingen er at Lighthouse samler inn dataene sine ved hjelp av forhåndsbestemte enhets- og nettverksinnstillinger, som ikke vil gjenspeile brukerens innstillinger. Dette betyr at det er en dårlig erstatning for den ekte varen.
GSC er et verktøy som er utviklet for å gi utgivere et overblikk over nettstedets CWV-problemer, og åpner døren for en helhetlig tilnærming for å forbedre nettstedets ytelse.
Den gjør dette ved å gruppere URL-ytelsesrapportene sine basert på status, metrikktype eller emnelikhet. Den identifiserer ikke problemer med individuelle sider, og nekter dermed muligheten til å implementere rettelser på et detaljert nivå.
Det er her PSI kommer inn i bildet. Det er imidlertid verdt å merke seg at PSIs individuelle siderapport kan avvike markant fra GSCs grupperesultater. Det er fordi den individuelle siden bare er én komponent av GSCs aggregerte grupperesultater.
Når brukerne logger seg på GSCs dashbord, vil de se fanen Core Web Vitals på venstre side. Ved å klikke på denne fanen vises separate CWV-rapporter for mobil og datamaskin for URL-grupper.
Til tross for at det finnes tre CWV-målinger – LCP, FID og CLS – vil URL-er få en samlet vurdering basert på den dårligste målingen for en bestemt enhet, noe som også vil påvirke grupperapportene.
Hvis for eksempel en URL på mobil får en dårlig FID og en god LCP, vil den bli merket som dårlig på mobil.
Igjen, det er viktig å merke seg at GSC ikke er ment for detaljerte rettelser. Det er imidlertid flott for utgivere som har mange lignende sider. For eksempel kan nyhetssider ha et relativt standard design og layout for artikkelsidene sine som bruker et bilde som det største elementet over fold. I dette tilfellet kan GSC raskt hjelpe med å identifisere LCP-problemer på tvers av en rekke nettadresser.
Det siste verktøyet i Googles verktøysett for ytelsesmåling er Lighthouse . Dette verktøyet er helt annerledes enn de tidligere ved at det emulerer brukerytelse basert på et etablert sett med parametere.
Den bruker ikke feltdata og er derfor mer begrenset når det gjelder praktisk bruk. For eksempel påvirkes feltdata av en brukers nettverkstilkobling og avstanden til nettstedets servere, mens Lighthouse emulerer en mellomklasseenhet for å samle inn data i et kontrollert miljø.
Det er også viktig å forstå at Lighthouses poengsum ikke bare er en sammenslåing av CWV-poengsummer. Den ekskluderer FID, siden laboratoriedata i sin natur ekskluderer sluttbrukerinteraksjoner, samtidig som den legger til total blokkeringstid (TBT), hastighetsindeks (SI) og tid til interaktivitet (TTI)-beregninger. For de som ønsker å simulere en FID-opplevelse i laboratoriet, kan TBT brukes som en proxy.
Vi vil imidlertid fraråde å bruke Lighthouse som en primær måleressurs. Det bør heller brukes som et tilleggsverktøy sammen med PSI for å feilsøke spesifikke sideproblemer.
Utgivere som ønsker å bruke Lighthouse i testingen sin, kan gjøre det via Chrome Devtools som er integrert direkte i Chrome-nettleseren, en utvidelse for nevnte nettleser eller på web.dev/measure .
Lighthouse vil granske nettsiden din og gi poengsummer ut av 100 på fire områder:
Slik ser det ut når vi legger inn hjemmesiden vår via web.dev-alternativet.
Mobil webdesign skiller seg fra tradisjonell desktop-webdesign ved at mobile enheter har mindre skjermer, vanligvis har mindre kraftig maskinvare og utelukkende er avhengige av berøringsinnganger.
Mobilvennlige nettsteder prioriterer brukeropplevelsen ved å følge et sett med beste praksiser som vi skal se på litt senere. Foreløpig er den beste måten å sjekke om sidene dine er mobilvennlige, med Googles mobilvennlighetstest .
Å skrive inn en URL til en mobilvennlig nettside returnerer følgende resultat:
Sider som ikke består denne testen, vil dukke opp med en rekke alternativer for løsning. Vi kommer tilbake til disse litt senere.
Å sjekke om nettstedet ditt har en sikker forbindelse er en ekstremt enkel prosess. Det innebærer å åpne nettleseren og se på symbolet til venstre for URL-en i adressefeltet.
I Chrome vil en sikker forbindelse bli angitt med et lukket hengelåssymbol slik:
En usikker forbindelse vil ha et infosymbol som dette:
Å avgjøre om mellomliggende annonser er påtrengende eller ikke er ikke så enkelt som å legge inn nettstedet ditt i et nettbasert verktøy og vente på at det skal returnere et hakemerke eller ikke.
Det krever at du studerer mellomliggende annonser og dialogbokser på nettstedet ditt og avgjør om de oppfyller visse parametere.
Tenk på disse parameterne som spørsmål, for eksempel:
Hvis du svarer ja på noen av disse spørsmålene, er det sannsynligvis en indikator på at annonsen eller dialogboksen er påtrengende.
Nå som vi har en god forståelse av de ulike komponentene av de fire som teller mot sideopplevelsen, samt måtene å overvåke ytelsen deres på, la oss gå videre til å utforske hvordan vi kan forbedre rangeringssignalene til nettstedene våre
Vi skal først se på CWV-er, ettersom feilsøking og optimalisering av LCP, CLS og FID vil ha størst innvirkning på din evne til å konkurrere om topplasseringer i hardt omstridte SERP-rangeringer.
Selv om mobilvennlighet er utrolig viktig for nettsteder som retter seg mot mobilbrukere, vil forbedring av CWV-er forbedre sideytelsen for nettsteder, uavhengig av om de vises på mobile enheter eller datamaskiner.
Å takle HTTPS og påtrengende mellomliggende annonser har blitt utsatt til slutt, da de er enklere og mindre givende.
Det finnes en rekke alternativer når det gjelder å forbedre CWV-ytelsen, som vi har delt opp i rekkefølge etter den viktigheten vi mener de fortjener.
Optimalisering av kjerneverdiene for nettanalyse på en hvilken som helst side er et spekter av handlinger, og det er viktig å vite hvor man skal begynne for å maksimere ressursene sine.
Som vi allerede har nevnt ovenfor, måler største innholdsrike farge (LCP) hvor lang tid det tar å laste inn den største tekst- eller bilderessursen som er synlig over bretten.
Bruk PSI til å identifisere hvilket sideinnhold som utløser LCP-testen, ved å gå til rapportens diagnoseseksjon og klikke på «Største innholdsrike malingselement». Her er hva vi så fra SODPs hjemmeside:
En dårlig LCP-poengsum kan vanligvis begrenses til enten trege responstider på serveren, gjengivelsesblokkerende JavaScript og CSS, ressursinnlastingstider eller klientsidegjengivelse, eller til og med en kombinasjon av alle fire.
Optimalisering av siden din innebærer faktisk å optimalisere fire forskjellige underdeler av LCP-innlastingsprosessen:
Alle disse trinnene må optimaliseres for at du skal se en forbedring i LCP-poengsummen din. Det betyr imidlertid ikke at alle deldelene er like viktige.
Google har foreslått at total LCP-tid bør deles opp med TTFB og ressursinnlastingstid som hver utgjør rundt 40 %, mens ressursinnlasting og forsinkelser i elementgjengivelse hver bør utgjøre mindre enn 10 %.
Ideelt sett bør disse to siste fasene være så nær null som mulig og prioriteres over de to andre.
Det finnes to måter å redusere forsinkelsen i ressursinnlastingen så nær null som mulig:
Vi sier dette med en gang, vi anbefaler at du konsulterer med webutvikleren din før du går i gang med disse rettelsene. Dette er en backend-operasjon og krever en erfaren hånd for å få det til å fungere som ønsket.
Ressursoppdagelse
Alle nettlesere leveres med en forhåndsinnlastingsskanner, hvis oppgave det er å hjelpe nettleserens primære HTML-parser med å oppdage sideinnhold.
Mens den primære HTML-parseren behandler rå markup til den møter en blokkerende ressurs – for eksempel et skript som ikke inneholder et async- eller defer- attributt, har forhåndsinnlastingsskanneren en mer spekulativ rolle.
Med andre ord, forhåndsinnlastingsskanneren ser etter ressurser å hente før den primære HTML-parseren når dem, og fortsetter å jobbe selv om parseren er blokkert. Forhåndsinnlastingsskanneren kan brukes til å finne og laste inn LCP-en så nær den første sideforespørselen som mulig.
For å sikre at LCP-ressursen kan oppdages fra HTML-kilden, har utviklere ressursspesifikke alternativer.
Hvis for eksempel LCP-en er et bilde, src- eller srcset -attributtene være tilstede i kildekoden. CSS-bakgrunnsbilder kan derimot forhåndsinnlastes ved å inkludere i HTML-markering eller i overskriften. Til slutt kan fonter lastes inn på samme måte via .
Det er imidlertid verdt å merke seg at bruk av forhåndslasting for å redusere lastetiden til LCP kan introdusere nye problemer, som å nedprioritere asynkrone elementer. Det er en grunn til at vi anbefaler å snakke med utvikleren din om dette.
Hvis du vil ha mer informasjon om dette emnet, kan du sjekke ut Googles dypdykk i både LCP-optimalisering og forhåndsinnlastingsskanneren .
Ressursprioritet
Nettlesere prøver å laste ned CSS-, font-, skript-, bilde- og iframe-ressurser så optimalt som mulig ved å prioritere dem. Nettlesere er utmerkede til å finne ut av prioriteringer av ressurser, men det betyr ikke at de er feilfrie.
For å optimalisere prioriteringen av ressurser kan utviklere bruke markupbaserte prioritetshint for å signalisere til nettlesere hvilke ressurser som har høyere prioritet. En utvikler kan for eksempel bruke JavaScript og Fetch API til å merke LCP-bildet med fetchpriority=”high” , noe som øker hastigheten på den bestemte CWV-metrikken.
Det er verdt å merke seg at Priority Hints bare fungerer på Chromium-baserte nettlesere , som Google Chrome og Microsoft Edge.
Utvikleren din har kanskje allerede implementert lazy loading for ressurser nedenfor brettet. Sjekk med dem for å være sikker, men det er også verdt å få dem til å bruke Priority Hints for ressurser over brettet.
Hvis du vil ha mer informasjon om prioritert lasting, anbefaler vi på det sterkeste å sjekke ut Googles veiledning for ressurslasting .
Søkegigantens utviklerteam kunne bruke Priority Hints til å forbedre LCP fra 2,6 sekunder til 1,9 sekunder i en test av Google Flights.
FID sporer hvor lang tid det tar for en brukers nettleser å begynne å behandle den første inndataen – unntatt rulling og zoom.
Dette målet handler om å fange opp brukerens opplevelse av å samhandle med en nettside, noe som betyr at trege nettsider vil score dårlig. Målet er å holde FID-poengsummen under 100 millisekunder.
Dårlig responsivitet skyldes vanligvis overdreven bruk av JavaScript, som nettlesere behandler før input.
Kode som bruker opp nettleserens fokus i 50 millisekunder eller mer kalles en lang oppgave og blir sett på som et tegn på JavaScript-oppblåsthet. Å dele opp disse lange oppgavene i mindre kodebiter kan løse treg ytelse og forbedre FID.
Men det er ikke det eneste området som er verdt å diskutere med utvikleren din. Det er viktig å diskutere hvordan både førsteparts- og tredjepartsskriptkjøring kan bremse nettstedet ditt. Progressiv lasting av kode og funksjoner kan bidra til å løse utfordringene med førstnevnte, mens lasting og lastprioritering på forespørsel kan hjelpe med sistnevnte.
Et annet alternativ ville være å bruke webarbeidere til å kjøre JavaScript i bakgrunnen og forhindre at nettleseren din setter seg fast i behandlingen av skript.
CLS er i bunn og grunn en måling av nettstedets visuelle stabilitet. Hvis de besøkende mister plassen sin på en side fordi innhold flyttes rundt for å gi plass til annonser og bilder, vil nettstedet ditt score dårlig.
Jo mindre sideoppsettet ditt spretter rundt, desto bedre blir CLS-poengsummen din. Google bedømmer nettsteder ved å vurdere forstyrrelsene i viewporten, samt hvor mye ressursene hoppet i forhold til den.
Å minimere uventede layoutendringer dreier seg i bunn og grunn om å avsette plass til annonser, bilder og innebygde videoer.
Husker du src- eller srcset- attributtene vi så på da vi snakket om ressursoppdagelse? Vel, dette er ganske sentralt for å forbedre CLS-poengsummene.
For statiske bilder, angi bredde og høyde ved hjelp av src -attributtene for å fortelle nettleseren at den skal reservere plass til ressurser som laster saktere, og dermed unngå layoutendringer.
Se eksempelkoden fra Google nedenfor:
Responsive bilder krever et srcset for å definere maksimale bredde- og høydegrenser nettleseren kan velge. Sørg for at du bruker bilder med samme sideforhold.
Her er et annet eksempel:
Når du håndterer annonser, er det noen få trinn du kan ta:
Det anbefales også å reservere statisk plass hvis du har tenkt å implementere iFrames, innebygd innhold og dynamisk innhold, for eksempel handlingsfremmende oppfordringer (CTA-er).
Når nettlesere laster ned og gjengir webfonter, er det en mulighet for at det enten oppstår et glimt av ustilisert tekst (FOUT) eller et glimt av usynlig tekst (FOIT). Førstnevnte skjer når en reservefont byttes ut med en ny font, mens sistnevnte er et resultat av en forsinkelse i gjengivelsen av en ny font.
Du kan løse begge problemene ved å bruke for å be forhåndsinnlastingsskanneren om å hente nettfontene raskere. Forhåndsinnlastede fonter har større sjanse for å møte den første malingen.
Det finnes andre løsninger i Googles feilsøkingsveiledning for CLS , i tillegg til dyptgående informasjon om bruk av forhåndsinnlasting for å forhindre FOIT .
Hvis du ønsker forbedringer av nettstedshastigheten og fortsatt bruker et tradisjonelt alternativ for hosting med én server, er det sannsynligvis på tide å vurdere å bytte til et innholdsleveringsnettverk (CDN).
Et CDN består av et nettverk av servere plassert på forskjellige datasentre rundt om i verden som distribuerer nettstedsinnhold for å forbedre ytelsen. Selv om både et enkelt serveralternativ – også kjent som lokal hosting – og CDN leverer nettstedsinnhold til besøkende, er det bare et CDN som kan ta hensyn til brukerens geografiske plassering og deretter velge den nærmeste serveren for å redusere lastetidene.
Geografi er imidlertid ikke den eneste fordelen, ettersom CDN-er også er bedre rustet til å håndtere plutselige trafikktopper samt rotserverressurser som båndbredde.
Til syvende og sist sender en raskere nettleseropplevelse et sterkt CWV-signal til Google. Selv om Cloudflare er en av de mest kjente CDN-leverandørene på markedet, finnes det en rekke seriøse konkurrenter å vurdere .
Uansett hvilken hostingleverandør du bruker, vil serverne deres være bundet av visse maskinvarebegrensninger.
Servere inneholder i stor grad de samme nøkkelkomponentene som gjør at den bærbare/stasjonære datamaskinen din kan fungere – nemlig en CPU og RAM – som håndterer alle oppgavene på kontoen din. Du bør kunne bruke hostingleverandørens dashbord til å sjekke CPU-en og RAM-en som er installert på serveren din, og til og med kunne be om ekstra ressurser for å forbedre nettstedets ytelse.
Hvis du ser på serverens CPU, er det viktig å forstå at bare én enkelt kjerne brukes til å oppfylle en besøkendes forespørsel om en nettside. Dette betyr at raskere klokkehastigheter for én kjerne alltid er nødvendig. CPUer med flere kjerner kan behandle flere sidevisninger og andre servertjenester.
Dette er enda en for utvikleren din.
Gå gjennom databasen din med jevne mellomrom for å sikre at den ikke har blitt overfylt med ubrukte bilder og filer. Sletting av unødvendige filer vil rydde opp i den, noe som øker den gjennomsnittlige sideinnlastingstiden.
Bruk av veldig store bilder kan og vil gjøre nettstedet ditt tregere. Hvor stort? Alt over 1 MB er rett og slett for stort.
Og som vi allerede vet, vil langsommere lastetider føre til høyere avvisningsfrekvenser og sende uønskede signaler til Google.
For de som bruker WordPress finnes det en rekke programtillegg for bildeoptimalisering å velge mellom som kan effektivisere en ellers kjedelig manuell oppgave. Dessuten kommer mange også med andre funksjoner som lazy loading og automatisk endring av størrelse.
Hvorvidt et nettsted er mobilvennlig eller ikke, avhenger av om du har forenklet og strømlinjeformet nettstedet ditt for den mobile nettleseropplevelsen.
Mobilbrukere samhandler med sider annerledes og har mye mindre tålmodighet med trege lastetider og nettsteder som er vanskelige å navigere i. Hvis nettstedet ditt ikke har bestått mobilvennlighetstesten beskrevet ovenfor, eller om det har bestått, men du er interessert i ytterligere optimalisering, la oss gå gjennom noen av de beste fremgangsmåtene.
Dette burde være enhver utgivers primære bekymring. En enkel måte å forbedre brukervennligheten på er å stille deg selv spørsmål som:
Disse svarene vil bidra mye til å identifisere brukerens smertepunkter. For eksempel vil du ikke at brukerne dine skal justere skjermene sine for å se innholdet ditt. Du kan se hva vi mener i eksemplet nedenfor.
For å optimalisere innholdet ditt for mobile enheter, finnes det tre utviklingsalternativer:
Vi har sortert dem etter hvor enkle de er å implementere, og vi anbefaler å bruke et responsivt design, ettersom det er det minst krevende av de tre alternativene.
Utviklere legger ganske enkelt til meta-taggen name="viewport" i den eksisterende koden til en nettside
Fordelen her er at du bare trenger å vedlikeholde ett nettsted, som enkelt kan vises på alle skjermtyper.
Dynamiske design fungerer derimot ved å servere ulik HTML-kode basert på brukerens enhet. Sider må bruke Vary HTTP-headeren for å forhindre at feil kode serveres til feil enhet.
Til slutt finnes det mobile underdomener, som vi ikke anbefaler gitt mengden ressurser som kreves for å implementere effektivt. Mobile underdomener er helt separate nettsteder som har separate hostingbehov. For å sikre at robotsøkeprogrammer forstår forholdet mellom domene og underdomene, må du inkludere rel="canonical" -taggen.
Fordi responsiv design er det enkleste alternativet, er det det vi anbefaler for utgivere. For en nærmere titt på responsiv design, sjekk ut Googles implementeringsveiledning .
Her er en rask liste over tekniske hensyn å ta for ethvert design:
Dette siste trinnet er den enkleste måten å forbedre sideopplevelsen på, men det bidrar også mye til å forbedre brukerens trygghet.
Å bytte til HTTPS beskytter og krypterer brukerens informasjon, og det bidrar også til å forhindre Man-in-the-Middle-angrep (MitM). I tillegg til dette eliminerer et SSL-sertifikat nettleseradvarsler om manglende sikkerhet.
Hostingleverandøren din burde virkelig kunne tilby deg HTTPS-sikkerhet. Hvis ikke, kan det være verdt å vurdere å bytte til en som gjør det. Det finnes allerede flere kjente hostingleverandører som tilbyr HTTPS gratis . Dessuten bruker de hostingleverandørene som tilbyr SSL-sertifikater sin egen tjeneste i stedet for den eksterne, noe som gjør prosessen enda enklere og raskere å implementere.
Hvis du vil be om og installere et SSL-sertifikat fra sertifiseringsinstanser (CA-er), er det fire trinn du må følge. Disse er:
Det er viktig å sørge for at når du migrerer nettstedet ditt til HTTPS, at det ikke påvirker strategien din for annonseinntekter. Problemet er at en HTTPvil ikke fungere på et nettsted som bruker HTTPS.
Vi anbefaler at du konsulterer med annonseteknologipartnerne dine før du gjør noen endringer på nettstedet ditt.
For mer informasjon, se Googles omfattende guide om emnet.
Påtrengende mellomliggende annonser og dialogbokser gjør det vanskelig for søkemotorer å forstå innholdet på en nettside, noe som kan undergrave SERP-ytelsen.
Det hadde vært flott om det fantes en måte å lage mellomliggende annonser på som ikke forstyrret brukeropplevelsen, men det er jo hele poenget med slike annonser. De tar over hele skjermen i pauser i innholdet for å fange brukerens oppmerksomhet.
Derfor ville utgivere være bedre tjent med å bruke bannerannonser i stedet for mellomliggende annonser, ettersom de bare tar opp en liten del av skjermplassen. Det er bedre å risikere bannerblindhet enn brukerfrustrasjon.
Utgivere kan bruke nettleserstøttede bannere eller enkle HTML-bannere som lenker til destinasjonssiden til handlingsfremmende oppfordringer.
Dialogbokser kan også brukes til reklamekampanjer, men disse kan utformes slik at de ikke forstyrrer. Du må sørge for at brukerne har tilgang til innhold uten avbrudd.
Det finnes ingen snarveier for å optimalisere sideopplevelsen, og det er viktig at du fikser punktene ovenfor. Når det er sagt, er det verdt å påpeke at selv om WordPress er den lett mest populære publiseringsplattformen i verden, betyr ikke dette nødvendigvis at det er det beste CMS-et når det gjelder å forbedre CWV-ytelsen.
En titt på CWVs teknologirapport viser at bare rundt 29 % av WordPress-nettsteder har gode CWV-er, mens 41 % av Wix-nettsteder får det grønne haket.
Det er verdt å vurdere om det å bytte til et spesialisert CMS kan forbedre CWV-ene dine direkte.
Det er mye å gjøre når det gjelder å optimalisere sideopplevelsen, og det kan være litt skremmende å komme i gang. Det er imidlertid viktig å huske at du spiser elefanten ved å ta én bit av gangen.
Det er ikke nødvendig å sikte mot en «god» poengsum på tvers av alle CWV-målingene dine for å hjelpe nettstedet ditt med å klatre i SERP-ene. Mer enn det, men det kan være kontraproduktivt å sette seg så høye mål, da det kan være en demoraliserende jakt.
Sikt heller på små seire når det gjelder dine CWV-er, fokuser på å adressere «dårlige» resultater uten å bekymre deg for mye om «trenger forbedring»-linjen. Det kan komme senere, når du har mer tid og ressurser å bruke på prosessen.
Vi har allerede snakket om Yahoo! Japans forbedrede CLS-poengsum. La oss se på et par andre nettsteder vi kan lære noe av.
Den indiske avisen The Economic Times, som betjener mer enn 45 millioner månedlige aktive brukere, reduserte CLS-poengsummen sin med 250 % fra 0,25 til 0,09 og LCP-tiden med 80 % fra 4,5 sekunder til 2,5 sekunder.
Mellom oktober 2020 og juli 2021 reduserte utgiveren LCP-poengsummene i «Dårlig»-området med 33 %, mens CLS-verdiene i «Dårlig»-området falt med 65 %. Disse forbedringene gjorde at The Economic Times klarte å passere CWV-terskler på tvers av hele opprinnelsesområdet, samtidig som de totale avvisningsfrekvensene ble redusert med 43 %.
Utgiveren oppnådde dette på flere måter, der den første var å prioritere nedlastingsprioriteter for ressurser ved hjelp av prioritetshint. De tok også tak i lange oppgaver, og delte opp kodebiter for å sikre at ressurser som er kritiske for gjengivelse av sider over brettet, ble lastet inn først.
Det britiske nyhetsnettstedet forbedret CLS-poengsummen sin fra 0,25 til 0,1 , samtidig som antallet URL-er som fikk bestått karakter økte fra 57 % til 72 %.
The Telegraph brukte Chrome DevTools til å identifisere individuelle forekomster av skiftende layout.
Før den tid brukte jeg WebPageTest for å finne hvor i tidslinjen layoutendringen skjedde.
Med disse dataene for hånden begynte teamet å fokusere på å redusere layoutendringer ved å takle disse områdene
For annonser begynte The Telegraphed å reservere plass til dem og brukte den vanligste annonsestørrelsen for å spesifisere dimensjoner. Dette bidro også til å forhindre at annonser kollapset når de ble vist på et nettbrett.
Teamet tok tak i et lignende problem med innebygde bilder øverst i artiklene, som ikke hadde spesifiserte dimensjoner.
Telegraph gjorde andre justeringer, som å flytte overskriften til toppen av markeringen og bruke plassholdere for innebygde videoer, men beskrev til slutt prosessen som «ganske enkel» samtidig som den fortsatt hadde en betydelig innvirkning.
Det trenger ikke å være overveldende å forbedre sideopplevelsen. Vurder de fire grunnpilarene for sideopplevelse, og bestem deg deretter for hvilke ressurser du kan bruke på å forbedre resultatene dine.
Hvis du er et mindre forlag, vil ressursbalanse være avgjørende, og vi anbefaler å identifisere rimelig lavthengende frukter for ditt første prosjekt.
Når man ser på Telegraphs tilnærming, fokuserte de på ett aspekt av CWV-ene i stedet for alle tre, og gjorde betydelige forbedringer. Economic Times fokuserte på to av de tre og leverte noen imponerende resultater.
