Next.js och SEO
Om ni läser detta inlägg har ni kommit till vår nya webbplats. Vi har byggt den i Next.js tillsammans med contentful. En kombination vi tycker har många starka sidor, i detta inlägg kommer jag fokusera på ramverket Next.js och några fördelar det har utifrån ett SEO-perspektiv.
Next.js är framtaget för att effektivisera och förenkla utveckling i React och JavaScript. Det är open-source med MIT-licens, vilket innebär att källkoden är gratis och tillgänglig för allmänheten.
En USP med Next.js är enkelheten med teknisk optimering. Tid och kostnad har nästan alltid ett linjärt samband och Next.js är kostnadseffektiv att arbeta i.
Next.js stöder server-side rendering som standard. Server-side rendering (SSR) är när webbplatsinnehåll renderas på servern istället för i webbläsaren. Servern förbereder en HTML-fil med användarspecifik data och skickar den till klienten.
Eftersom innehållet renderas innan sidan laddas, behöver inte JavaScript köras för att läsa och indexera vilket gör att SSR-webbplatser är enklare för sökmotorer att indexera. En konkret del från web core vitals som påverkas markant av denna teknik är first contentful paint.
Next.js använder en teknik som kallas codesplitting, det är en dynamisk importfunktion som delar upp koden och skickar den del som är nödvändig till browsern. Istället för att använda stora JavaScript-filer som innehåller en hel applikation, bryts den ner i mindre delar. När en användare går till en sida, laddas enbart den kod som är nödvändig för den specifika sidan.
Mängden av JS-kod är i många fall en avgörande faktor för laddtider och jag skulle säga att codesplitting-tekniken har en mycket positiv effekt på prestanda och därmed SEO.
Fonter har ofta en förmåga att höja laddtider där en anledning är att de många gånger kräver externa nätverksförfrågningar när fonten laddas. Ibland ser man exempelvis en blinkning när fonter laddas som påverkar den visuella stabiliteten och höjer CLS (vars värde ska vara så lågt som möjligt).
Next.js har en automatisk font-optimering som dels tar bort externa nätverksförfrågningar men även genererar en fallback som tar bort eventuella skiftningar i layouten.
Bildoptimering är en viktig del inom SEO och bilder är många gånger en bidragande orsak till att en sida laddas långsamt och detta är liksom annat inbyggt.
Next.js har en bildkomponent som optimerar bilder automatiskt och genererar den mest lämpade bildversionen för webbläsaren för optimal prestanda inklusive konvertering till WebP.
Bilder i Next.js laddas som standard med lazy loading, vilket innebär att de inte laddas förrän de blir synliga på skärmen när användaren scrollar nedåt. Detta minskar den initiala laddtiden och förbättrar användarupplevelsen.
Många vet vad som bör göras med bildoptimering, problemet är att det inte görs och glöms bort, att detta sker automatsikt är styrkan.
Next-sitemap-paketet ger ett flexibelt stöd för automatisk generering av dynamiska sitemaps som inkluderar Google News, bilder, videos och hreflang.
För en standardsitemap brukar jag enbart generera LOC och LASTMOD. Sedan är ett viktigt tillägg att ta bort sidor som antingen är canonicalizerade eller satt som no index. Jag hittade en tråd om hur man modifierar sitemap-paketet för att exkludera no index.
Next.js använder 307 och 308 istället för 301 och 302 och enligt John Mueller hanterar Google dessa på samma sätt. Men rent tekniskt finns en stor skillnad och den bygger på hur en 308 tar hänsyn till GET och POST och för att förstå skillnaden mellan ompekningmetoderna behöver man förstår hur GET och POST fungerar.
När en webbapplikation byggts upp används GET och POST-förfrågningar för att hämta och skicka information mellan servern och klienten (ofta en browser).
GET används för att hämta information, som att visa sidor, sökresultat eller bilder, medan POST används för att skicka data till servern, som att skapa användarkonton, skicka meddelanden eller utföra transaktioner.
När GET används skickas data som en del av URL:en. Informationen kan därmed både cashas och sparas.
När POST används skickas data till servern via en body som följer med HTTP-förfrågan. Post har därmed ingen begränsning på datamängd, vilket gör POST lämplig för att skicka större mängder data samt är ett betydligt säkrare sätt att hantera information.
Den stora skillnaden mellan en 301 och en 308 är att en 301 ändrar en POST-förfrågan till en GET-förfrågan vilket gör att eventuell data kan gå förlorad (eftersom GET bara använder data i URL:en) . En 308 däremot, kommer att bevara POST-förfrågan och behålla den data som finns.
Alltså: om det finns data utöver URL:en som behöver följa med är en 308 en bättre metod.
En skillnad mellan 301 och 308 bygger även på huruvida en klient hanterar cachning, en 301 är avsedd för användning med klienter som kan uppdatera sina egna cachar och index för att återspegla den nya URL:en. Men en 308 är avsedd för användning med klienter som inte kan uppdatera sina egna cachar och index för att återspegla URL:en och den kräver att alla klienter följer omdirigeringen.
Utifrån ett rent SEO-perspektiv är det få fall där det egentligen spelar någon roll om man använder 308 eller 301 om syftet enbart är att peka om en sida, så länge Google hanterar dessa så som de säger att de gör. Fördelen med en 308 är att den har möjligheten att överföra mer information och att den inte stänger vissa dörrar som en 301 gör.
För att slippa skriva JSON-LD manuellt finns exempelvis next-seo som automatiskt renderar ut strukturerad data. Den stödjer inte allt från schema.org men det vanligaste. Det verkar ganska smidigt att använda för att snabbt generera de vanligaste typerna och properties för webbplatser.
Det jag ser som den största fördelen att välja Next.js utifrån ett SEO-perspektiv är effektiviteten att utveckla komponenter och enkelheten att få ut en webbplats i SSR. De flesta viktiga SEO-delar är inbyggda i ramverket eller finns som komponenter man installerar där konfiguration etc går blixtsnabbt.
