Rendering on the Web: Performance Implications of Application Architecture
summary
Compares architectures with concrete tooling and results: server render plus client hydration speeds first contentful paint but TTI still tracks bundle size; frameworks use render-to-string or render-to-node-stream for streaming (Spectrum reports big TTFB gains) while Node’s stream high water mark (~16 kilobytes) limits wins on tiny pages. Static builds (Gatsby, render-to-static-markup) cut runtime cost; progressive hydration (IntersectionObserver, Airbnb experiments, vue-lazy-hydration) defers component boot and noticeably reduces client-side TTI. Also covers SEO fixes (react-helmet, vue-meta), dynamic rendering and server-driven preloading of data and modules.
AI-written summary · about
chapters (15)
- 0:00Start
- 4:09Client-Side Rendering
- 5:43Performance
- 6:13Hydration
- 9:52First Input Delay
- 10:51Pre Rendering
- 13:59Streaming Server Side Rendering
- 14:57Spectrum
- 17:14Page Hydration
- 22:39Progressive Hydration
- 23:19Sample App
- 24:30View Lazy Hydration Plugin
- 26:55Mobile-Friendly Test
- 28:48Include Critical Content in Your Html Markup
- 29:22Dynamic Render
related talks
24mOptimising React’s TTI
44mServer Side Rendering from the trenches
21mImplementation and use cases of modern rendering patterns
40mThe state of frontend frameworks in 2023
32mStay Away From My Path!
25mProgressive Rendering – how to make your app render sooner
20mA Saga of Web Rendering Woes
48mClientside templates for reactive UI