Render Pattern

[weikee94]

Web Vitals

| Abbreviation | Full Form | Description | |--------------|----------------------------------|-------------------------------------------------------------------------------------| | TTFB | Time To First Byte | Time it takes for a client to receive the first byte of page content | | FCP | First Contentful Paint | Time it takes the browser to render the first piece of content after navigation | | LCP | Largest Contentful Paint | Time it takes to load and render the page's main content | | TTI | Time To Interactive | Time from when the page starts loading to when it's reliably responding to user input quickly | | CLS | Cumulative Layout Shift | Measures visual stability to avoid unexpected layout shift | | FIP | First Input Delay | Time from when the user interacts with the page to the time when the event handlers are able to run | | Term | Description | |----------------|-------------------------------------------------------------------------------------------------------------| | Compiling | Converting JavaScript into native machine code | | Execution time | The time it takes to execute the previously fetched, parsed, and compiled data | | Hydration | Attaching handlers to a DOM node whose HTML contents were server-rendered, making the component interactive | | Idle | The browser's state when it's not performing any action | | Loading time | The time it takes to fetch the data from the server | | Main thread | The thread on which the browser executes all the JavaScript, performs layout, reflows, and garbage collection | | Parsing | Converting an HTML source into DOM nodes, and generating an AST | | Processing | Parsing, compiling, and executing the previously fetched data | | Processing time| The time it takes to parse and compile the previously fetched data |

[weikee94]

Client Side Rendering

Render your application's UI on the client   TTFB: The Time To First Byte can be fast, since the initial HTML does not contain large components. FCP: The First Contentful Paint can occur once the JavaScript bundle has downloaded, parsed, and executed its contents. TTI: The Time To Interactive can occur once the JavaScript bundle has downloaded, parsed, and executed its contents to bind the event handlers to the components. LCP: The Largest Contentful Paint can occur at the same time as the First Contentful Paint, provided there aren't any large components such as large images or videos.

[weikee94]

Static Rendering

With static rendering, the HTML contents are pre-generated at build time.   TTFB: The Time To First Byte can be fast, since the initial HTML does not contain large components. FCP: The First Contentful Paint can occur once the JavaScript bundle has downloaded, parsed, and executed its contents. TTI: The Time To Interactive can occur once the JavaScript bundle has downloaded, parsed, and executed its contents to bind the event handlers to the components. LCP: The Largest Contentful Paint can occur at the same time as the First Contentful Paint, provided there aren't any large components such as large images or videos. | Term | Description | |---------------|-----------------------------------------------------------------------------------------------------------------------| | Cacheability | Pre-rendered HTML files can be cached and served by a global CDN. Users can benefit from quick responses when they request a page, as the request doesn't have to go all the way to the origin server. | | SEO | The HTML content can be rendered by web crawlers with no extra effort. | | Availability | Static is always online. Even if your backend or data source (e.g. database) goes down, your existing pre-rendered page will still be available. | | Backend load | With Static Generation, the database or API wouldn't need to be hit on every request. Page-rendering code wouldn't have to run on every request. | | Dynamic data | If a statically generated page needs dynamic content, for example from an external data source, it needs to fetch this client-side. This can result in a long LCP, and higher server costs. |

[weikee94]

Incremental Static Regeneration

Pre-render certain pages, and render the other pages on-demand Besides only pre-rendering a subset of pages, we can also automatically invalidate cached pages based on a stale-while-revalidate approach. When a user requests a page that is stale - meaning it's been in cache for longer than the provided number that it should be cached for - a regeneration is triggered in the background. While this is happening, the user gets to see the stale page, but they're able to see the updated content on subsequent requests.  We can implement Incremental Static Regeneration using Next.js's getStaticProps method in combination with the getStaticPaths method. ``` import { Listings, ListingsSkeleton } from "../components"; export default function Listing(props) { return } export async function getStaticProps(props) { const res = await fetch(`https://my.cms.com/listings/${props.params.id}`); const { listing } = await res.json(); return { props: { listing } } } export function getStaticPaths() { const res = await fetch(`https://my.cms.com/listings?limit=20`); const { listings } = await res.json(); return { params: listings.map(listing => ({ id: listing.id })), fallback: false } } ```  TTFB: The Time To First Byte can be fast, since the initial HTML does not contain large components. FCP: The First Contentful Paint can occur once the HTML has been parsed and rendered. LCP: The Largest Contentful Paint can occur at the same time as the First Contentful Paint, provided there aren't any large components such as large images or videos. TTI: The Time To Interactive can occur once the HTML has been rendered, and the JavaScript bundle has been downloaded, parsed, and executed its contents to bind the event handlers to the components.

[weikee94]

Server Side Rendering

With Server-Side rendering, we can generate HTML on the server (or serverless function) on every request.  When server-side rendering an application, we need a method to render HTML from our React components on the server, and hydrate the non-interactive HTML on the client. One way to render HTML on the server, is by using the renderToString method. This function returns an HTML string corresponding to the React element. The HTML can then be rendered to the client for a faster page load, and hydrated with the hydrateRoot method on the client. [stackblitz](https://stackblitz.com/edit/nextjs-hpsp3x?file=pages%2Findex.js)  TTFB: The TTFB can be slow, since the page still has to be generated on-demand. FCP: The First Contentful Paint can occur once the HTML has been parsed and rendered. LCP: The Largest Contentful Paint can occur at the same time as the First Contentful Paint, provided there aren't any large components such as large images or videos. TTI: The Time To Interactive can occur once the HTML has been rendered, and the JavaScript bundle has been downloaded, parsed, and executed its contents to bind the event handlers to the components.

[weikee94]

Streaming Server Side Rendering

Generate HTML on every request, sending it down piece by piece  TTFB: The TTFB can be slow, since the page still has to be generated on-demand. FCP: The First Contentful Paint can occur once the HTML has been parsed and rendered. LCP: The Largest Contentful Paint can occur at the same time as the First Contentful Paint, provided there aren't any large components such as large images or videos. TTI: The Time To Interactive can occur once the HTML has been rendered, and the JavaScript bundle has been downloaded, parsed, and executed its contents to bind the event handlers to the components. | Feature | Description | |----------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------| | Performance regardless of page size | With Streaming SSR, we can have a fast TTFB since the first byte reaches the client soon after rendering starts on the server. This results in a good TTFB for any page of any size. | | Network Backpressure | If the network is clogged and not able to transfer any more bytes, the renderer gets a signal and stops streaming till the network is cleared up. Thus, the server uses less memory and is more responsive to I/O conditions. This enables your Node.js server to render multiple requests at the same time and prevents heavier requests from blocking lighter requests for a long time. As a result, the site stays responsive even in challenging conditions. | | Support | Not all runtimes support HTTP streaming, which is necessary for streaming SSR. |