React, SEO og visning

Hvorfor du bør lage en statisk React app med Next.js og server-side rendering eller generere med Gatsby 👉

Problemet

Om du lager single page applications med React så vil du sannsynligvis oppleve disse problemene:

Hvis denne React-appen tilhører et selskap eller en offentlig nettside med mye trafikk så vil du fort få tilbakemelding om at folk ikke finner nettstedet. For en forretning så betyr dette tapte inntekter siden folk ikke finner produktene, og for offentlig sektor så betyr det at folk hverken kan finne eller bruke offentlige tjenester. Dette er det verste scenariet og har vært et problem med React i mange år.

Kort sagt så er problemet at dine sider bygges med hjelp av javascript.

For å forstå problemet så trenger du å forstå hvordan en side vises i en nettleser og hva en robot fra Google, Bing, Facebook og Twitter kan se. Til syvende og sist så handler dette om hvordan nettsiden vises i nettleseren, hvor dataene lagres og hvordan nettleseren henter det. Dette kalles rendering. Ordet stammer fra fransk og betyr å lage. Typisk brukes ordet i IT-fag for å forklare hvordan en datamodell blir konvertert til noe annet, for eksempel grafikk.

Les mitt forrige innlegg for å forstå hvordan søkemotorer fungerer: Hvordan ser søkemotorer

Det viser seg at søkemotorer og andre roboter er vandt til den gamle måten. Derfor er det blitt vanskeligere å optimalisere for søkemotorer med Create React App. Løsningen er å levere innholdet i statisk format, og gjerne levere hele nettstedet statisk også.

Vi må hjelpe robotene finne og forstå nettstedet vi lager. Vi løser dette ved å levere innholdet som statisk informasjon. I dette innlegget forklarer jeg alternativene for å gjøre dette med React og hvordan det løser problemet. Jeg legger til at dette kan også gjøre nettstedet mer tilgjengelig for de som reiser verdensveven uten javascript.

Hvis du vil gå rett til oppsummeringen så hopp rett til slutten for mine anbefalinger, men jeg tror at noen folk ønsker å forstå de ulike alternativene og hvordan de fungerer.

For nå holder det å forstå de ulike måtene man kan bygge et nettsted. Det er 3 måter:

Gatsby er et rammeverk for static site generation. Next.js er et rammeverk for server-side rendering, og Create React App er et rammeverk for å bygge client-side rendered applikasjoner. Alle tre er laget for React.

La oss starte med den tradisjonelle måten å bygge et nettsted som lagrer alle dataene i HTML.

Static site generation

Hvordan fungerer dette egentlig?

I et tradisjonelt nettsted skriver vi innholdet rett i HTML filer eller i et verktøy som lager det for oss. Tenk å skrive dine blogginnlegg i ren HTML.

Det er også andre verktøy som kan konvertere råtekst til HTML. Enkle CMS og rammeverk som Hugo og Gatsby lager sider fra markdown. Hvordan skjer det?

I denne metoden ber vi om tilgang til dataene mens vi bygger nettsidene. Med andre ord bygger vi nettstedet mens koden kompilerer. Så kan vi bruke vårt API i Gatsby (eller Hugo i mitt tilfelle) for å hente våre data lagret andre steder og bygge nettstedet slik at det kan legges ut på internett. Kort sagt så bygger vi nettsidene i forkant av at brukeren besøker nettstedet. Dette kalles også prerendering.

Slik bygges våre HTML filer og vanligvis i moderne verktøy som Hugo og Gatsby får vi minifiserte styling og script filer i samme prosessen. Denne prosessen er tilpasset for å gjøre nettsidene veldig små slik at de kan lastes raskere i nettleseren. Folk setter veldig stor pris på at sider laster raskt og søkemotorer belønner raskere sider med høyere rangering.

Når noen besøker vår nettsted i nettleseren så mottar de HTML filene med styling og script filer. Dette krever minimalt visningsarbeid i nettleseren, såkalt rendering, en prosess som vi sier hender på client-side.

Client-side rendering

Til sammenligning med static site generation så handler client-side rendering om å gi nettleseren både oppgaven å vise nettstedet og legge til data i HTML maler.

Når noen besøker nettstedet ditt så vil nettleseren hente HTML, CSS og javascript filene fra dine server, og deretter lese og kjøre javascript forespørselen fra React til å hente dataene som mangler for å bygge og vise en nettside. Det betyr at nettleseren tar seg av oppgaven å hente dataene via et API-kall. Dette tillater deg å lagre dine data utenfor nettstedet, for eksempel i en database eller et hodeløst CMS.

Hvorfor er det et problem?

Kort sagt så er ikke crawlere og roboter nettlesere og derfor kan de ikke lese og kjøre javascript. Det som ser fint ut i din nettleser for et menneske er en helt annen oppgave for maskiner.

