Isomorphic, then Static, then Single Page

Published on Aug 21, 2020

Three months ago, I wrote about why we need to combine different web rendering strategies to have an optimal balance between SEO and user experience.

As I am in the middle of rewriting Cowriters' codebase following my own advice, I found out it's much more efficient to take into account each rendering method one after the other instead of implementing all of them at once.

Adding all rendering methods in parallel increases the time needed to obtain a full prototype, which isn't a viable option when you are building a startup: fast iterations are key to receive precious feedback, so the search for performance cannot be allowed to gain the upper hand.

When you take into account isomorphic rendering, client-side rendering, and pre-rendering, you need to duplicate some logic to complete a webpage: the page has to be loaded from the server dynamically or from a static file before being hydrated by the front-end framework, and you need to develop controllers from the web server as well as in-app routes (including duplicate authorization and data fetching logic). It's a lot of work.

If you have to do all three, it's best to start with an isomorphic approach. If you start with client-side rendering, you lose all SEO benefits, which is not acceptable for a content website. If you start with pre-rendering, you'll lose a ton of time building and rebuilding your static webpages to make everything work. Isomorphic rendering gives you an app that works so that you can receive instant feedback on your coding. It's also a great boilerplate to implement static generation and client-side routing in a future iteration loop.

While implementing hybrid rendering, you want to avoid meddling with in-app routing. You can fetch resources asynchronously at runtime instead of serving them, but you can't lose time on duplicating your routing logic to make it work on the client-side without refresh. Simply use regular links and server routes to navigate.

Once you're done with that and managed to put a first version in front of your stakeholders, you can add static support. It should be child play since you already managed to output the content; you just have to write it to a text file and tell the server which file is which webpage.

At this point, your app has perfect SEO and Performance Lighthouse scores, but you want to be able to seamlessly go from one page to another instantly thanks to in-app routing. Not having to wait just feels great, the reason is that simple.

That's when you have to sync the back-end routing logic with the front-end and request the data you need from one page to another, before the user even asks for it.

During the isomorphic implementation, each webpage will have its own dedicated Javascript bundle. In the last phase, all pages share a common bundle to handle the routing logic. You'll have to fine-tune your Javascript and lazy load components to keep the size under control, but it will be worth it.