Performance
Client-side rendering
Also called CSR.
Client-side rendering is shipping a nearly empty HTML shell and letting JavaScript fetch data and draw the page in the browser. It trades server work for client work and a longer wait before anything appears.
How it is measured
Watch the sequence in a trace: HTML arrives, the bundle downloads and parses, the app fetches data, and only then does content render. The gap between First Contentful Paint and the data call finishing is the cost of the pattern.
View the page source or run curl. If the body holds a single root div and no article text, the content depends on script. Lighthouse's LCP and Total Blocking Time usually show the price on slower phones.
Worked example
A dashboard app returns a 3 KB HTML shell in 120 ms. The 480 KB bundle finishes parsing at 1,900 ms on a mid-range phone, then an API call returns at 2,450 ms. FCP is 1,950 ms and LCP is 2,700 ms, even though the server was quick.
Prerendering the login and pricing routes brings LCP on those pages to 1,300 ms. The dashboard behind login stays client rendered, where users stay for a long time and the shell is cached.
How it differs
Client-side rendering builds the page in the browser. Server-side rendering sends finished HTML for the first view. Hydration is the step that makes server HTML interactive. CSR has no hydration cost because nothing arrived to hydrate, but it also has nothing to show until script runs.
Common errors
Using CSR for marketing pages that need a fast first paint and search visibility. Shipping one large bundle with no route splitting. Waiting for data in a waterfall after the bundle instead of in parallel. Showing a blank screen instead of a skeleton. Assuming crawlers always execute JavaScript on time.
In practice
Check which routes truly need a logged-in app and which are content. Render content routes on the server or at build time, and keep the app shell for authenticated screens. Start the data fetch as early as the route is known, not after the component mounts.