Web Performance Daybook Volume 2

Chapter 3. Why Inlining Everything Is NOT the Answer

Guy Podjarny

Every so often I get asked if the best frontend optimization wouldn’t be to simply inline everything. Inlining everything means embedding all the scripts, styles, and images into the HTML, and serving them as one big package.

This question is a great example of taking a best practice too far. Yes, reducing the number of HTTP requests is a valuable best practice. Yes, inlining everything is the ultimate way to reduce the number of requests (in theory to one). But NO, it’s not the best way to make your site faster.

While reducing requests is a good practice, it’s not the only aspect that matters. If you inline everything, you fulfill the “Reduce Requests” goal, but you’re missing many others. Here are some of the specific reasons you shouldn’t inline everything.

No Browser Caching

The most obvious problem with inlining everything is the loss of caching. If the HTML holds all the resources, and the HTML is not cacheable by itself, the resources are re-downloaded every time. This means the first page load on a new site may be faster, but subsequent pages or return visitors would experience a slower page load.

For example, let’s look at the repeat visit of the New York Times’ home page (Table 3-1, Figure 3-1). Thanks to caching, the original site loads in 2.7 seconds. If we inline the JavaScript files on that page, the repeat visit load time climbs to 3.2 seconds, and the size doubles. Visually, the negative impact is much greater, ...