When you first load a url the browser performs a document request, and under the hood it will look something like this:
You can see here that we are provided with things like a doctype and meta tags. Most consumer facing websites will constantly be trying to improve their traffic, one way to achieve this is having better standing with search engines like Google. Another way of doing this is making sure their website will display correctly when scraped by social media crawlers. In many cases this can all be improved using contextualised meta tags on your website. For example, Facebook will look for:
|
1 |
<meta property="og:title" content="When Great Minds Don’t Think Alike" /> |
…when their crawler is trying to determine what the title of a given url is. The problem with SPAs, specifically those that leverage client side rendering, is – these tags can never be changed, or at least not in a way that will allow the crawlers to see. It is possible to programmatically change tags with Javascript, but it is too late, the crawlers will generally only look at the document response on first load of the url provided, no JS is involved.
How can we fix this, well there is a thing called server side rendering, check out this great article that talks about using SSR with Next.js. In a nutshell, server side rendering means that instead of getting a massive bundle of javascript that then runs to determine what structure will be present on first load, the initial state of the markup now gets generated ahead of time by the server, so when that initial document request lands in, it is actually now representative of the intended state.
How does this solve our problem with the crawlers? Well let’s say we are on darrylsbrilliantapp.com/home which contains the default meta tags, with SSR when we navigate to darrylsbrilliantapp.com/about we can now receive a new document response via sockets, this document can hold the specific meta tags we want to show on /about, which means tools like crawlers can pick them up.