Post content is now server-side rendered

Server-side rendering may not sound very exciting, but trust me, it's important.

I spent a whole day working on this. You may feel a slight performance improvement around the platform as posts load a little snappier, but otherwise this is a pretty invisible update.

So why spend so much time on it?

SEO, once again. Last week, I talked about how we've been making a lot of changes to optimize the organic search performance of content created by our users.

You can read more about that here:

To summarize these changes we made already:

• Human-readable asset URLs - replacing long UUIDs with the name of the asset

• Add the creator of the asset to the URL - for readability and discoverability, but also as a way to build the reputation of our users across the web.

• Consolidated the public, open-web (no user signed in) asset page with the signed-in app version. URLs are now the same, but access and details are determined by whether a user is signed-in or not.

Now that we've covered the work so far, let's get into the most recent changes we've made.

The problem to solve

When search engines like Google send their crawler to a website for indexing, they typically use a very basic version of a web browser. This simplistic setup usually results in no JavaScript execution or styling being applied. Consequently, the focus is primarily on the page’s initial HTML content.

For most static content, such as blog posts and guides, all the necessary information is included in the initial HTML sent from the server to the client. However, many websites use JavaScript to load content on the client side for various reasons.

In our case, we were displaying a read-only version of the editor to view the saved content. The problem with this approach is that search engine crawlers can't see the content you worked so hard to share. They can index the title and description because they're server-rendered, but they miss the main content entirely. This is a significant issue if we want Google to read the content, understand it, and use it to determine its relevance and how to rank it for specific search terms and keywords.

The solution to fix

To address the SEO challenges while maintaining a dynamic and performant website, we went with a hybrid rendering approach. The solution strikes a balance between search engine visibility and user experience. Here's what we did:

1. Server-side render critical content

   • Post text content: The main body of the post is now rendered on the server, ensuring that search engine crawlers can access and index the primary content.

   • Images and videos: We include the necessary HTML for these media elements in the initial server response, making them visible to crawlers.

2. Client-side loading for performance

   • Media asset loading: While the HTML for images and videos is server-rendered, the actual loading of these assets is deferred to the client-side. This approach helps maintain fast initial page loads while still providing SEO benefits.

   • Large interactive elements: Heavier components such as dataset visualizations and 3D models are loaded client-side to keep the initial page load quick.

While we may not see the benefits of this work immediately, I'm confident it will pay off in the long run. With all visible assets discoverable by search engines (including the content of them now!), we're building a stronger reputation and network of assets that can reach a much wider audience than the users on the platform.

That's all for now, and thanks for reading! Let's keep getting better every day.

Server-side code syntax highlighting is now fixed! Now you can get your syntax highlighting back in posts and conversations.