The Challenges and Pitfalls of Server Side Rendering
summary
Wix moves nearly 100 million sites from CSR to SSR and measures a ~60% improvement in time‑to‑visible after three years and two failed attempts. Engineering fixes include using WeakMap per session to avoid mutable globals and memory leaks, restarting Node less often, and adding ESLint with custom rules to block unguarded DOM access. Expect hydration to leave pages visible but slower to become interactive, require extensive tests, new DevOps skills, and enough engineers and time to hunt subtle server‑side leaks and diverging HTML.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 0:46About Dan
- 1:26What is Server Side Rendering
- 3:23Isomorphic JavaScript
- 3:49Hydration
- 4:53Benefits
- 6:24Impact
- 7:29Supported frameworks
- 8:09It was not that easy
- 8:45Challenges
- 11:58What can you do
- 12:40JavaScript context
- 14:19Global variables
- 15:35Solution
- 16:23Memory Leaks
- 18:10Tools
- 18:21Test First
- 20:35Time to Visible vs Time to Interactive
- 22:38Multiroute Rendering
- 24:16Dis diverges
- 24:52Un unjustified diverges
- 27:22Summary
- 27:51Takeaway
related talks
44mServer Side Rendering from the trenches
04mA few things to know about SSR
45mThe War of HTML Rendering: SSR, CSR and Hybrid Rendering — Which Is Fastest?
30mImproving Load Time for 100 Million Websites - Wix Case-Study
30mRendering Revealed
20mCSR, SSR, SSG, ISR, and OMG. WTF? BBQ!
13mStraight Talk About Server-Side Rendering
25mServer-side Rendering with ReactJS: Win or Lose
