If you are like me, your web journey began when everything was much simpler. Create an HTML page and some CSS, throw it up on an Apache server, and you were well on your way to a website. Flash forward (pun intended) to what you see on the web today: You must choose between a slew of different web libraries and frameworks that all attempt to solve problems in different ways.
How a site is rendered–whether at the client or at the server side–directly affects TTL and TTI. For example, with a server rendered page you may see the content sooner but it may take additional time for that page to become interactive.
Each approach has its pros and cons. While SSR (server-side rendering) can result in better initial load times, SEO benefits, and improved accessibility, it can result in higher server loads and less initial interactivity. CSR (client-side rendering) can result in faster page transitions and interactivity, while sacrificing initial load times, SEO, and accessibility benefits.
As mentioned above, the rendering technique that is used affects accessibility. Why is that? A few reasons you may see a degraded accessibility experience when using client-side rendering (CSR) include:
- Increased initial load times.
- CSR approaches generally update or change content after the initial page load, which may pose challenges for assistive technologies in detecting or announcing updates.
You may have also come across the term partial hydration. This is when the hydration process only hydrates small parts of the page that require updating. Astro Islands and React 18’s selective hydration come to mind in different implementations of this concept. A nice feature with React’s selective hydration is that it prioritizes what it is hydrated based on interactions within the page, such as a button click.
While these two implementations are similar in concept, they are different because React’s selective hydration is only available within React itself, whereas Astro’s partial hydration is part of the Astro framework which accommodates multiple frameworks.
React’s selective hydration would be effective when dealing with large, complex components that may require a lot of client-side processing. Astro’s partial hydration would be best suited when dealing with small, modular components that can be loaded on an as-needed basis.
A new feature in React 18 is the ability to stream HTML. This allows the rendering of a React component to begin on the server and incrementally send the HTML back to the client as it is generated. This will produce a faster initial load and a more responsive user experience because the user can begin interacting with the application as soon as the initial content is downloaded, while still asynchronously loading additional suspended chunks.
A perfect example of this would be an article that has comments below. You can load the critical piece of the page—the article—without waiting for the comments to load. Using suspense, you could instead display a spinner until the comments are ready. The following image shows this scenario:
While React’s streaming of HTML may bring a lot of benefits, it’s also important to note some potential downsides:
- Streaming HTML requires a server that supports HTTP/2 or newer and client-side browsers to support it as well. Older browsers or devices may not support this functionality.
- An application using streaming HTML may be more complex than one without and pose a steeper learning curve for a team not familiar with the different techniques being used.
- Streaming HTML can improve the initial load time, but it may require careful consideration of caching and performance strategies. These strategies may include managing server-side caching and rendering strategies to prevent server overload due to frequent streaming requests.
Qwik is another front-end framework that aims to improve the performance of applications by providing a unique server-side rendering solution. Qwik calls this unique solution resumable rendering.
The first thing to note is that Qwik is not React, nor does it use React. It does use JSX as its template syntax, which means components may look similar to ones created in React. But, you can also use React within Qwik with Qwik React to make transitions easier if you choose to do so.
Qwik avoids the need to hydrate the HTML returned by the server by serializing all the required information as part of the HTML during the SSR process. It also uses a global event handler that relies on event bubbling to intercept all events. This global event handler means Qwik doesn’t need to register handlers on individual DOM elements.
Image courtesy of builder.io docs
With hydration, all event handlers are created and attached before the event is triggered (eagerly). Whereas with Qwik, the creation of the event handler happens after the event is triggered on an as-needed basis (lazily). This is done by deserializing the event handler from the HTML which prevents duplication of the work already done by the server.
Qwik is definitely a tool to watch. With it being a relatively newer platform, it may be lacking from a community standpoint or ecosystem of tooling when compared with other frameworks. And because Qwik serializes its handlers as part of its HTML, it requires those to be eligible for serialization which may prove difficult for certain edge cases.
There are many front-end technologies available today, each with a slightly different approach for improving performance and user experience. When choosing which technique or combination of techniques best fits your needs, the answer unfortunately is “it depends”. Each and every use case is different, but choosing a familiar technique whose capabilities and limitations you understand is generally a good solution.