Why and How to Check the Server-side Rendered Content on your Website

So you've built a website powered by a JavaScript framework with server-side rendering, like Next.js, Gatsby, or Nuxt. However, you notice some issues with SEO - maybe Google isn't discovering links on your site properly, or your PageSpeed Insights performance score is hurt by high cumulative layout shift (CLS). Maybe your page feels jumpy as it loads.

These problems are common when developers write isomorphic code - code that runs both on the server and client. In our optimized development environment, with fast computers and internet speeds, the client-side rendering process of React and other JS frameworks is so fast that we don't often see what the page looks like and how it functions before and while the JavaScript executes.

Why does the server-side rendered UI matter if the page looks fine after it's done loading?

Most search engines either don't run client-side JavaScript at all, or defer it (like Google does), so we need to ensure all of the content that we can render on the server is rendering correctly. From the linked Google documentation page:

Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.

Plus, a stable loading experience is important to build a usable, accessible experience for users in varying network and device conditions. If we our content jumps around as the site loads, it can be disorienting for users and they may tap on unintended elements. Jumpiness during loading raises your CLS score, hurting your performance score and hurting your Google Search ranking - so it's important to monitor how our page loads.

How can I check the Server-side Rendered Content?

I recommend anyone building a site with server-side and client-side rendering try this debugging method:

1. Disable JavaScript in Chrome by following these steps: https://developer.chrome.com/docs/devtools/javascript/disable/
2. Refresh your page and play around - confirm the content is in place, try clicking on different parts of the page, etc.

Some issues to check for which I've run into in the past:

1. Links not working, because they're actually buttons using JS to act like links, instead of actual <a> tags - which will prevent or delay pages from being discovered
2. Some content not rendering, because a code issue is causing the content to be rendered on the client-side only - which worsens UX due to content loading only after client-side JS takes over (hydration), and hurts your performance score due to content shifting during hydration instead of initially loading correctly - which also has a negative SEO impact. Additionally, client-side-only content loads later, so Google may deprioritize links/images or miss them entirely.

Personal, I also find this to be an interesting, educational exercise to see how your website acts in different conditions.

How do I fix these issues?

While the exact issue can vary, here are a few suggestions and things to check:

• Make sure links are actually links. If you need them to look like a button, use an <a> tag styled as a button with CSS.
• Make sure the data-based parts of the page are rendered correctly, to confirm your server-side data fetching is working.
• If you fetch or revalidate any data on the client-side, make sure it's also being fetched in the SSR process and the client-side and server-side data is formatted the same/as expected.
• Watch out for any superfluous "client-side-only" checks. For example, many JS frameworks allow you to use typeof window !== "undefined" to check when you're rendering on the server or the client. If you need to use that, make sure it's moved to the most granular level possible - server-side render whatever you can.
• If there's an element you really can't server-side render, such as a customer's personal info on a static page, you should server-side render a placeholder to prevent CLS.

Note: most interactive features of your site probably won't work, unless you use native web forms/form handlers. That's expected, since we mostly build interactivity using JS. You want to focus on checking the content that should be server-side rendered.

Good luck!