Statically Generating Performance

When Harry's launched Flamingo, a women's care brand, we invested in static rendering with Gatsby to deliver the site's frontend in a scalable and performant way. This talk explores the differences between server-rendering and static-rendering for web frontends, and lays out the architecture for shopflamingo.com.

It discusses the importance of building a performance culture through monitoring and automation, and how building for performance helps ensure that sites are accessible for users, regardless of their access to fast networks and devices.

Versions delivered at
NY Web Performance (4/18/19): https://www.meetup.com/Web-Performance-NY/events/259982710/
Dev Stackup (3/13/19): http://stackuptalks.com/dev/2019/3/4/dev-stackup-strategies-for-increasing-performance

Transcript

1. Statically Generating Performance Tim Brown @_brimtown
2. Tim Brown @_brimtown
3. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
4. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
7. Goals Deliver a mobile-first, highly interactive experience
8. Our Needs We knew we needed scalability and web performance
9. Web Performance Impacts ecommerce conversion rate and SEO
10. harrys.com (2013 – present )
12. Original Stack Launched on Magento, rewritten in Rails
13. Harry’s Architecture Monolith, frontend and backend coupled together
14. Inflection Point Main focus on scalability and server performance
15. Server Performance
16. Harry’s Page Rendering Some pages written in Rails ERB templates
17. Harry’s Page Rendering More interactive pages written with MooTools, then React
18. Harry’s Page Rendering As more UI moved to React, noticed more layout jank
20. Deeper Understanding Time to rethink performance, starting with page rendering
21. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
22. Server-Side Rendering Traditional Rendering
23. Server Rendering Architecture User
24. Server Rendering Architecture User Server
25. Server Rendering Architecture User Server GET harrys.com/blades
26. Server Rendering Architecture User Server GET harrys.com/blades Data
27. Server Rendering Architecture User Server GET harrys.com/blades Data Page Templates
28. Server Rendering Architecture blades.html User Server GET harrys.com/blades Data Page Template s Page Templates
30. Server Rendering Architecture blades.html User Server GET harrys.com/blades Data Page Template s Page Templates
31. Server Rendering Architecture blades.html Data User Server GET harrys.com/blades Page Template s Page Templates
32. Server Rendering: Pros Complexity scales to large numbers of pages ✅
33. Server Rendering: Pros Quick initial render of the page ✅
34. First Meaningful Paint (FMP) Time it takes for the primary above-the-fold content to render
36. Server Rendering: Cons Server infrastructure needs to scale with traffic ❌
37. Server Rendering Architecture blades.html Data User Server GET harrys.com/blades Page Template s Page Templates
38. Server Rendering: Cons Takes time to generate a page on the fly ❌
39. Time To First Byte (TTFB) Time between the request being made and initial data being received
40. Server Rendering Architecture blades.html Data User Server GET harrys.com/blades Page Template s Page Templates Time to First Byte (TTFB)
41. Time to First Byte Distance from server (latency) also affects TTFB
42. Client-Side Rendering Traditional Rendering
43. Server-Side Rendering Architecture blades.html Data User Server GET harrys.com/blades Page Template s Page Templates
44. Client-Side Rendering Architecture blades.html Data User Server GET harrys.com/blades Page Template s Page Templates bundle.js
47. Client-Side Rendering: Pros Author pages with JavaScript frameworks ✅
48. Client-Side Rendering: Pros Ability to decouple frontend and backend ✅
49. Client-Side Rendering: Cons First Meaningful Paint can be slower than plain HTML ❌
51. Page Weight JavaScript is the single most expensive asset you can ship
53. Client-Side Rendering: Cons Page interactivity can suffer with too much JavaScript ❌
54. Time To Interactive (TTI) Time it takes for the page to be ready to respond to user input
55. Server-Side Client-Side Serving (TTFB) ✅ Rendering (FMP) ✅ ❌ Interactivity (TTI) ✅ Authoring ❌ ✅ Operations ❌ ❌
56. Flamingo Needs #1: Deliver great TTFB and FMP
57. Flamingo Needs #2: Render a small number of pages that don’t change often
58. Flamingo Needs #3: Minimize operational overhead and complexity
59. Flamingo Needs #4: Author pages entirely with React
60. Architecture Is there an alternate architecture that meets our needs?
61. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
62. Static Rendering Architecture Data Build Server Page Template s Page Templates
63. Static Rendering Architecture blades.html Data Build Server Page Template s Page Templates
64. Static Rendering Architecture blades.html Data Build Server Page Template s shave-set.html Page Templates
65. Static Rendering Architecture blades.html Data Build Server Page Template s shave-set.html homepage.html Page Templates
66. Static Rendering Architecture User
67. Static Rendering Architecture User GET shopflamingo.com/blades
68. Static Rendering Architecture User GET shopflamingo.com/blades blades.html shave-set.html homepage.html
69. Static Rendering Architecture User GET shopflamingo.com/blades blades.html shave-set.html homepage.html
70. Static Rendering Architecture User GET shopflamingo.com/blades blades.html shave-set.html homepage.html blades.html
71. An Analogy Restaurant vs. Catering
73. Gatsby 1. Author in React 2. Render to HTML 3. Serve static files
74. Server-Side Client-Side Serving (TTFB) ✅ Rendering (FMP) ✅ ❌ Interactivity (TTI) ✅ Authoring ❌ ✅ Operations ❌ ❌
75. Server-Side Client-Side Static Serving (TTFB) ✅ ✅ Rendering (FMP) ✅ ❌ ✅ Interactivity (TTI) ✅ Authoring ❌ ✅ ✅ Operations ❌ ❌ ✅
76. Flamingo Frontend Architecture
77. Flamingo Frontend Architecture
78. Flamingo Frontend Architecture merge
79. Flamingo Frontend Architecture merge publish
80. Flamingo Frontend Architecture merge build publish
81. Flamingo Frontend Architecture merge build serve publish
82. Operational Benefits Static page generation means we can be fully “serverless”
83. Static Rendering: Pros Pushes all latency and scaling to the CDN
84. Cache Invalidation Can set very long cache times since everything is static
85. Cache Invalidation Automatically invalidate changed files on publish
86. Everything Else Many other concerns outside of just rendering
87. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
88. JavaScript
89. JavaScript JavaScript is the single most expensive asset you can ship
90. JavaScript: Code Splitting by Route app.js homepage.js about-us.js product--blades.js product--shave-set.js ...
92. CSS
93. CSS With traditional CSS, hard to know what’s being used
94. CSS: Code Splitting by Component Code split with styled-components, render to plain CSS
96. Images
97. Images: “Resolution Switching” Serve different images based on screen size
98. Images: srcset and sizes
99. Images: Formats Serve WebP to browsers that support it, with fallbacks
100. Images: Loading Lazy-load images below the fold to reduce page weight
102. Fonts
103. Fonts: Preloading Preload critical fonts to minimize “flash of unstyled text”
105. Fonts: Subsetting Subset fonts based on which characters are actually being used
106. Compression
107. Compression: GZIP vs. Brotli Compress assets with Brotli for ~20% smaller file sizes
109. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
110. Automation Automate as much performance as you can
111. Automation Automation means more time shipping features
112. Monitoring Keeping a site fast is just as important as building it fast
113. Synthetic vs. Real-User Monitoring Synthetic for trends, RUM for user insights
115. Speed as a Feature When comparing speed, 20% faster is noticeable to users
116. Flamingo First Meaningful Paint Comparison Competitors / other ecommerce
118. Metrics Prioritize metrics that are tied to user experience
119. RUM Problems Many important RUM metrics aren’t available from Safari
120. RUM Problems RUM with single-page apps means you have to define “done”
121. Process Use performance budgets to align site goals with users
122. H’istory Optimizing the Rest Traditional Rendering Automation & Measurement Static Rendering The “Why?” 1 2 3 4 5 6
123. Engineers Web performance is both quantitative and qualitative
124. Business Good web performance helps business metrics
125. Users Web performance is about users
126. Users Web performance determines which users can use your site
127. Hello there, Sincerely, [redacted] From beautiful Grand Lake, Oklahoma! “I am a very heavy online shopper. Living in a small resort town, I buy literally every single thing we need online except for fresh perishables.”
128. Hello there, Sincerely, [redacted] From beautiful Grand Lake, Oklahoma! “Your website conveyed a sense of a quick and uncomplicated transaction, and one that was built for mobile users like me.”
129. Users Building for performance allows you to serve all users
130. Thank You Tim Brown @_brimtown