Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Dynamic Generation

Sergey Chernyshev
January 24, 2019
44

Dynamic Generation

Sergey Chernyshev talks about the reasons why we prefer generation+deployment workflow to calculating output in real time as users request information. We review the difference between generation and caches and why the former is more preferred strategy while latter is often misleading with it’s declared ease of implementation.

And in the end we look at the range of currently available solutions, from static generation to API-driven applications within JAMstack and introduce a new concept of “Dynamic Generators” and discuss how one can build a system that combines benefits of “generation” workflow and “dynamic” data to help expand fast User Experiences all the way across the full range of web application.

Sergey Chernyshev

January 24, 2019
Tweet

Transcript

  1. Sergey Chernyshev Principal Engineer @ Meetup January 24, 2019 @

    JAMstack NYC Meetup • Care about
 UX speed • Organize
 NY Web Performance Meetup Group • Work on
 Web Platform team @ Meetup
  2. • No PHP/Python/Ruby/ Java/ASP.Net/Node runtime! • No servers! • No

    databases! • Faster for users! Why Do We Generate?
  3. Server-Side Rendered HTML • 1240ms @ Average • 3910ms @

    95%ile Static Resources • 483ms @ Average • 629ms @ 95%ile Generation is Faster • Bottleneck for the whole page • Much faster on average • Significantly less variable
  4. • Carousell: -65% page load => +63% SEO, 3x ad

    clicks (2019) • Pinterest: -40% wait time => +15% SEO, +15% conversion (2017) • DoubleClick: 5s vs 19s on mobile => 2x ad revenue (2016) • Trainline: -300ms latency => +$11.5M / year revenue (2016) • Etsy: +160Kb => +12% bounce rate (2014) • Mozilla: -2.2s => +15.4% Downloads (2010) • Google: +400ms => -0.21% searches after experiment! (2009) • Netflix: +GZip => -43% Traffic cost (2008) • Amazon: +100ms => -1% revenue (2008) • Google: +500ms => -25% searches (2006) Stats @ WPOstats.com
  5. • Renders on Read • Time To Live (TTL) •

    Stale for TTL/2 time • Cache hit ratio < 100% • Needs origin for misses • Renders on Write • Infinite TTL • Stale until updated • 100% offload Cache Generation
  6. • API call • stale-while-revalidate • Surrogate keys for dependency

    tracking • Cache evictions • Shared CDN nodes • Long tail content • Deployment is invalidation • Serve stale while building • Incremental builds need dependency tracking • Storage & CPU cost $ • Each view is stored • Generates on write Invalidation ~ Generation
  7. Static Generators
 with data in git Static with
 In-browser
 API

    calls Static Generators with API calls during build “Dynamic” Generators
  8. • Maps changes to file names and edge cache keys

    • Sets renderer variables • auth / role • segmentation • language • Triggers incremental builds Dependency Manager
  9. • Know your real freshness / staleness requirements • Learn

    your existing data update cycle • Map data changes to outputs, list variations • Identify personalized vs. segmented content • Build your Dynamic Generator • Make your users happy! To Do