Make it faster!
summary
Wix measures real user performance across 100M sites (50M pageviews/day, 2B HTTP requests) by collecting production metrics (median DNS ~150ms, TTFB for media, KB/s, staged render times showing ~50% spent waiting for JS). Pipeline: single-pixel GET pipeline -> nginx logs -> Apache Flume -> Hadoop + Apache Spark -> dashboards/alerts; they use New Relic and Hana for redundancy. Developers use a performance API wrapper over W3C marks/measures (optional reporting). Practical wins: CDN + caching, service workers, prefetch/preconnect, async/defer, and HTTP/2 gave ~20% faster JS download in real data.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 0:25Overview
- 0:53About Dan
- 2:41Measuring Performance
- 4:03Running Performance Tests
- 5:13Keep it Real
- 5:43DNS Time
- 6:22Response Time
- 6:57Performance Time
- 9:11Time to First byte
- 10:33DNS Provider attack
- 11:12DNS lookup time graph
- 11:54Performance API
- 15:39Chrome Dev Tools
- 16:37New Relic Insights
- 18:16Build vs Buy
- 20:43Open Source
- 22:59BI Catalog
- 24:43Web Performance API
- 26:50Rail Model
- 30:46Bundles
- 32:10HTTP 2 impact
- 33:03Cache
- 39:31Summary
- 43:17Questions
related talks
30mImproving Load Time for 100 Million Websites - Wix Case-Study
18mWebsite performance from user perspective
31mEvery Millisecond Counts: Performance & UX
21mState of Performance
01h 04mNeed for speed 8, performance tuning of your web application
11m"Time is Money - The Measurable Value of Performance by Design"
36mHacking Web Performance
54mTipping the Scale