Utgiverveksttaktikker for valgsesongen | WEBINAR
Utgiverveksttaktikker for valgsesongen | WEBINAR
På slutten av denne modulen bør du ha en klar forståelse av de ulike komponentene som bidrar til Page Experience, hvorfor de er viktige og hvordan hver enkelt kan optimaliseres for å forbedre både nettstedets brukeropplevelse og SEO.
Videovarighet
17:09
Svar Quiz
Ta gjeldende modulquiz
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), mobilvennlighet, HTTPS og påtrengende interstitial retningslinjer – som Google bruker for å ekstrapolere brukeropplevelsen på et nettsted.
Sideopplevelse er en evaluering av et nettsteds ytelse i stedet for innholdet. Mens Google fortsatt prioriterer innholdsrelevans når de svarer på brukerforespørsler, er sideopplevelsen i praksis en uavgjort når flere nettsteder tilbyr et tilsvarende nivå av dekning.
De fire sideopplevelsessignalene er:
CWV-er måler brukeropplevelsen ved å fokusere på hvor raskt en side lastes, dens respons på brukerinndata og også dens visuelle stabilitet. Det er tre beregninger for dette:
Googles oppdatering i april 2015 introduserte søkegigantens mobilvennlige beregning, som øker rangeringen av mobilvennlige sider på mobile SERP-er.
Effektivt vil Google prioritere de nettstedene som sikrer at innholdet deres lett kan leses på mobile enheter - noe som betyr at det ikke er behov for å zoome, berøre mål som påloggingsknapper ikke er avstand for nær hverandre, det er ingen horisontal rulling og uspillbart innhold unngås.
Oppdateringen gjelder individuelle sider, ikke hele nettsteder, og påvirker heller ikke innhold som blir sett på desktop/bærbare nettlesere.
HTTPS, eller Hypertext Transfer Protocol Secure, er en sikker versjon av HTTP Internet Communication Protocol.
HTTPS, eller HTTP, utgjør den første delen av hver URL som er kjent som "ordningen". Dette kommer foran domenenavnet, som er segmentet av URL -en kjent som "autoriteten".
Forskjellen mellom HTTPS og HTTP er at førstnevnte er sikker mens sistnevnte ikke er det. Hva dette betyr i praksis er at brukere som logger seg på et nettsted via en HTTP -tilkobling, sender sine personlige detaljer i ukryptert ren tekst.
HTTPS sikrer denne tilkoblingen, noe som betyr at data som er sendt mellom brukerens nettleser og nettstedets server er kryptert underveis. Nettsteder som ønsker sikre tilkoblinger trenger et SSL -sertifikat, som brukerens nettleser sjekker og verifiserer.
Interstitials er et mobil bare annonseformat som bare vises i naturlige pauser i innholdet - for eksempel når en bruker flytter fra en artikkel til den neste - som dekker skjermen i prosessen.
Interstitials blir sett på som påtrengende når de blokkerer eller delvis skjuver et brukernes syn på innholdet. Dialogbokser på mobile nettsteder som oppfører seg på samme måte faller også under denne kategorien.
De fleste forlagers sterkeste ferdighetssett har en tendens til å være innholdsoppretting, publisering og markedsføring, og etterlater lite rom for både å forstå og optimalisere de forskjellige sideopplevelsessøylene.
Endelige ressurser betyr at utgivere vil kjempe for å rettferdiggjøre tiden og pengene som trengs for å grave i backend på individuelle websider, enn si et helt nettsted.
Selv om utgivere er i stand til å bruke tid på å takle problemet, som vi kan se ovenfra, er sideopplevelse et mangefasettert problem som krever en helhetlig tilnærming for å levere meningsfulle ytelsesgevinster.
Å vite hvilke av de fire siders opplevelsessignalene som skal begynne å jobbe med, kan være hodepine i seg selv.
Sideopplevelse er utrolig viktig for utgiveren SEO, da flott innhold ikke er nok til å garantere toppplassering i SERP -ene.
Google verdsetter fortsatt den beste informasjonen før noe annet, noe som betyr at unikt innhold eller nyheter "Scoops" vil fungere bra selv om sideopplevelsen er "subpar" . I tilfeller der flere utgivere gir utmerket aktuell dekning, blir imidlertid sideopplevelsen en viktig avgjørende faktor som påvirker SERP -rangeringer.
Hver av de fire siders opplevelsessøylene har en annen innvirkning på nettstedets SEO. Den mest umiddelbare virkningen kommer fra å fokusere på CWV -er, som vil oversette til et nettsted som laster raskere.
Tallrike studier har vist at jo lengre et nettsted tar å laste, jo raskere mister publikum interessen og jo høyere blir avvisningsraten.
For eksempel fant en Google -studie fra 2018 at avvisningssannsynligheten hoppet 32% da sidelasttider klatret fra 1 sekund til 3 sekunder.
En annen Google -studie fra 2020 fant at nyhetssider som besto CWV -testen, så en 22% lavere forlatelsesrate enn de som mislyktes. Yahoo! Japan forbedret i mellomtiden sin CLS -poengsum med 0,2 og så en 15,1% uptick i sidevisninger per økt og en økning på 13,3% i øktvarigheten.
Selv om Google har sagt eksplisitt at den ikke bruker avvisningsrater som et rangeringssignal , taler en høy avvisningshastighet til faktorer Google bryr seg om - nemlig en sides lasthastighet, respons og visuell stabilitet.
Utgivere som er rettet mot publikum på mobile enheter, må sikre at nettstedet deres sender mobilvennlige signaler som både Google og Bing kan hente seg. Begge søkemotorene vil prioritere vennlige nettsteder når de leverer søkeresultater til mobilbrukere.
Sammenlignet med CWV -er og mobil vennlighet, vil implementering av HTTPS ha mye mindre innvirkning på en utgivers SEO. Google sa i 2014 at det ville bruke det som et rangeringssignal og begynte å markere alle HTTP -nettsteder som "ikke sikker" i Chrome i 2018. Imidlertid er den største fordelen her forbedret datasikkerhet, spesielt hvis forretningsmodulen din er basert på abonnementsinntekter.
Påtrengende interstitielle annonser eller dialogbokser kan i mellomtiden begrense webcrawlers evne til å krype og indeksere en side, og forhindre at søkemotorer til og med kan rangere den, la være alene med høyt i søkeresultatene ..
Det første trinnet mot å forbedre sideopplevelsen begynner med å evaluere nettstedets nåværende effektivitet.
Det er et bredt utvalg av første- og tredjepartsverktøy for å oppnå dette, men for denne guiden vil 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 parametrene som optimale CWV -tall skal falle for den beste sideopplevelsen.
Nå som vi vet hva vi trenger å måle og etter hvor mye, kan vi se på hvordan vi kan gå ut på å måle sideopplevelse.
Nedenfor er en liste over noen av de mest brukte metodene.
Det første alternativet som er åpent for utgivere er den desidert mest teknisk utfordrende, og er ikke et vi vil anbefale selv med tanke på med mindre du har en god utvikler for å hjelpe til med implementeringen.
Vi snakker om å samle brukerdata fra nettstedet ditt, en prosess kjent som Real User Monitoring (RUM), og deretter analysere resultatene innen Google Analytics 4 (GA4). Google har andre verktøy, for eksempel PageSpeed Insights (PSI), som bruker dataprøvetaking for å evaluere nettstedet ditt. Men hvis målet er å ha et komplett brukeropplevelsesbilde for nettstedet ditt, trenger du data fra den virkelige verden som er samlet inn fra nettstedet ditt.
Vi anbefaler å bruke GA4 for denne oppgaven av den enkle grunnen at Google har til hensikt å begynne å "solnedme" den forrige generasjonen Google Analytics, Universal Analytics (UA), fra midten av 2023.
Som utgiver burde du allerede ha satt opp en GA4 -konto i påvente av overgangen. Hvis du ikke har det, så følg Googles guider om hvordan du enten kan sette den opp for første gang eller hvordan du legger det til på et nettsted som allerede har UA .
Når det er gjort, er neste trinn å koble Googles BigQuery Data Warehouse til GA4 fra Analytics Admin. Kobling av BigQuery lar deg spørre dataene dine ved hjelp av SQL. Her er en guide for hvordan du kobler de to .
Med disse trinnene ut av måten vi nå kan legge til Googles Web-Vitals-bibliotek på nettstedet ditt.
Biblioteket, som er et ekstremt lite modulært JavaScript -bibliotek for datainnsamling, er tilgjengelig på Github.
Biblioteket kan installeres enten fra Open Source NPM Online Repository ved å kjøre "NPM Install Web-Vitals" i kommandoteterminalen eller via<script> tags on a content distribution network (CDN).
Her er et eksempel på et slikt manus:
Når Web-Vitals-biblioteket er installert, kan brukerdata deretter sendes til Google Tag Manager (GTM), ved hjelp av en Google-anbefalt tilpasset mal-tag som Simo Ahava opprettet og vedlikeholder.
Når taggen er installert, kan CWV -beregningene og tilhørende attribusjonsdata deretter videresende dem til GA4.
Når du har satt opp analyser for å spore GTM -dataene, vil du kunne se hendelsesdata i BigQuery -grensesnittet. Disse dataene kan deretter spørres slik:
Når spørringen er returnert, skal rapporten se slik ut:
Vi må virkelig understreke igjen at dette er en utviklerløsning og faktisk er mye mer komplisert enn dette. Å ta i bruk denne løsningen vil imidlertid gi deg den mest nøyaktige lesningen på nettstedets ytelse.
For en mer detaljert forklaring av denne prosessen, sjekk ut Googles guide til å se CWV -er i GA4 .
Selv om dette er den mest nøyaktige tilnærmingen til å overvåke CWV -er, er det enklere tilnærminger for å takle 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 det bare kan bruke prøver av ekte brukeropplevelser hentet fra Chrome User Experience Report (CRUX) i løpet av forrige 28-dagers periode, gir PSI et enkelt og lett forståelig brukergrensesnitt . Dette betyr å tolke dataene er en mye enklere prosess.
Som du kan se i vårt eksempel nedenfor, gir undersøkelsen Forbes 'nettsted umiddelbart et vell av informasjon i både utgiverens desktop og mobilnettsted.
PSI bruker de grønne, ravlige og røde kategoriene ovenfra når du tildeler god, må forbedring og dårlige ytelseskarakterer.
Cruxs prøvetakingsmetode betyr at selv om vurderingen av Forbes ovenfor tok inn noen brukeropplevelser i den virkelige verden, kan det ikke ta hensyn til alle nettstedets brukerdata.
Denne prøvetakingsmetoden blir problematisk for mindre steder, hvorav mange ikke vil inneholde Crux feltdata.
Imidlertid kan PSI fremdeles tilby en virtuell diagnose av nettstedet ditt ved hjelp av laboratoriedata trukket fra Googles Open Source Lighthouse Tool . Se eksemplet nedenfor:
Problemet med denne tilnærmingen er at Lighthouse samler inn dataene ved å bruke forhåndsbestemte enheter og nettverksinnstillinger, som ikke vil gjenspeile brukernes innstillinger. Dette betyr at det er en dårlig erstatning for den virkelige tingen.
GSC er et verktøy som er designet for å gi utgivere et fugleperspektiv av nettstedets CWV-problemer, og åpner døren for en helhetlig tilnærming til å forbedre nettstedets ytelse.
Det gjør dette ved å gruppere URL -ytelsesrapportene basert på status, metrisk type eller aktuell likhet. Den identifiserer ikke problemer med enkeltsider, og nekter muligheten til å implementere rettelser på et granulært nivå.
Det er her PSI kommer inn. Det er imidlertid verdt å merke seg at PSIs individuelle siderapport kan avvike markant fra GSCs gruppesultater. Det er fordi den enkelte side bare er en komponent i GSCs samlede gruppesultater.
Logger på GSCs dashbord, vil brukere se kategorien Core Web Vitals på venstre side. Klikk på denne fanen viser separate mobile og stasjonære CWV -rapporter for URL -grupper.
Til tross for at det er tre CWV -beregninger - LCP, FID og CLS - vil URL -er motta en samlet karakter basert på deres dårligst presterende beregning for en spesifikk enhet som også vil påvirke grupprapportene.
For eksempel, hvis en URL på mobil mottar en dårlig FID og en god LCP, vil den bli merket som dårlig på mobil.
Igjen er det viktig å merke seg at GSC ikke er ment for granulære fikser. Imidlertid er det flott for utgivere som har mange lignende sider. For eksempel kan nyhetssider ha en relativt standard design og layout for artikkelsider som bruker et bilde som det største elementet over folden. I dette tilfellet kan GSC raskt bidra til å identifisere LCP -problemer på tvers av en rekke URL -er.
Det endelige verktøyet i Google Performance Measuring Toolkit er fyrtårn . Dette verktøyet er helt annerledes enn de som kom før ved at det emulerer brukerytelsen basert på et etablert sett med parametere.
Den bruker ikke feltdata og er så mer begrenset når det gjelder praktisk bruk. For eksempel påvirkes feltdata av en brukers nettverkstilkobling og deres avstand til nettstedets servere, mens fyrtårn emulerer en mellomklasse enhet for å samle inn data i et kontrollert miljø.
Det er også viktig å forstå at Lighthouses poengsum ikke bare er en sammenslåing av CWV -score. Det ekskluderer FID, siden labdata etter sin natur utelukker sluttbrukerinteraksjoner, mens du legger til total blokkeringstid (TBT), Speed Index (SI) og Time to Interactive (TTI) metrics i blandingen. For de som ønsker å simulere en FID -opplevelse i laboratoriet, kan TBT brukes som fullmakt.
Vi vil imidlertid anbefale mot å bruke Lighthouse som en primær måleressurs. Snarere bør det brukes som et ledsagerverktøy sammen med PSI for å hjelpe til med å feilsøke spesifikke sidespørsmål.
Utgivere som ønsker å bruke fyrtårn i testingen, kan gjøre det via Chrome Devtools som er bakt direkte i Chrome -nettleseren, en utvidelse for nevnte nettleser eller på web.dev/Measure .
Lighthouse vil revidere hjemmesiden din og gi score av 100 på fire områder:
Slik ser det ut når vi legger hjemmesiden vår gjennom alternativet Web.Dev.
Mobil webdesign skiller seg fra tradisjonell stasjonær webdesign i at mobile enheter har mindre skjermer, har generelt sport mindre kraftig maskinvare og stoler utelukkende på berøringsinnganger.
Mobilvennlige nettsteder prioriterer brukeropplevelse ved å følge et sett med beste praksis som vi skal utforske litt senere. Foreløpig den beste måten å sjekke om sidene dine er mobilvennlige er med Googles mobilvennlige test .
Å legge inn en URL for en mobilvennlig webside returnerer følgende resultat:
Sider som mislykkes denne testen vil dukke opp med en rekke fikseringsalternativer å forfølge. Vi kommer inn på dem litt senere.
Å sjekke om nettstedet ditt har en sikker tilkobling er en ekstremt enkel prosess, som involverer nettleseren og ser på symbolet til venstre for nettadressen i adressefeltet.
I krom vil en sikker tilkobling bli betegnet via et lukket hengelås -symbol som dette:
En usikker tilkobling vil ha et infosymbol som det:
Å bestemme om dine mellomliggende annonser er påtrengende eller ikke er ikke så enkelt som å legge inn nettstedet ditt i et online verktøy og vente på at det skal returnere en hake eller ikke.
Det krever å studere interstitielle annonser og dialogbokser på nettstedet ditt og avgjøre om de passerer visse parametere.
Tenk på disse parametrene 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 et godt grep om de forskjellige komponentene i de fire komponentene som teller mot sideopplevelse, så vel som midler til å overvåke ytelsen, la oss gå videre til å utforske hvordan vi kan øke nettstedets rangeringssignaler nøyaktig
Vi skal se på CWV -er først, ettersom feilsøking og optimalisering av LCP, CLS og FID vil ha størst innvirkning på din evne til å konkurrere om toppplasser i sterkt omstridte SERP -rangeringer.
Selv om mobil vennlighet er utrolig viktig for nettsteder som er rettet mot mobilbrukere, vil forbedring av CWV -er øke sideytelsen for nettsteder uavhengig av om de er vist på mobile enheter eller skrivebord.
Å takle HTTP -er og påtrengende interstitials har blitt overlatt til slutten, da de er enklere og mindre givende gevinster.
Det er en rekke alternativer når det gjelder å forbedre CWV -ytelsen, som vi har brutt ned i rekkefølge av viktigheten vi tror de fortjener.
Optimalisering av kjernen Web Vitals på enhver side er et spekter av handlinger, og det er viktig å vite hvor du skal begynne å maksimere ressursene dine.
Som vi allerede har nevnt ovenfor, måler den største innholdende malingen (LCP) hvor lang tid det tar å laste den største teksten eller bildeverdien som er synlig over brettet.
Bruk PSI for å identifisere hvilket sideinnhold som utløser LCP -testen, ved å gå til rapportens diagnoseseksjon og klikke på “Største innholdende malingselement”. Her er hva vi så fra på SODPs hjemmeside:
En dårlig LCP-poengsum kan vanligvis bli innsnevret til enten sakte server-responstider, gjengivelse av JavaScript og CSS, ressursbelastningstider eller klientsiden-gjengivelse, eller til og med en kombinasjon av alle fire.
Optimalisering av siden din innebærer faktisk å optimalisere fire forskjellige underdeler av LCP -belastningsprosessen:
Alle disse trinnene må optimaliseres for deg å se en forbedring i LCP -poengsummen din. Det betyr imidlertid ikke at alle underdelene er like viktige.
Google har antydet at total LCP -tid skal brytes ned med TTFB og ressursbelastningstid hver utgjør rundt 40% mens ressursbelastning og element gir forsinkelser for hver utgjør mindre enn 10%.
Ideelt sett bør disse to siste være så nær null som mulig og prioritere de to andre fasene.
Det er to måter å hjelpe til med å redusere ressursbelastningsforsinkelsen så nær null som mulig:
Vi vil si dette med en gang, vi anbefaler å konsultere med nettutvikleren din før du dykker ned i disse rettelsene. Dette er en backend -operasjon og krever en erfaren hånd for å få den til å fungere som ønsket.
Ressursoppdagelse
Hver nettleser kommer med en forhåndsskanner, hvis jobb det er å hjelpe nettleserens primære HTML -parser i å oppdage sideinnhold.
Mens den primære HTML -parseren behandler rå markering til den går inn i en blokkeringsressurs - for eksempel et skript som ikke inneholder en async- eller utsettingsattributt , opptar forhåndsskanneren en mer spekulativ rolle.
Med andre ord, forhåndsskanneren leter etter ressurser å hente før den primære HTML -parseren når dem og fortsetter å jobbe selv om analyseren er blokkert. Forhåndsbelastningsskanneren kan brukes til å finne og laste inn LCP så nær den første sidenforespørselen som mulig.
For å sikre at LCP -ressursen kan oppdages fra HTML -kilden, har utviklere eiendeler spesifikke alternativer.
For eksempel, hvis LCP er et bilde, SRC- eller SRCSET -attributtene være til stede i kildekoden. CSS bakgrunnsbilder kan i mellomtiden forhåndsinnlastes ved å inkludere i HTML -markering eller i overskriften. Endelig kan skrifter lastes på lignende måte via .
Det er imidlertid verdt å merke seg at bruk av forhåndsbelastning for å kutte ned på LCP -belastningstider kan introdusere nye problemer i blandingen, for eksempel å deprioritere asyncelementer . Det er en grunn til at vi tar til orde for å snakke med utvikleren din om dette.
For mer informasjon om dette emnet, sjekk ut Googles dype dykk i både LCP -optimalisering og forhåndsinnlastingsskanneren .
Ressursprioritet
Nettlesere prøver å laste ned CSS, font, skript, image og iframe så optimalt som mulig ved å tildele prioritet. Nettlesere er utmerkede til å finne ut av eiendelsprioriteringer, men det betyr ikke at de er feilfrie.
For å optimalisere eiendelsprioritering, kan utviklere bruke markeringsbaserte prioriterte hint for å signalisere til nettlesere hvilke eiendeler som har høyere prioritet. For eksempel kan en utvikler bruke JavaScript og Fetch API for å merke LCP -bildet med Fetchpriority = ”High” HTML -attributtet, og fremskynder den bestemte CWV -metrikken.
Det er verdt å merke seg at prioriterte antydninger bare fungerer på krombaserte nettlesere , for eksempel Google Chrome og Microsoft Edge.
Utvikleren din kan allerede ha implementert lat belastning for under foldemidlene, sjekk med dem for å være sikker, men det er også verdt å få dem til å bruke prioriterte hint for eiendeler over folden.
For mer informasjon om prioritert lasting, anbefaler vi på det sterkeste å sjekke ut Googles guide til ressursbelastning .
Søkegigantens Dev -team var i stand til å bruke prioriterte hint for å forbedre LCP fra 2,6 sekunder til 1,9 sekunder i en test av Google -flyreiser.
FID sporer hvor lang tid en brukers nettleser tar for å begynne å behandle den første inngangen - unntatt rulling og zoom.
Dette tiltaket handler om å fange brukerens opplevelse av å samhandle med en webside, noe som betyr at trege websider vil score dårlig. Å holde den FID -poengsummen under 100 millisekunder er målet.
Dårlig respons kommer generelt ned på en overdreven bruk av JavaScript, som nettlesere vil behandle foran innganger.
Kode som forbruker en nettlesers fokus for 50 millisekunder eller mer, kalles en lang oppgave og blir sett på som et tegn på JavaScript oppblåsthet. Å bryte opp disse lange oppgavene i mindre biter av kode kan adressere 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 utførelse av førstepart og tredjepart kan redusere nettstedet ditt. Progressiv lasting av kode og funksjoner kan bidra til å takle utfordringene fra førstnevnte, mens lasting og lasting av lasting og lasting kan hjelpe med sistnevnte.
Et annet alternativ vil være å bruke nettarbeidere til å kjøre JavaScript i bakgrunnen og forhindre at nettleseren din blir fastsatt behandlingsskript.
CLS er i utgangspunktet en måling av nettstedets visuelle stabilitet. Hvis de besøkende mister sin plass på en side takket være at innholdet blir flyttet rundt for å gjøre plass for annonser og bilder å laste inn, vil nettstedet ditt score dårlig.
Jo mindre sideoppsettet spretter rundt, jo bedre er CLS -poengsummen din. Google Dommers nettsteder ved å vurdere forstyrrelsen i Viewport, så vel som hvor langt eiendeler hoppet i forhold til det.
Å minimere uventede layoutskift dreier seg i utgangspunktet om å betegne plass for annonser, bilder og innebygde videoer.
Husker du SRC- eller SRCSET -attributtene vi så på når vi snakket om ressursoppdagelse? Vel, dette er ganske sentralt for å forbedre CLS -score.
For statiske bilder, sett bredden og høyden ved hjelp av SRC -attributtene for å fortelle nettleseren om å reservere plass for langsommere lastemidler, og dermed unngå layoutskift.
Se eksempelkoden fra Google nedenfor:
Responsive bilder krever et SRCSet for å definere maksimal bredde og høydegrenser nettleseren kan velge. Forsikre deg om at du bruker bilder med samme sideforhold.
Her er et annet eksempel:
Når du arbeider med annonser er det noen få skritt du kan ta:
Reservering av statisk plass anbefales også hvis du har tenkt å implementere iframes, innebygd innhold og dynamisk innhold, for eksempel oppfordring til handling (CTAs).
Når nettlesere laster ned og gjengir nettfonter, er det en sjanse for enten et blitz av ustylet tekst (FOUT) eller et blitz av usynlig tekst (FOIT) som oppstår. Førstnevnte skjer som en tilbakeslagsfont blir byttet med en ny skrift, mens sistnevnte er resultatet av en forsinkelse i en ny skrift som blir gjengitt.
Du kan løse begge problemene ved å bruke For å fortelle forhåndsskanneren om å ta tak i nettfontene før. Forhåndsinnlastede skrifter har større sjanse for å møte den første malingen.
Det er andre løsninger i Googles CLS -feilsøkingsguide, så vel som det dype dykket til å bruke forhåndsinnlasting for å forhindre FOIT .
Hvis du leter etter forbedring av nettstedets hastighet og fremdeles bruker et tradisjonelt alternativ for en-server, er det sannsynligvis på tide å vurdere å bytte til et innholdsleveringsnettverk (CDN).
En CDN består av et nettverk av servere lokalisert ved forskjellige datasentre over hele verden som distribuerer nettstedinnhold for å forbedre ytelsen. Mens både et enkelt serveralternativ - også kjent som lokal hosting - og CDN leverer nettstedinnhold til besøkende, kan bare en CDN faktorere brukerens geografiske beliggenhet og deretter velge den nærmeste serveren for å redusere belastningstidene.
Geografi er imidlertid ikke den eneste fordelen, ettersom CDN -er også er bedre rustet til å administrere plutselige trafikkpigger, så vel som rotserverressurser som båndbredde.
Til syvende og sist sender en raskere nettleseropplevelse et sterkt CWV -signal til Google. Mens Cloudflare er en av de mest kjente CDN -leverandørene på markedet, er det en rekke seriøse konkurrenter å vurdere .
Uansett hvilken hosting -leverandør du bruker, vil serverne deres være bundet av visse maskinvarebegrensninger.
Servere inneholder i stor grad de samme nøkkelkomponentene som lar den bærbare/skrivebordet fungere - nemlig en CPU og RAM - som håndterer alle kontooppgavene dine. Du bør kunne bruke vertsleverandørens dashbord for å sjekke CPU og RAM som er installert på serveren din og til og med kunne be om flere ressurser for å øke nettstedets ytelse.
Hvis du ser på serverens CPU, er det viktig å forstå at bare en enkelt kjerne brukes til å oppfylle en besøkendes forespørsel om en webside. Dette betyr at raskere en-kjerne klokkehastigheter alltid er en. Multi-Cores CPUer er i stand til å behandle flere sidevisninger og andre servertjenester.
Dette er en annen for utvikleren din.
Gjennomgå databasen din på semifrunnlag for å sikre at den ikke har blitt oppblåst med ubrukte bilder og filer. Å slette unødvendige filer vil declutter det og fremskynder gjennomsnittlig sidelastningstider.
Å bruke virkelig store bilder kan og vil bremse nettstedet ditt. Hvor stor? Alt over 1 MB er rett og slett for stort.
Og som vi allerede vet, vil tregere belastningstider føre til høyere avvisningsrater og sende uønskede signaler til Google.
For de som er på WordPress, er det en rekke bildeoptimaliseringsplugins å velge mellom som kan effektivisere en ellers kjedelig manuell oppgave. Dessuten har mange også med andre funksjoner som lat belastning og automatisk størrelse.
Enten et nettsted er mobilvennlig eller ikke dreier seg om du har forenklet og strømlinjeformet nettstedet ditt for mobil nettleseropplevelsen.
Mobilbrukere samhandler med sider annerledes og har mye mindre tålmodighet for langsomme belastningstider og vanskelig å navigere på nettsteder. Hvis nettstedet ditt har mislyktes den mobilvennlige testen beskrevet ovenfor, eller selv om det er bestått, men du er interessert i videre optimalisering, så la oss gå over noen av de beste praksisene.
Dette bør være alle utgiverens primære bekymring. En enkel måte å adressere brukervennlighet er å stille deg spørsmål som:
Disse svarene vil gå langt i retning av å identifisere smertepunkter for brukere. For eksempel vil du ikke få brukerne dine til å justere skjermene for å se innholdet ditt. Du kan se hva vi mener i eksemplet nedenfor.
For å optimalisere innholdet ditt for mobile enheter, er det tre utviklingsalternativer:
Vi har bestilt dem når det gjelder enkel implementering, og vi anbefaler å ta i bruk et responsivt design, da det er det minst krevende av de tre alternativene.
Utviklere legger ganske enkelt til Meta Name = ”ViewPort” -koden til en websides eksisterende
Fordelen her er at du bare trenger å opprettholde ett nettsted, som enkelt kan vises på tvers av hvilken som helst skjermtype.
Derimot fungerer dynamiske design ved å betjene forskjellig HTML -kode basert på brukerens enhet. Sider må bruke Vary HTTP -overskriften for å forhindre at feil kode blir servert til feil enhet.
Endelig er det mobile underdomener, som vi ikke anbefaler gitt mengden ressurser som kreves for å implementere effektivt. Mobile underdomener er helt separate nettsteder som separate vertsbehov. For å sikre at crawlers forstår forholdet mellom domene og underdomenet, må du inkludere rel = ”kanonisk” -taggen.
Fordi responsive 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 til alle design:
Dette siste trinnet er den enkleste måten å forbedre sideopplevelsen på, men går også langt for å forbedre brukerens trygghet.
Når du bytter til HTTPS beskytter og krypterer brukernes informasjon, hjelper det også å forhindre mennesket i midten (MITM) angrep. På toppen av dette eliminerer det å ha et SSL -sertifikat advarsler om nettleser om mangel på sikkerhet.
Hostingleverandøren din burde virkelig kunne gi deg HTTPS -sikkerhet, hvis det ikke gjør det, kan det være verdt å vurdere et trekk til en som gjør det. Det er allerede flere bemerkelsesverdige hostingleverandører som gir HTTP -er gratis . Dessuten bruker de som er vert for leverandører som gir 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 sertifikatmyndighetene (CAS), 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 annonseinntektsstrategien. Problemet er at en HTTPVil ikke jobbe på et nettsted ved hjelp av HTTPS.
Vi anbefaler rådgivning med AD -teknologipartnerne dine før du gjør endringer på nettstedet ditt.
For mer informasjon, sjekk ut Googles omfattende guide om emnet.
Påtrengende interstitielle annonser og dialogbokser gjør det vanskelig for søkemotorer å forstå innholdet til en webside, som kan undergrave SERP -ytelsen.
Det ville være flott om det var en måte å lage interstitials som ikke forstyrret brukeropplevelsen, men det er hele poenget med slike annonser. De overtar hele skjermen i pauser i innhold for å gi brukerens oppmerksomhet.
Som sådan ville utgivere ha det bedre å bruke bannerannonser i stedet for mellomliggende annonser, da de bare tar opp en liten del av skjermene for skjerm. Bedre å risikere bannerblindhet enn brukerens frustrasjon.
Forlag kan bruke nettleserstøttede bannere eller enkle HTML-bannere som lenker til CTAs destinasjonsside.
Dialogbokser kan også brukes til salgsfremmende kampanjer, men disse kan utformes for å være uinnførende. Du må sikre at brukere kan få tilgang til innhold uten avbrudd.
Det er ingen reelle snarveier for å optimalisere sideopplevelsen din, og det er viktig at du fikser punktene ovenfor. Når det er sagt, er det verdt å påpeke at selv om WordPress lett er den mest populære publiseringsplattformen i verden, betyr ikke dette nødvendigvis at det er den beste CMS når det gjelder å øke CWV -ytelsen.
Å se på CWVS -teknologirapporten viser at bare rundt 29% av WordPress -nettsteder har gode CWV -er, mens 41% av Wix -nettstedene får den grønne flått.
Det er verdt å veie opp om å bytte til en spesialisert CMS kan forbedre CWV -ene dine.
Det er mye grunn å dekke når det gjelder å optimalisere sideopplevelsen og komme i gang kan være litt skremmende. Det er imidlertid viktig å huske at du spiser elefanten ved å ta en bit av gangen.
Å sikte på en "god" poengsum på tvers av alle CWV -beregningene dine er ikke nødvendig for å hjelpe nettstedet ditt med å klatre på SERP -ene. Mer enn det kan imidlertid å sette seg slike høye mål være motvirkende, da det kan være en demoraliserende forfølgelse.
Sikt på små gevinster når det gjelder CWV -ene, fokuser på å adressere "dårlige" resultater uten å være altfor å bekymre deg for "behovsforbedring" -linjen. Det kan komme senere, når du har mer tid og ressurser til å vie prosessen.
Vi har allerede snakket om Yahoo! Japans forbedrede CLS -poengsum, la oss se på et annet par nettsteder som vi kan lære noen leksjoner fra.
Indian Daily the Economic Times, som betjener mer enn 45 millioner aktive brukere, reduserte CLS -poengsummen med 250% fra 0,25 til 0,09 og LCP -tiden 80% fra 4,5 sekunder til 2,5 sekunder.
Mellom oktober 2020 og juli 2021 trimmet Publisher LCP -score i det "dårlige" området med 33%, mens CLS -verdiene i det "dårlige" området falt med 65%. Disse gevinstene tillot de økonomiske tidene å passere CWV -terskler over hele opprinnelsen, samtidig som de reduserte totale avvisningsratene med 43%.
Forlaget oppnådde dette på flere måter, med den første av disse som prioriterer nedlasting av eiendeler ved å bruke prioriterte hint. Den taklet også lange oppgaver, og bryter opp biter av kode for å sikre at ressursene som er kritiske for ovenfor sammenleggingsinnstillingen ble lastet først.
Det britiske nyhetsnettstedet forbedret CLS -poengsummen fra 0,25 til 0,1 , mens du økte antall nettadresser som fikk en bestått karakter fra 57% til 72%.
Telegraph brukte Chrome Devtools for å identifisere individuelle forekomster av skiftende layout.
Før du deretter bruker WebPagetest for å finne hvor på tidslinjen oppstod oppsettskiftet.
Med disse dataene i hånden begynte teamet fokusert på å redusere layoutskift ved å takle disse områdene
For annonser begynte den telegraferte å reservere plass for dem og brukte den vanligste annonserstørrelsen for å spesifisere dimensjoner. Dette bidro også til å hindre annonser fra å kollapse når de ble sett på et nettbrett.
Teamet taklet et lignende problem med inline -bilder øverst i artiklene, som ikke hadde spesifisert dimensjoner.
Telegraph gjorde andre justeringer, for eksempel å flytte overskriften til toppen av markeringen og bruke plassholdere for innebygde videoer, men beskrev til slutt prosessen som "ganske enkel" mens de fortsatt hadde en betydelig innvirkning.
Forbedring av sideopplevelsen trenger ikke å være overveldende. Mål de fire søylene på sideopplevelsen, og bestem deg deretter for hvilke ressurser du kan bruke for å forbedre resultatene.
Hvis du er en mindre utgiver, vil ressursbalansering være avgjørende, og vi vil anbefale å identifisere rimelig lav hengende frukt for ditt første prosjekt.
Når de ser på Telegraphs tilnærming, fokuserte de på ett aspekt av CWV -ene i stedet for alle tre og gjorde betydelige forbedringer. De økonomiske tidene fokuserte på to av de tre for å levere noen imponerende resultater.
