Fundamentals × What Makes a Website Slow?

Episode Summary

Executive Summary: The episode is a fundamentals deep dive into what makes websites slow, spanning the full request lifecycle from DNS and server generation to payload size, rendering, latency, caching, and browser-blocking behavior. The hosts use real examples, especially a large uses.tech homepage, to explain practical debugging steps and optimizations such as compression, indexing, concurrency, image/CDN caching, lazy loading, and deferring scripts.

Main Topics: Server generation time and backend bottlenecks: They explain how request latency can come from DNS lookup, cold starts, routing, database queries, and slow server-side logic. Debugging starts in DevTools/network timing and can continue with logs, profiling, and function timing. Payload size: HTML, assets, and compression: A large HTML document or oversized assets can slow perceived load time. They discuss gzip/brotli compression, duplicate markup compressing well, and why images and videos are often the biggest hidden costs. Caching across layers: The hosts break down caching in memory, Redis, browser cache, CDN cache, and even local/session storage, emphasizing that caching is fundamentally about storing data in a faster-to-read location for later use. Render-blocking CSS and JavaScript: They explain how CSS and script tags can pause rendering, causing slow first paint or flash of unstyled content. Solutions include inlining critical CSS, using media attributes, and loading JS with async/defer or ES modules. Virtualization and lazy rendering/loading: For pages with huge DOMs or long lists, they discuss virtualization, lazy loading images, and CSS content-visibility:auto as ways to only render what is visible, improving initial paint and responsiveness. Latency and geography: Latency is framed as the time for data to travel between computers, influenced by server location, edge functions, Bluetooth, and hardware. They note the tradeoff between moving compute closer to users and keeping databases close to compute. Perceptual performance issues: Beyond actual speed, the hosts cover flashes of incorrect theme, signed-out states, and font loading shifts. These can make an app feel slow even when the underlying data is quick, so server-rendered state and careful font strategy matter.

Key Arguments: Slow websites can stem from many layers, not just JavaScript; server logic, databases, HTML size, images, and CSS all matter. Network timing in DevTools is the first place to identify whether the bottleneck is server response, asset download, or client parsing. Database performance improves when queries are narrowed, indexed properly, run concurrently when independent, and cached when repeated. Compression dramatically reduces transfer size; large HTML can be acceptable if it compresses well, but it still indicates redundant markup. Images and video are often the easiest high-impact optimization targets, especially when resized, compressed, lazy loaded, or served in modern formats via a CDN. Caching should be used at the right layer: server memory/Redis for compute-heavy generation, CDN/browser for static assets, and local/session storage for client-side persistence. Render blocking is a major source of slow perceived load; CSS and JS should be treated carefully using inlining, defer, async, and modules. Virtualization and content-visibility allow the browser to avoid rendering offscreen DOM, significantly reducing initial paint costs on large pages. Perceived slowness can be caused by flashes of unstyled content, incorrect theme/account state, or font swaps even if the underlying request is fast. Sometimes the best solution is simply to reduce work: fewer elements, fewer requests, smaller assets, and more intelligent defaults from tools/frameworks.

Data Points: uses.tech homepage size: 1.34 MB HTML uncompressed - Wes describes the homepage for a large directory list as very large due to nearly 700 entries. uses.tech compressed transfer size: 124 KB - The same 1.34 MB HTML compresses heavily over the wire via gzip/brotli. uses.tech homepage paint time before optimization: 3.8 seconds - Wes reports initial paint before adding content-visibility optimization. uses.tech homepage paint time after optimization: 1.7 seconds - Adding content-visibility:auto roughly halved initial paint time. uses.tech growth: ~700 people - The directory grew from about 30 people to nearly 700, increasing page weight. Cold start latency: 50 milliseconds up to 1 second - Serverless/edge functions may take this long to wake up before handling a request. Example normal HTML size: 73 KB - Wes checked a typical site and found its HTML payload was far smaller than uses.tech. CNN HTML size compressed: 165 KB - Used as an example of a dense real-world site. CNN HTML size uncompressed: 1.19 MB - Shown as the uncompressed equivalent of the compressed HTML payload. Podcast/video channel audience: Nearly 5 million subscribers - Referenced for the Three Blue One Brown YouTube channel.

Pivotal Quotes: "What makes a website slow?" — Wes Boss: Sets up the episode’s core fundamentals question. "It's not a JavaScript issue. There's not really much JavaScript on the page. It's not a CSS issue. It kind of is a CSS issue. It's a HTML issue." — Scott Tolinski: Explaining why the uses.tech homepage is slow: the problem is primarily DOM/HTML volume. "If your site is slow, your users are not going to be happy." — Wes Boss: Sponsorship transition and framing for why performance matters.

Implications: Performance work should be holistic: optimize server logic, transport, rendering, and perceived UI state together. Small structural improvements—compression, caching, deferred scripts, virtualization, and leaner assets—can yield major gains and better UX.