Yelp knows their resources are better than your phone.
So they did all the server side rendering themselves
⚡TLDR;
Yelp has been doing Server Side Rendering (SSR) for awhile. But it wasn’t optimized so they made it more optimized.
Do the SSR work on worker threads instead of the main thread
Switch to client-side rendering if server-side rendering would fail.
👏 Yelp’s problem with SSR
SSR was done on a single service and put a lot of stress on that server. Which is one of the biggest cons to server side rendering.
🧠 How it used to happen
There was a single service that built all the server-side rendering bundles.
This meant there was a bundle for each and every entry point to a yelp page on the same server
This meant a server wouldn’t be started until it built all of them (yikes).
♻️ It got so slow that their own alarms marked the server as unhealthy and restarted the server.
🔧 Here’s the requirements
Requirement #1: Don’t block the main thread trying to build the HTML. This also solves the server start problem.
Requirement #2: Fail-fast and faster than that. If SSR doesn’t work, go with client-side rendering.
🚅 Processing the process diagram
It looks like a complicated diagram but let’s simplify it into byte-sized chunks starting with the request handler.
The request handler: Gets some request from the client and figures out if there’s enough time to do SSR, else do regular client-side rendering
The rendering queue: If there’s enough time, add a task to the queue for worker threads (not main threads) to build the html for the webpage.
The IPC handler: An inter-process communicator that takes the HTML and sends it back to the request handler to then send it to the client.
🏆 How good did it get?
From the article:
An average reduction of 125ms p99 when server side rendering a bundle.
Improved service startup times from minutes in the old system to seconds by reducing the number of bundles initialized on boot.
Increased observability since each shard is now responsible for rendering one bundle only, allowing teams to more quickly understand where things are going wrong.
Created a more extensible system allowing for future improvements like CPU profiling and bundle source map support.
💰 HELP WANTED
This newsletter has grown to 10,500 → 13,000 AMAZING READERS. It’s grown to a scale that a single person can’t maintain all of it on their own.
If you’re interested in being a byte-sized design writer, apply here!
📝 Official Article
(Links to official article and sources are available to paid subscribers. They help maintain and support this newsletter!)
Keep reading with a 7-day free trial
Subscribe to Byte-Sized Design to keep reading this post and get 7 days of free access to the full post archives.