![]() ![]() There is a longstanding debate over the correct applications of server rendering versus client-side rendering, but it’s important to remember that you can opt to use server rendering for some pages and not others. Whether server rendering is enough for your application largely depends on what type of experience you are building. However, there is one primary drawback to this approach: generating pages on the server takes time, which can often result in a slower Time to First Byte (TTFB). Even when third-party JS can’t be avoided, using server rendering to reduce your own first-party JS costs can give you more " budget" for the rest. With server rendering, users are unlikely to be left waiting for CPU-bound JavaScript to process before they can use your site. This approach can work well for a large spectrum of device and network conditions, and opens up interesting browser optimizations like streaming document parsing. This makes sense, since with server rendering you’re really just sending text and links to the user’s browser. Running page logic and rendering on the server makes it possible to avoid sending lots of JavaScript to the client, which helps achieve a fast Time to Interactive (TTI). Server rendering generally produces a fast First Paint (FP) and First Contentful Paint (FCP). This avoids additional round-trips for data fetching and templating on the client, since it’s handled before the browser gets a response. Server rendering generates the full HTML for a page on the server in response to navigation. TTI: Time To Interactive - the time at which a page becomes interactive (events wired up, etc).FCP: First Contentful Paint - the time when requested content (article body, etc) becomes visible.FP: First Paint - the first time any pixel becomes visible to the user.TTFB: Time to First Byte - seen as the time between clicking a link and the first bit of content coming in.Prerendering: running a client-side application at build time to capture its initial state as static HTML.Rehydration: “booting up” JavaScript views on the client such that they reuse the server-rendered HTML’s DOM tree and data.CSR: Client-Side Rendering - rendering an app in a browser, generally using the DOM.SSR: Server-Side Rendering - rendering a client-side or universal app to HTML on the server.The differences between these approaches help illustrate the trade-offs of rendering on the web through the lens of performance. In order to better understand the architectures we’re choosing from when we make this decision, we need to have a solid understanding of each approach and consistent terminology to use when speaking about them. Broadly speaking, we would encourage developers to consider server rendering or static rendering over a full rehydration approach. Our understanding of this space is informed by our work in Chrome talking to large sites over the past few years. This can be difficult, since there are a number of different ways to build a website. One of the core decisions web developers must make is where to implement logic and rendering in their application. Streaming server rendering and Progressive RehydrationĪs developers, we are often faced with decisions that will affect the entire architecture of our applications. ![]() A Rehydration Problem: One App for the Price of Two.Combining server rendering and CSR via rehydration. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |