JavaScript bliver mere og mere normalt på diverse hjemmesider. Frameworks som Angula, React og Polymer bliver brugt i stigendende grad på diverse blogs og e-commerce sites, og disse frameworks giver frihed og performance til at bygge lige præcis den hjemmeside, du går og drømmer om. Men Google og JavaScript har ikke den bedste historie set i et Search-perspektiv.
Man hører hele tiden, at Google er blevet god til at læse JavaScript, og at man derfor ikke behøves at tænke sig om, når man laver en hjemmeside i JavaScript. Vi bør dog have i mente, at Google-bot, som er Google’s crawler, benytter Chrome 41. For at sætte det lidt i perspektiv, så blev Chrome 41 udgivet i maj 2015. Har man i skrivende stund opdateret sin Chrome-browser, vil man have Chrome 66.
Det er altså en forholdvis gammel udgave af Chrome, Google-bot kører med.
Når vi taler om, at Google er blevet god til forstå JavaScript, så er det traditionel JavaScript, der henvises til. Moderne JavaScript er en udfordring, der bør tages højde for, hvis man ønsker at performe i Googles søgeresultater.
Hvad skal man have i mente, når man har en JavaScript-hjemmeside?
Når man skal vurdere dette, er det vigtigt at have Google-bot i baghovedet.
Når Google vurderer en hjemmeside og dens indhold, er der tre parametre, som gør sig gældende:
- Crawling
- Rendering
- Indeksering
Man hvad betyder det helt præcist?
Det er nemmest at forklare enkeltvis:
Crawling:
Når Google-bot skal crawle en hjemmeside, betyder det, at Google går ind og kigger på indholdet af siden.
Hvis en side ikke er ’crawlable’, vil den ikke blive indekseret i søgeresultaterne.
I den sammenhæng er der typisk 3 problematikker i forhold til crawling af JavaScript:
- URL’erne skal være tilgængelige
JavaScript-hjemmesider kan have den udfordring, at de interne links på siden er gemt helt væk i et JavaScript. Dette kan være svært for Google-bot at afkode, hvorfor man altid bør have et XML-sitemap, når man benytter JavaScript til sine interne links. Så er man sikker på, at Google har fået at vide, hvor ens URL’er kan findes. Dette er dog ikke ensbetydende med, at de vil blive indekseret.
- Duplicate Content
JavaScript-sites har en udfordring med, at content bliver skiftet ud dynamisk. Indhold kan derfor lynhurtigt blive spredt ud på flere URL’er. Det er derfor vigtigt at benytte canonical tags, så man fortæller Google, hvor indholdet hører til. På den måde undgår man duplikeret indhold.
- Rene, unikke URL’er
Der er uendelig mange metoder til at få content til at vise sig – enten ved at bruge URL’en eller blot skifte indhold via Ajax. Google-bot skal bruge en ren og unik URL for indholdet, før end den kan indeksere siden i søgeresultaterne. Der bør derfor hverken benyttes hashtags eller webparametre, hvis undersiderne skal indekseres bedst muligt.
Rendering
Når Google-bot forsøger at skabe sig et billede af, hvad der faktisk er på en side, kalder vi det rendering.
Google læser og forstår HTML, men når JavaScript er indblandet, skal JavaScripten renderes, før end Google kan forstå indholdet i Scriptet. Dette tager tid og ressourser.
Eftersom Google skal crawle alle sider i hele verden, er det derfor begrænset, hvor mange ressourcer der kan benyttes på en enkelt URL.
Derfor kører Google-bot med en 2 steps-indekseringsproces, som bliver kørt igennem ved hver URL.
I de to forskellige steps bliver der tjekket for følgende ting:
- step: Server sided indhold:I det første step læser Google hele HTML-koden, meta data samt links til andre sider (så crawlingen kan fortsætte).
Allerede her begynder Google at indeksere siden i forhold til, hvad den har fundet – den påbegynder dog også en rendering af alle scripts på siden, og når de scripts så er tilgængelige, går 2. step af indekseringen igang. - step: Renderet indhold:
I 2. step kigges der udelukkende på det renderede indhold. Hér er det derfor en udfordring, hvis man benytter JavaScript til at indsætte title tags, meta beskrivelser og canonical tags. De bliver simpelthen ikke læst, da Google kigger på netop disse i første step.
Som sagt, har Google en begrænset mængde ressourser til at crawle, rendere og indeksere en underside.
Rammer Google derfor et langsomt site, hvor der skal renderes en stor mængde scripts, er det ikke sikkert, Google når at komme dem alle igennem, og man kan derfor ende med at få en delvist indekseret underside, som sjældent kommer til at performe optimalt. Det betyder, at hjemmesider med meget JavaScript kan være langsommere at indeksere og dårligere til at performe end normale HTML-sider, netop pga. af hele renderingsprocessen.
Google anbefaler selv to forskellige løsninger på denne udfordring. Hvilken, der bør vælges, kommer helt an på, hvad der økonomisk giver bedst mening for din hjemmeside:
Hybrid Rendering:
Hybrid Rendering handler om at pre-rende sit JavaScript på server-niveau, og vise dette til browsere og crawlers. På den måde sikrer man sig, at alt indhold er indeksertbart,når Google-bot kommer forbi.
Den pre-renderede version bliver indekseret, og man opnår den fulde effekt, når man skal placeres i søgeresultaterne.
Derefter kan JavaScript ændre og opdatere indholdet på siden, men kun for at øge brugervenligheden. I ændringerne bør der kun være indhold, som Google allerede har set i den pre-renderede version, eller indhold som ikke er relevant at indeksere.
Google vurderer selv, at denne løsning bliver best practice på den lange bane.
Dynamic Rendering:
Denne løsning går faktisk imod Googles tidligere guidelines, der dikterede, at det er forbudt (cloaking) at vise forskelligt indhold til brugeren og til Google-bot.
Ideen med Dynamic Rendering er at sende det fulde serverrenderede indhold til søgemaskinerne og lade dette blive indekseret. På samme tid sender man client-sided indhold til brugeren.
Man har altså en server, der viser den normale version af siden, som er dynamisk renderet. Det er denne version, Google vurderer og indekserer. I mellemtiden viser man en client-sided version til brugeren, som er noget hurtigere at loade. Det øger brugeroplevelsen, da siden kommer til at virke meget hurtigere.
Denne løsning kræver dog en meget specifik server-infrastruktur, som kan være en dyr løsning at etablere.
Ønsker du at kigge mere ind i implementering af dynamic rendering, er her et par muligheder:
Puppeteer: https://developers.google.com/web/tools/puppeteer/
Rendertron: https://github.com/GoogleChrome/rendertron
Hvornår bør man gøre noget ved sin rendering?
- Hvis man er dybt afhængig af moderne JavaScript-frameworks, som outputter meget lidt HTML.
Ovenstående billede viser, at intet er pre-renderet, og at alt indhold bliver skudt ind client-sided.
Dette er en meget moderne form for JavaScript, som Google ikke umiddelbart kan læse.
Er du i tvivl om, hvilke ressourcer den nuværende Google-bot kan se, kan man via caniuse.com sammenligne den nuværende Chrome-browsers kompetencer med Google-bot.
- Hvis man har en stor side, som skifter indhold tit, kan dynamisk eller hybrid rendering hjælpe med at få nyt indhold indekseret hurtigere. Dette kan fx være en nyhedsside, der kræver, at nyhederne hurtigt bliver indekseret.
- Har man sider, der benytter sociale medier og chat-applikationener, som kræver at kunne tilgå indholdet på siden, bør man overveje sin rendering
Hvornår bør man ikke ændre sin rendering?
Som udgangspunkt bør man holde en evt. ændring op imod de ressourcer, det kræver at implementere det.
Grunde til ikke at ændre sin rendering:
- Hvis man ikke er afhængig af moderne JavaScript til at vise sit indhold – i så fald vil Google nemlig ikke have nogen problemer med at rendere og indeksere indholdet.ellers vil Google ikke have nogle problemer med at rendere og indexere indholdet.
- Hvis man på forhånd ved, at man ikke har de server-ressourcer, det kræver at kunne håndtere de avancerede indstillinger for at komme i mål med enten hybrid rendering eller dynamisk rendering.
Indeksering:
Core & embedded content
Indholdet bør være synligt for Googles crawler. Her er der en del retningslinjer for, hvilket indhold Google kan læse og hvilket indhold, der er usynligt for Google.
De typisk anvendte JavaScript-elementer er:
Lazy Load-billeder:
Google kan ikke læse Lazy Load-billeder, eftersom de først bliver renderet, når brugeren scroller ned ad siden. Man kan dog ret nemt gøre disse billeder tydelige ved at indsætte et ”noscript” på billederne eller ved at markere dem med Schema markup.
Interaktions elementer:
Google-bot forholder sig ikke til knapper eller scroll-funktioner på en underside, og derfor vil indhold, der kræver en ”action”, som hovedregel ikke blive læst. Det kunne eksempelvis være:
Tab navigation / infinite scroll
Når man benytter tab-navigationer og infinite scroll, er det vigtigt, at man linker til det indhold, som vises, efter brugeren har trykket eller scrollet ned til handlingen.
Ved infinite scroll er der også tale om pagination, hvorfor man bør linke til siderne via ”rel=next/prev”.
Http codes
Statuskoder skal leveres til Google server sided, ellers fanger Google ikke statuskoderne, og der kan derfor opstå et mismatch imellem, hvad hjemmesiden har af undersider, og hvad Google rent faktisk ser.
Hastighed
Langsomme og ueffektive sider kan blive renderet uregelmæssigt, da Google ikke har tid til at vente på en langsom side.
Opsummering
Google bliver bedre og bedre til at forstå JavaScript, men moderne JavaScript kan være en stor udfordring.
Benytter du et website, der er lavet i et JavaScript-framework, kan det være en god idé at tænke over, hvordan du leverer dit indhold – både til Google og til dine brugere. Et dynamisk eller hybridt renderingssystem kan rykke din hjemmeside fra værende usynlig til at blive lige så synlig som en ganske normal HTML-hjemmeside.
Benytter du enkeltstående JavaScripts på din hjemmeside, er det vigtigt at tænke over, hvilket indhold du skyder ind i via JavaScript. Er det hovedindholdet på siden, bør man overveje blot at sætte det ind via serveren, men er det sekundært indhold, er det udmærket at have det stående i JavaScript, hvis man blot følger retningslinjerne.