Polish and Perf

Episode Summary

Executive Summary: The episode focuses on "polish and perf"—how to make a shipped web app faster, smoother, and less wasteful. Wes and Scott stress using real diagnostics like DevTools network tab, Lighthouse, and PageSpeed Insights to find large assets, slow server responses, unnecessary third-party scripts, and poor caching. They emphasize tackling the biggest bottlenecks first, especially images, embeds, analytics, and server-side caching.

Main Topics: Diagnosing performance with the right tools: The hosts recommend using Chrome DevTools Network tab, Lighthouse, PageSpeed Insights, and related tools to identify where time and bandwidth are being spent before making changes. Removing or replacing heavy third-party embeds: They discuss eliminating costly social and community embeds like Twitter, Facebook, and Discord when they add load, tracking, or broken behavior without enough value. Optimizing images and media: Large images and media are highlighted as common major bottlenecks; the hosts stress resizing, compressing, formatting correctly, and serving appropriately sized assets. Caching at the browser, CDN, and server levels: They explain how HTTP caching, route caching, CDN caching, and Redis-backed server caching can dramatically reduce repeat load times and backend work. Reducing unnecessary JavaScript and third-party work: The conversation covers removing unused scripts, reducing tracked/embed code, and moving non-essential dependencies like analytics off the main thread with tools like Partytown. Using real-world performance signals instead of vanity metrics: The hosts argue that numbers matter only in context; better than chasing a single score is understanding actual user experience, network behavior, and production load patterns. Continuous incremental optimization: They frame performance work as an ongoing process of chipping away at the largest problems, verifying improvements, and accepting "good enough" once the major pain points are resolved.

Key Arguments: Start by inspecting the Network tab because it reveals both file weight and time spent on server responses, letting you distinguish backend latency from oversized assets. Focus on the largest files first; shaving kilobytes from a tiny script matters less than fixing a multi-megabyte image or embed. Many social/third-party widgets are not worth their cost because users block them, they load extra JavaScript/fonts, and they can hurt performance more than they help. Caching is a high-leverage optimization: browser caching, CDN caching, and server-side caches like Redis can significantly improve repeat visits and reduce backend load. If a third-party resource is non-essential, consider replacing it with a static image, proxy, or serverless snapshot to avoid tracking and reduce runtime overhead. Performance metrics like PageSpeed scores are useful only when interpreted in context; real user experience and detailed network diagnostics are more reliable guides. Partytown-style offloading can move scripts such as analytics off the main thread, offering an easy win for reducing UI contention. Small, repeated improvements accumulate; even a one-second reduction across many loads can meaningfully improve user experience.

Data Points: PageSpeed score before Gatsby upgrade: 42 - Ryan Dahl reportedly ran Scott's site through PageSpeed Insights before upgrades. PageSpeed score after Gatsby upgrade: 96 - Scott says the site improved substantially after upgrading Gatsby. Syntax logo size: 500K - Wes found the logo to be the largest file on his site during a network sort. Desired logo size: 30K - Wes suggests the logo could probably be reduced to around this size. Cloudinary image reduction: about 10% of original size - Wes describes using Cloudinary auto-width/auto-format to shrink images dramatically. Caching duration example: 30, 60, 100 days - He suggests long-term caching for assets like a logo that rarely change. Build time on the latest Gatsby: 3 or 4 minutes - Wes says his build times improved, though still feel too slow. Target build time: instant / as I type - Wes says he wants builds to feel immediate. Typical build time for personal site: about a minute - Scott says his personal site builds in roughly this time. Emoji-based log signal: turtles - Scott mentions using logging that outputs emojis to indicate slow requests.

Pivotal Quotes: "What we're looking for in performance is we're looking for visibility and we're looking for big things." — Wes: He summarizes the core strategy for identifying performance bottlenecks. "What I'm worried less about is a number telling me that my thing is okay. And I'm worried more about like what that network when I'm refreshing my network cached and uncached..." — Scott: He explains why real diagnostic data matters more than a single score. "You save one second off of the majority of my page loads." — Wes: He describes the cumulative value of incremental optimization work.

Implications: Listeners should prioritize measurable, high-impact fixes over vanity scores: remove heavy embeds, compress media, cache aggressively, and use diagnostics to target bottlenecks. For teams, performance should be treated as ongoing product work, not a one-time polish step.