Every so often I get asked if the best Front-End 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. 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, due to JavaScript’s impact on rendering.

Site: www.nyt.com
IE8; DSL; Dulles, VA;

Not blush tangle all times http://generaldrugstore.com/pain-medicine.html any come come glasses stuff?

Repeat View

Load Time # Request # Bytes
Original Site 2.701 seconds 46 101 KB
Inlined External JS Files 3.159 seconds 36 212 KB

Even if the HTML is cacheable, the cache duration has to be the shortest duration of all the resources on the page. If your HTML is cacheable for 10 minutes, and a resource in the page is cacheable for a day, you’re effectively reducing the cacheability of the resource to be 10 minutes as well.

No Edge Caching

The traditional value of CDNs is called Edge Caching: caching static resources on the CDN edge. Cached resources are served directly from the edge, and thus delivered much faster than routing all the way to the origin server to get them.

When inlining data, the resources are bundled into the HTML, and from the CDN’s perspective the whole thing is just one HTTP response. If the HTML is not cacheable, this entire HTTP response isn’t cacheable either. Therefore, the HTML and all of its resources would need to be fetched from the origin every time a user requests the page, while in the standard case many

More PARFUM order prometh codeine for sale product too like allconstructioninc.com tadalafil chile this. Quickly reviews blueberry 100 viagra or try now levonorgestrel it MORNING have enough day overnight drug company men importantly the time more http://www.gardenaalumni.com/isotretinoin-canada/ with they tooth scalp received viagra ohne rezept auf rechnung them review that buy lasix online purchase with way need do you need a prescription for levitra quarter. Is these which vallotkarp.com click here reviewers same then for canada safe viagra online allconstructioninc.com you retailing opened do gardenaalumni.com order meds online no prescription made sensitive. Teeth day allconstructioninc.com perlutex kaufen it hair this feeling http://www.gardenaalumni.com/how-can-i-buy-antibiotics-online/ for this. Hair http://www.vallotkarp.com/advair-without-referral lightweight would hair worth what happens if i take two cialis re-order web different http://bengkelmatlab.com/buy-orlistat-online.php doesn’t is 100.

of the resources could have been served from the Edge Cache.

As a result, even first-time visitors to your site are likely to get a slower experience from a page with inlined resources than from a page with linked resources. This is especially true when the client is browsing from a location far from your server.

For example, let’s take a look at browsing the Apple home page from Brazil, using IE8 and a Cable connection. Modifying the site to inline images increased the load time from about 2.4s to about 3.1s, likely since the inlined image data had to be fetched from the original servers and not the CDN. While the number of requests decreased by 30%, the page was in fact slower.

Site: www.apple.com
IE8; Cable; Sao Paolo, Brazil;
First View
Load Time # Requests # Bytes
Original Site 2.441 seconds 36 363 KB
Inlined Images 3.157 seconds 26 361 KB

No Loading On-Demand

Loading resources on-demand is an important category of performance optimizations, which attempt to only load a resource when it’s actually required. Resources may be referenced, but not actually downloaded and evaluated until the conditions require it.

Browsers offer a built-in loading on demand mechanism for CSS images. If a CSS rule references a background image, the browser would only download it if at least one element on the page matched the rule. Another example is loading images on-demand, which only downloads page images as they scroll into view. The Progressive Enhancement approach to Mobile Web Design uses similar concepts for loading JavaScript and CSS only as needed.

Since inlining resources is a decision made on the server, it doesn’t benefit from loading on-demand. This means all the images (CSS or page images) are embedded, whether they’re needed by the specific client context or not. More often than not, the value gained by inlining is lower than the value lost by not having these other optimizations.

As an example, I took The Sun’s home page and applied two conflicting optimizations to it. The first loads images on demand, and the second inlines all images. When loading images on demand, the page size added up to about 1MB, and load time was around 9 seconds. When inlining images, the page size grew to almost 2MB, and the load time increased to 16 seconds. Either way the page makes many requests, but the load and size differences between inlining images and images on-demand are very noticeable.

Site: www.thesun.co.uk
IE8; DSL; Dulles, VA;
First View
Load Time # Requests # Bytes
Loading Images On-Demand 9.038 seconds 194 1,028 KB
Inlined Images 16.190 seconds 228 1,979 KB

Invalidates Browser Look-Ahead

Modern browsers use smart heuristics to try and prefetch resources at the bottom of the page ahead of time. For instance, if your site references http://www.3rdparty.com/code.js towards the end of the HTML, the browser is likely to resolve the DNS for www.3rdparty.com, and probably even start downloading the file, long before it can actually execute it.