Det betyr at når Bing sender sin crawler til ditt nettsted så finner den ikke noe tekst som den kan fortolke, men kun javascript og hva enn for statisk HTML tags du har etterlatt der. Vanligvis er det kun javascript å finne.

Dette kan ikke Bing forstå så det er ikke akkurat enkelt å rangere et slikt nettsted på noe som helst tema eller søkeord. Hvis du er bekymret for at det skjer med ditt nettsted så prøv å hente nettsiden din med curl. For eksempel

curl https://www.google.no

Du kan også sammmenligne resultater fra Google Mobile Friendliness Tool og Bing Webmaster Tools for å se forskjellene i hver crawler.

Facebook og Twitter har samme problem. Når noen lenker til ditt nettsted så vil ikke innholdet vises riktig, hverken tittel, beskrivelse eller ingress. Derfor kan det fremstå ganske uprofesjonelt og det kan skade vårt omdømme. Det ønsker vi å unngå.

Google vil mest sannsynligvis forstå nettstedet men det er ikke garantert heller. Du må vanligvis melde inn siden via Google Search Console eller ved å pinge Google om å sjekke ditt sitemap.

Hva hvis du har mye innhold og mange redaktører? Da blir en server virkelig relevant.

Server-side rendering

Server-side rendering løser problemet vårt litt annerledes.

Først og fremst så har vi en server hvor vi kan lagre både nettstedet og innholdet vårt. Mens noen besøker siden så vil nettleseren deres sende en forespørsel til vår server for HTML, CSS og javascript filer. På dette tidspunktet svarer serveren forespørselen til vårt innholds-API for å hente data, og så bygges nettsidene av serveren for sluttbrukeren. Det vil si at nettsidene bygges av serveren når brukeren besøker nettstedet. Deretter så kan nettleseren gjøre ting på den gamle måten og vise ferdiglagd HTML, CSS og javascript filer til brukeren.

I dette tilfellet så har det ikke noe å si om vi bruker et hodeløst CMS med React eller en fullstendig CMS applikasjon heller.

Dette betyr også at når roboter besøker nettstedet så får de alt innholdet servert som statisk informasjon. Dette kan lastes ned, kjøres og forstås slik at nettstedet kan rangeres på tema de tror er relevante. Dette er like bra som static site generation fra robotenes ståsted. Fordelen med serveren er at mange redaktører kan skrive og publisere innholdet umiddelbart.

Facebook og Twitter vil også kunne hente sidetittelen og alle dataene slik at de kan vise brukere noe meningsfylt når man lenker til nettstedet.

Eksempler ved å bytte til og fra server-side rendering

Finnes det noe bevis om at dette har noe å si? Ja og ganske mye bevis egentlig.

Noen nettsteder som har byttet byggemetode til statisk informasjon har sett gode resultater.

Spectrum Chat siden byttet til server-side rendering og så øyeblikkelige forbedringer i trafikk fra søkemotorer.

Den naturlige forklaringen er at søkemotorene var endelig i stand til å finne og forstå innholdet på alle sidene deres. Det betyr at de kunne oppdage sider de ikke hadde visst om tidligere og deretter forstod innholdet godt nok til å rangere det. Først da kunne folk finne sidene deres i en søkemotor.

Det finnes også eksempler om nettsteder som byttet til client-side rendering og mistet trafikk som et resultat:

Konsekvenser for små og store nettsteder

Du bryr deg kanskje ikke om problemet, men et firma, en veldedig stiftelse, ikkestatlig organisasjon og offentlige aktører må bry seg om dette.

Et firma vil tape salg på grunn av dette problemet og sannsynligvis til konkurrenten. En offentlig aktør kan ikke utføre sin oppgave til befolkningen om folk ikke kan finne informasjon og offentlige tjenester de har rett på. En ikkestatlig organisasjon som jobber med innsamling til veldedige saker og offentlig opplysning vil også bli hindret av dårlig søkemotoroptimalisering.

Dette er like skadelig som å skjule innholdet fra en søkemotor med vilje. Det er en reell risiko for å skade folk om tjenesten er viktig nok.

Etter min erfaring så er dette spesielt tilfelle for nettsteder med mange hundre og tusener av sider. Desto mer innhold desto vanskeligere er det å få dette lagt til i søkemotorer og holde de oppdatert om endringene man gjør på nettstedet sitt.

Hvorfor er det slik? Søkemotorer besøker nettsteder ditt mer enn en gang i uken og i noen tilfeller mer enn en gang per dag.

De vil derimot ikke oppdage alle dine nye sider, sider som er flyttet, endret eller fullstendig fjernet. Det er fordi søkemotorer har mange nettsteder å besøke hver dag så de setter en grense for hvor lenge de besøker ditt nettsted. Dette kalles et crawl-budsjett.

