Briefly, JavaScript and CSS have to be “external” in order to be cached.  That means they are separated from the HTML file, so new visitors (without a primed cache) experience the performance overhead involved with making extra round-trip HTTP requests to the server to fetch each individual JS and CSS. Across a number of files and stylesheets, the cumulative overhead time can add up.

Thus the all-important first impression for new visitors — those who are most likely to bounce back to a search engine results page because of a slow site — is worse than it would be if the files were  “inlined” in the HTML instead.  

So what’s a developer to do when tasked with speeding up a site?

Performance Consensus (?)

Something close to a consensus has emerged among developers: to always make JavaScript and CSS external, both in order to leverage the cache and to keep code organized and easy to maintain.  Does that translate to “forget about inlining”?

This consensus has developed in part due to the influence of YSlow rules and the writings of Steve Souders authoritative web performance resources that call “Make Files External” a rule of thumb.

But looking past the surface, it’s obvious why this is a guideline, rather than a hard-fast rule.  In his book High-Performance Websites, Souders actually devotes several pages to the tradeoffs of inlining versus external, which include cases where inlining may be the better option.

If forced to pick a rule that has the best chance to help the greatest number of sites, sure — cache is king.  But if you seek a comprehensive approach to performance, don’t sleep on inlining. It might be the best policy for certain web properties and use cases.

When to Inline 

Small files

One great use case for inlining is for very small files.  Websites are increasingly complex, meaning they are host to more separate JavaScript files and stylesheets than ever.  Some of these files are small: single lines of code weighing in at less than 50 KB.  These files process so quickly in the browser that the time savings of having them cached is trivial.  So instead of keeping small files external, inline them to save those extra HTTP round trips.  The reduced latency for first-time visitors will likely outweigh the reduced processing time caching would provide a visitor on repeat views.  (You can still keep any bigger files and stylesheets external and cacheable).

Mobile

Another use case for inlining is on mobile sites.  Slow, congested cell networks and high packet loss rates amplify the performance cost of each round trip to and from a mobile device.  Cutting down the number of HTTP requests required to load a page is key for undercutting those performance burdens. If you have a separate site for mobile, you may want to inline more aggressively there than you do on your desktop site, thereby saving trips.  Yes, there’s still the same tradeoff with caching, but the slow cell networks may tip the scales toward inlining.

Niche sites

The metrics that Souders used to support the “external” rule of thumb are that, for an average website, ?75-85% of page views per day are performed with a primed cache.? There’s no denying that a site with those metrics would want to leverage the cache to its advantage.  But what about microsites, landing pages, and other special page types?  If you don’t expect multiple page views per visit perhaps because the site serves only to funnel traffic to your main site, or it’s a site with only one page then it will serve you well to use inlining to provide the best experience possible for that single-page view.

Clean code 

Aside from performance, the reason many developers recommend external scripts and stylesheets is to keep code clean and manageable.  This is something you’ll have to account for according to your own habits and organizational practices.  We think that performance is important enough that concessions on some coding best practices are worth making, for the benefit of the user.  But that’s a decision to be made with your team.

There is, however, a way around these code concerns:  automated inlining.  Front-end optimization solutions like ours (Yottaa Site Optimizer) do inlining on the fly so that no matter how your site is written and organized, you can benefit.  In fact, the on-the-fly application means that you can set exceptions so that certain users see differently configured balances of inlined and external assets.  (For more information on the “Inlining” feature in Yottaa Site Optimizer, check out our Product Update blog: New Yottaa Feature: Inline JavaScript and CSS).

Conclusion: Try Inlining

You won’t know how much inlining can help performance on your site unless you try it.  With tools like WebsiteTest.com and WebPageTest.org, you can run real-browser tests with primed and clear caches, so you can make an educated assessment of where and when to inline files. If you make a foray into this technique, let us know how it goes!