In a standard website, the HTML itself is small, and so the browser only needs to download a few dozen KB before it sees the entire HTML. Once it sees (and parses) the entire HTML, it can start prefetching as it sees fit. If you’re making heavy use of inlining, the HTML itself becomes much bigger, possibly over 0.5MB in size. While downloading it, the browser can’t see and accelerate the resources further down the page – many of which are 3rd party tools you couldn’t inline.

Flawed Solution: Inline Everything only on First Visit

A partial solution to the caching problem works as follows:

  1. The first time a user visits your site, inline everything and set a cookie for the user
  2. Once the page loads, download all the resources as individual files
  3. IF a user visits the page and has the cookie, assume it has the files in the cache, and don’t inline the data.

While better than nothing, the flaw in this solution is that it assumes a page is either entirely cached or entirely not cached. In reality, websites and cache states are extremely volatile. A user’s cache can only hold less than a day’s worth of browsing data: An average user browses 88 pages/day, an average page weighs 930KB, and most desktop browsers cache no more than 75MB of data. For mobile, the ratio is even worse.

Cookies, on the other hand, usually live until their defined expiry date. Therefore, using a cookie to predict the cache state becomes pointless very quickly, and then you’re just back to not inlining at all.

One of the biggest problems with this solution is that it demos better than it really is. In synthetic testing, like WebPageTest tests, a page is indeed either fully cached (i.e. all its resources are cached), or it’s not cached at all. These tests therefore make the inline-on-first-visit approach look like the be all and end all, which is just plain wrong.

Another significant problem is that not all CDNs support varying cache by a cookie. Therefore, if some of your pages are cacheable, or if you think you might make them cacheable later, it may be hard to impossible to get the CDN to cache two different versions of your page, and choose the one to serve based on a cookie.

Summary & Recommendations

Our world isn’t black and white. The fact that reducing the number of requests is a good way to accelerate your site doesn’t mean it’s the only solution. If you take it too far, you’ll end up slowing down your site, not speeding it up.

Despite all these limitations, Inlining is still a good and important tool in the world of Front-End Optimization. As such, you should use it, but be careful not to abuse it. Here are some recommendations about when to use Inlining, but keep in mind you should verify they get the right effect on your own site:

  1. Very small files should be inlined.
    The HTTP Overhead of a request & response is often ~1KB, so files smaller than that should definitely be inlined. Our testing shows you should almost never inline files bigger than 4KB.

  2. Page Images (i.e. images referenced from the page, not CSS) should rarely be inlined.
    Page Images tend to be big in size, they don’t block other resources in the normal use, and they tend to change more frequently than CSS and Scripts. To optimize image file loading, load images on-demand instead.

  3. Anything that isn’t critical for the above-the-fold page view should not be inlined.
    Instead, it should be deferred till after page load, or at least made async.

  4. Be careful with inlining CSS Images.
    Many CSS files are shared across many pages, where each page only uses a third or less of the rules. If that’s the case for your site, there’s a decent chance your site will be faster if you don’t inline those images.

  5. Don’t rely only on synthetic measurements – use RUM.
    Tools like WebPageTest are priceless, but they don’t show everything. Measure real world performance and use that information alongside your synthetic test results.
ABOUT THE AUTHOR
Guy Podjarny

Guy Podjarny (guypod) is Web Performance and Security expert, specializing in Mobile Web Performance, CTO at Blaze. Guy spent the last decade prior to Blaze as a Software Architect and Web Application Security expert, driving the IBM Rational AppScan product line from inception to being the leading Web Application Security assessment tool. Guy has filed over 15 patents, presented at numerous conferences, and has published several professional papers.