Hvis du også endrer måte du bygger og viser nettstedet ditt så trenger du en metode å informerer søkemotorer om endringene. Hvis du flytter innhold så bør du sette redirects. Å gi søkemotorene en oversikt med et sitemap er også nødvendig om nettstedet består av tusener av sider. Crawleren bruker dette til å oppdage endringer i informasjonsarkitekturen. Crawlere kan også reise via nettstedet ved å følge lenker som et menneske gjør, så sørg for at de er i orden og unngå lenkeråte.

Når bør man bruke static site generation og server-side rendering?

La oss anta at du har bestemt deg for å bruke React.

Hvis du ikke har bestemt deg og du skal kun lage en personlig blogg så anbefaler jeg å bruke Hugo. Det er et enkelt rammeverk for å lage blogger og tilogmed firmasider.

For de som virkelig har lyst til å bruke React så svar på disse spørsmålene:

Må du promotere dette nettstedet? Skal det være lett å finne?

Ønsker du å legge ut mye innhold ofte?

Du kan også blande flere måter å bygge nettstedet på så siden er delvis server-side rendered og delvis client-side rendered.

Grunnen til at mengden innhold har noe å si er at static site generation verktøy som Gatsby kan bli trege når du bygger tusener av sider. Det finnes måter å optimalisere dette.

Hugo bygger mange sider enkelt og raskt. Mitt nettsted med en håndfull sider bygges på 17 millisekunder.

Fordelen med å velge static site generation fremfor server-side generation er at det er billigere. Å kjøre mange servere kan bli dyrt.

Disse spørsmålene vil hjelpe deg å planlegge ditt nettsted uansett så du bør finne ut av det før du velger rammeverk. Kort sagt så trenger du å forstå formålet med nettstedet, hva slags innhold du skal lage, hvor mye innhold det blir og hvor mange redaktører skal jobbe med det.

Hvor mange brukere skal kunne publisere innhold og trenger du å publisere nytt innhold ofte? Hvor raskt må du kunne få innholdet ut på nettet for å oppnå ditt mål med nettstedet?

Det er ikke umulig å bygge om nettsteder etter å ha funnet svarene på disse spørsmålene men du sparer deg selv for mye smerte ved å kjenne svarene i forkant. Det gjør det enklere å løse utfordringer om publisering, SEO, brukskvalitet og ytelse.

For å oppsummere, dersom du har mange redaktører som ønsker å publisere sitt innhold umiddelbart så er nok server-side rendering det beste alternativet. Det gjelder typisk nettsted som bruker CMS eller åpenkilde programvare som lar sluttbrukere publisere sitt innhold raskt. I dette tilfellet så bør man bruke Next.js.

Hvis innholdet ikke endres så ofte så er det nok tilstrekkelig med statisk innhold og å bygge sidene før de publiseres. Isåfall anbefaler jeg å bruke Gatsby. Dette passer godt for blogger.

Hvis du har allerede bygget appen din med Create React App og ikke ønsker å investere tid for å gjøre hele nettstedet statisk så kan du vise deler av siden statisk med React-helmet for meta-tagger og sidebeskrivelsen. Dette er ikke en løsning for hele nettstedet. Jeg har merket meg at siden som promoterer Create React App har byttet til å bruke Gatsby, så det er er noe å tenke på.

Merk også at dette ikke er et problem for en innlogget side. Bare sørg for at landingssiden dukker opp som forventet.

Ikke forvent at dette skal fungere med Create React App. Bare fordi Googlebot forstår javascript så er det ikke rimelig å forvente at andre tjenester gjør det samme. Det er en betydelig kostnad ved å gjøre dette for selskapene og det er ikke nødvendigvis fremtiden for verdensveven heller.

Personlig mener jeg det er en ganske stor tabbe av Facebook-teamet som lagde React og det er uheldig at utviklere må lære ekstra rammeverk for å bygge en side som kan vises i en søkemotor og sosiale medier. Den gode nyheten er at statiske sider får et comeback-øyeblikk, men kostnaden har vært stor og unødvendig.

Dette legger stadig mer press på utviklere men det hindrer også adopsjon av nye teknologier når folk oppdager at en single page application lager ekstra kompleksitet som ikke fantes i tradisjonelle nettsider. Hvert problem som øker sjansen for å gjøre en feil fører til at folk blir mer forsiktige og skeptiske. Tilogmed så skeptiske at man utsetter nødvendige endringer. Det fører igjen til at firma venter med å investere i sine nettsteder og mislyktes i å nå sine mål.

Jeg håper innlegget hjalp deg å forstå at det finnes alternativer for å løse disse problemene og som lar deg nå dine mål på verdensveven.

Jeg bør legge til at det ikke holder å ta råd fra Google webmaster miljøet fordi de ikke prioriterer å hjelpe deg få synlighet i en annen søkemotor enn sin egen. Det er uheldig fordi det betyr at rådene deres blir mindre nyttige. Det utviklere må få med seg om SEO nå er at mesteparten av internett støtter fortsatt ikke å kjøre javascript og man bør oppføre seg deretter. Heldigvis er utviklerguiden fra Google om Rendering on the Web verdt å lese.