How is this Website so fast!?

Source: How is this Website so fast!?, Wes Bos, 13:39, uploaded 2024-10-18, playlist index 484.

McMaster-Carr is a roughly century-old company with a catalogue website that looks old and feels unusually quick. Wes Bos starts from a post by Kenneth Castle claiming that it might be the fastest website on the internet, then inspects the site to work out why its pages appear before the browser has had much time to do anything. The explanation is a long chain of small decisions about when HTML, CSS, images, JavaScript, and cached responses become available.

HTML arrives before the application

McMaster-Carr sends rendered HTML from the server. Bos finds no JavaScript framework responsible for building the first page. The browser receives ordinary HTML and can render it with very little work of its own.

The site also fetches the next page when the pointer hovers over a link. Bos clears the network panel, moves over a set of catalogue links, and sees requests for their HTML begin before he clicks. When he follows one, the page content appears before the URL changes. The site has already fetched the response and replaces the part of the page that changes, whilst the navigation, order area, and shopping cart remain in place. pushState updates the address after the new shell is visible.

That sequence removes several kinds of waiting from the click itself. The server has rendered the page, the browser has downloaded it, and the site can insert the changing part without rebuilding the whole document. Bos presents the technique as a familiar browser mechanism arranged with unusual care.

Caches at the edge and in the browser

Bos reads the response headers and finds evidence of aggressive caching. He points to hit-or-miss cache headers, an Akamai-related header, and Squid Cache, which he describes as a proxy that stores HTML. The pre-rendered responses can therefore sit in a CDN near visitors instead of being generated from the origin for every request.

The browser keeps another copy through a service worker. In one inspection, the homepage takes about 65 milliseconds to arrive from the server. After a refresh, Bos sees roughly 7 milliseconds because the service worker can intercept the request and return its cached version. He connects this pattern with offline progressive web apps and guesses that the service worker also supports McMaster-Carr’s iOS and mobile applications. That application claim is his inference from the behaviour he sees.

The site uses a service worker for ordinary HTML, which makes the cache useful on the next navigation rather than only for static images or scripts. The CDN and the browser each shorten a different part of the request path.

The browser gets dependencies early

The source contains clues about ASP.NET, including capitalised names in the markup. Bos also finds link preloads for the logo and web fonts, along with DNS prefetch hints for domains that serve images. A preload tells the browser to fetch a known dependency before parsing reaches the stylesheet or element that eventually asks for it. DNS prefetch resolves a hostname in advance, so the later image request can skip that lookup.

Without those hints, the browser can discover the same files through a chain of dependent requests. It downloads the HTML, parses enough to find the CSS, parses the CSS to find the font, and only then starts the font request. The page spends its early time discovering work. McMaster-Carr declares some of that work in the document head, which shortens the waterfall.

Critical CSS and the first visible page

Bos searches the document for a stylesheet link and finds the page’s initial CSS inside a style tag before the body. He calls this critical CSS. The browser has the rules needed for the first layout as soon as it starts parsing the HTML, whilst additional CSS can arrive later for the parts of the site that need it.

In the performance panel, Bos measures a largest contentful paint of about 174 milliseconds. He attributes the clean result to the order of operations: the browser already knows the first layout, so images and later styles do not repeatedly move the visible page. The recording shows a brief change whilst images download, then leaves the rest of the page in place.

Fixed spaces for images and one sprite

The catalogue reserves width and height for its images. When a browser lacks an image’s dimensions, it can lay out a zero-sized space, download the image, and push the following content down when the image arrives. That creates another render and visible movement. An explicit size gives the image a place before its bytes arrive, so the loaded image fills an existing rectangle.

McMaster-Carr also uses an old image-sprite technique. Bos opens one asset and finds many of the page’s small images arranged inside a single file. The browser downloads one image, about 93 KB in his example, then shows the required pieces through background positioning. A single request reduces the overhead of fetching many small assets.

JavaScript arrives by page

The network panel still contains plenty of JavaScript. Bos filters the requests and sees a browser extension mixed in with the site’s files, then notices that the files differ from page to page. Product-page responses contain metadata listing the JavaScript include paths they need. He infers that a server-side tool splits the bundle by page and adds only the dependencies required for the current view.

Bos calls this dependency injection in a post that drew criticism, although the useful observation is simple: a catalogue page does not need to download every behaviour used by every other page. He says server-rendered React frameworks make this arrangement easy, whilst a great many sites send the same complete JavaScript bundle everywhere because finding the exact dependency set takes work.

Old libraries, careful ordering

The code includes YUI, Yahoo’s old JavaScript and CSS library, with a copyright date of 2008. It also loads jQuery. Bos estimates that one page includes about 800 KB of JavaScript. The age of the libraries does not decide the first impression because the HTML can arrive and render before that code blocks the page or triggers a large amount of client-side work.

He finds window.performance and performance.mark calls in the scripts, which suggest that the site measures its own timings closely. His conclusion is about ordering rather than fashion: a site can use old ASP technology, YUI, and jQuery whilst the browser still receives the important HTML first. Newer frameworks can use the same priorities.

The slow catalogue lookup

The site does have slow moments. Bos assumes that a catalogue containing around 700,000 products needs database lookups, rendering, and cache work that cannot always finish immediately. One page shows a spinner for a while, although the delay remains tolerable on his fast connection.

The speed techniques matter because the people using the catalogue need exact answers. Bos imagines machinists and fabricators looking for a lid-support hinge with gas springs, a 392-degree operating range, and a 19.49-inch version. He describes users working from a six-year-old iPhone inside a dirty OtterBox and says that an awkward search can send them to the phone or back to a paper catalogue. A fast shell gives the user something to work with whilst the deeper product query catches up.

Limits of the inspection

The video records Bos’s inspection of the site on 2024-10-18. The figures are momentary observations from his browser and network panel, not an independent performance study. The source provides no reproducible test conditions, response samples, cache configuration, or citations for the product count and the technical history of the site. Some details remain inferences, especially the service worker’s role in the mobile apps and the backend process that assembles page-specific assets.

The durable point is the sequence Bos observes. McMaster-Carr makes the first response useful before JavaScript becomes necessary, predicts the next requests, stores HTML close to the user, reserves layout space, and gives later code a narrow job. The site feels fast because the browser spends its early work on the page a person can see.