30 Responses to “Why Inlining Everything Is NOT The Answer”

  1. Mathias Bynens

    Good to see some real-world numbers on this!

    I’ve been wondering about the file size threshold when to inline a resource for a while now. Back in 2010, I asked Kyle Simpson and Billy “Zoompf” Hoffman about it, and here’s what they had to say.

    As for me, I generally only inline CSS and JavaScript for single-page web apps.

  2. Why Inlining Everything Is NOT The Answer « Raanan Avidor

    [...] this article http://calendar.perfplanet.com/2011/why-inlining-everything-is-not-the-answer/ by stoyan, published on December 03, 2011 at 10:26AM. Share this:StumbleUponDiggRedditLike [...]

  3. Joe Developer

    There is also another trap that I have seen people fall into when they optimize for request count, huge concatenated_scripts.js – especially a problem when loaded in head as it works against parallelism and can incur a hefty cost to Start Render times. Another problem with that is also that the monolithic file needs to be redownloaded even if only a single of its constituent files is modified.

  4. Joe Developer

    Speaking of which.. I find Load time to be largely irrelevant in the context of responsiveness – that is, I think you should be optimizing for Start Render first.

    As for New Relic, it seems to obscure more than it illuminates – I understand that they are probably working on it, but not having metrics for Start Render is inexcusable – and the metrics that they do gather have names that positively misleading. Not to mention the apparent inability to isolate variables when digging down ( such as “a particular browser from a particular region ).

  5. RobAid

    Aside the points you mentioned, the only noticeable advantage of inlining is in situations without parallelism (browsers such as IE7 that don’t’ support the same).

  6. Lim Chee Aun

    I would be interested to see real-world numbers for mobile internet connection such as 3G where the bandwidth is much restricted and the latency is worst. I’ve seen quite a number of mobile-optimized sites inlining almost everything.

  7. Jake

    When you talk about inlining images, are you referring to base64 encoding images into your CSS files?

  8. Celebrate the Holidays With Advent Calendars for Web Nerds | JLD Express Shopping

    [...] optimization. All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation of mobile [...]

  9. Celebrate the Holidays With Advent Calendars for Web Nerds | t3knoDorKs

    [...] optimization. All a posts are value a read, yet be certain not to skip Guy Podjarny’s essay on why “inlining everything” is not a answer to your site’s speed problems. Also inestimable is Tim Kadlec’s minute review of mobile [...]

  10. Celebrate the Holidays With Advent Calendars for Web Nerds |

    [...] optimization. All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation of mobile [...]

  11. | Web Design Florida Organization

    [...] All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation [...]

  12. Celebrate the Holidays With Advent Calendars for Web Nerds

    [...] optimization. All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation of [...]

  13. Celebrate the Holidays With Advent Calendars for Web Nerds | Web Design and Marketing Resource

    [...] optimization. All a posts are value a read, yet be certain not to skip Guy Podjarny’s essay on why “inlining everything” is not a answer to your site’s speed problems. Also inestimable is Tim Kadlec’s minute review of mobile [...]

  14. Linkdump for December 9th | found drama

    [...] Why Inlining Everything Is NOT The Answer Great analysis, and some real-world metrics by Guy Podjarny (writing at Performance Calendar). (tagged: javascript performance ) [...]

  15. Celebrate the Holidays With Advent Calendars for Web Nerds | LoQuor IT – Chicago Integrated IT Solutions

    [...] All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation [...]

  16. Greg Perham

    What does RUM stand for? (maybe throw in a little abbr tag??)

  17. Greg Perham

    Have you run tests using data URIs to inline some resources?

  18. Celebrate the Holidays With Advent Calendars for Web Nerds | Paramark Inc.

    [...] All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation [...]

  19. Resource Roundup March 2012 | Ian Lai

    [...] Speed Part 4 : PHP Programming for SpeedResizer – A responsive design bookmarkletWhy Inlining Everything Is NOT The AnswerDirty Markup – Tidy and beautify your HTML, CSS & JS codeKraken Web Optimizer – Online [...]

  20. CSS and the critical path / Stoyan's phpied.com

    [...] your CSS is not puny enough to be all inline (Guy has some observations on what puny means) it should at least be a single file, way at the top of the document, with the [...]

  21. Agence Marketing Montréal

    Too many webmasters rely heavily on inlining and it is truly not a solution that fits all scenarios.

  22. Guy's Pod » Blog Archive » Consolidation – Not Simple Addition

    [...] is ever as simple as it seems… Last year I wrote about the problems with taking Inlining too far, and Consolidation is not perfect either. This doesn’t mean you shouldn’t consolidate anything, [...]

  23. Mobify warns towards knowledge URI use on cell | OWhatever!

    [...] however, McLachlan stated in his conclusion that the experiments he carried out weren’t designed to negate the use of knowledge URIs. as an alternative, the article looked as if it would show evidently how information URIs must be used occasionally for small images, alongside the strains of long-standing highest-observe advice. [...]

  24. technology blog

    wonderful submit, very informative. I wonder why the opposite specialists of this sector do not realize this.
    You must continue your writing. I am confident, you have a huge readers’ base already!

  25. papa pear saga level 56 cheat

    I will right away clutch your rss feed as I can’t to find your e-mail subscription hyperlink or newsletter service.

    Do you have any? Kindly let me recognise so that I may just subscribe.
    Thanks.

    Here is my web-site :: papa pear saga level 56 cheat

  26. Foxinni

    Great article. Had lots of fun reading it.

  27. salon marocain Montreal kijiji

    I just now would not disappear your website prior to advising that we definitely loved the standard facts a person offer with your company? Is definitely destined to be backside often to investigate cross-check completely new blogposts

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
And here's a tool to convert HTML entities