Frontend resource optimisation: Requests vs caching

Question

I'm currently working on a big site which has quite a bit of technical debt we need to work away. There is quite a bit of js and css being loaded in the site. Currently the files are aggregated and minified in layers. One layer is used on each page, while the other layers are only loaded on pages that actually use them.

For example:

page 1:
    - default.css
    - page1.css
    - some-feature.css
    - default.js
    - page1.js
    - some-feature.js

page 2:
    - default.css
    - page2.css
    - default.js
    - page2.js

page 3:
    - default.css
    - page3.css
    - some-feature.css
    - some-other-feature.css
    - default.js
    - page3.js
    - some-feature.js
    - some-other-feature.js

Now, besides these resources there are a lot of external resources loaded as well, used for tracking, advertising, social integration etc.

I have the feeling that these resources would be served faster (both on initial and subsequent requests) if they were aggregated and minified in one single js and one single css file per page. For example page1.css + page1.js and on another page it would be page2.css + page2.js. Although this would result in less requests, it would also end up in loading some general content twice (like the original default.css)

What would be the preferred way of loading these resources? And do you have any test results on this?

Answer 1

TLDR: People prefer caching, because your page will survive through first page load with gzipped payload

Most of the projects I've seen, had all front-end assets aggregated in single files. gzip compression will take a good care, you might be amazed how huge is reduction of the file size.

Consider outputting small amounts of page-specific CSS code as inline styling.

Regarding JavaScript, the best you can do is to convert all the assets in to AMD modules and use something like RequireJS to handle dependencies and the execution order.

Inlining small pieces of JS code works great too, you can save up a little on the main package size that way.

After all, having huge amount of advertisement is a huge letdown for a front-ender, unless you can make banners to load asynchronously(see postscribe)

Consider using PageSpeed Tools by Google, it's a fairly simple tool, that might give you a tip on optimizing your payload.

Answer 2

So you have severall questions:

1. Combine and minify or schedule it for subrequests. There were two metrics important for this: first, how big should the compressed and minified .js file be? I would strongly recommend to keep one lower than 300kb (even less on mobile use). But if all your pageX.js together have 100kb, please combine them. (Is this advice to obvious?) - if your files are more than 300kb per page, please go on below on huge js assets.

2. What about the duplicate default.css/js Code? If you keep them seperate, put them on the same URL. The browser cache URLs and won't reload the file if they just have loaded it (also see http expiry header to improve caching). It is also recommended to store them on a fast, replicated external space (e.g. Amazon Cloud Front / S3)

Overall recommendation:

common (externally hosted, same url): 
- default.minified.css
- default.minified.js

page 1:
- page1.css
- page1.js

page 2:
- page2.css
- page2.js

page 3:
- page3.css
- page3.js

** Huge JS Assets **

Okay, assuming your page3.js gets large (>500kb). Then you really should think about lazy loading. This means, the core functionality, which is necessary for the user interaction is loaded first.

After that, there are several approaches to load single javascript files async (Google: lazy loading javascript) for each library. e.G. with jquery as decribed here

$.getScript('tinymce.js', function() {
    TinyMCE.init();
});