Hacker News Reader

Comment by nateberkopec | Hacker News Reader

Ha, I should totally fix that. The site uses Jekyll, not Rails, which I'm used to getting the asset pipeline for free with!

Combining all the resources will include assets that aren't needed. Part of the reason I made the post about profiling with Timeline was so that you could test tradeoffs like this for yourself.

I don't know what you mean by reducing the utility of CDNs and caching though - surely having only one file actually increases the use of browser caching, since the browser will only make 1 request for CSS and serve the cached copy for every other page?

View on HN

Agreed, it's all about tradeoffs.

On public CDNs- I mean public CDNs for common libraries (jQuery, Angular, Font Awesome) can improve page load time if a user already has the file. The more sites use the same public CDN, the more users benefit. But if a user doesn't have the file already, it's a loss. So, tradeoffs.

On caching- if you make one JS file and one CSS file for each page, then there is no caching between pages but only necessary info is downloaded for each page. You could make one JS/CSS file for your whole site, but then there are unused assets on each page, and it becomes more difficult to simplify CSS and could increase layout thrashing. Again, tradeoffs.

Really enjoying this discussion, thanks for taking the time to write this up. I have this debate in my head constantly.

> On public CDNs- I mean public CDNs for common libraries (jQuery, Angular, Font Awesome) can improve page load time if a user already has the file. The more sites use the same public CDN, the more users benefit. But if a user doesn't have the file already, it's a loss. So, tradeoffs.

Even this has a tradeoff - if, for example, the other JS on your page require JQuery, you can't make the CDN copy of JQuery use an "async" tag, because you can't be certain of the order the JS will execute. And if you're not using the async tag, the first load will suffer.

Unfortunately the variety of library versions and public CDNs prevents users from realizing the benefits promised by caching most of the time.

Combining everything into one file reduces browser caching, since a change in any of the N files invalidates the cache.

As a site grows, it's usually better to have 2-3 bundles grouped by frequency of change. E.g. I rarely upgrade 3rd-party files like jQuery, etc. but often make changes to the 1st-party app logic.

Except for Chrome, and firefox users who have explicitly configured their cache size, most browsers have a very limited cache, with the average sizing being ~50MB. For everything. I don't know about you, but I've loaded 50MB already today. Because of that, I don't worry about cache hits, because the median visitor will have nothing cached. Instead, worry about total page size, and total number of http requests. Minifying dramatically helps the number of http requests.

Great point, and caches are even smaller on mobile.

I think it depends on your use case. If your page views are mostly new users (e.g. you're a content publisher), then cachability doesn't matter too much. But if you're writing a web app hoping to have high engagement with users that return to the site frequently, it's likely you can be pretty effective with caching.

Also - I kinda doubt that browser caches use a simple LRU replacement policy. I suspect they have some heuristics built in to guess what is most likely to be re-used. I don't know for sure though...it would be interesting to know.

Not sure about these numbers, but.. yes, in general browser disk caches are not nearly as effective as people imagine.

Even jQuery from the Google CDN is rarely present in a cache. They are great for navigating around the same site in one session, but not effective for much more than that.

I've never configured my cache in Firefox. Just looked at the settings, and, as far as I get what's written (it's not very clear), there's no limit at all on my cache size.

It's currently using 350MB.

Chrome has several different caches (HTTP, DNS, SSL session data, etc.) but looking at just the on disk HTTP cache my laptop is currently using 201MB with the default settings. For anyone else who is interested, you can see the cache stats at chrome://net-internals/#httpCache

199MB here. I think Chrome defaults to 200MB, yeah.

I just checked my preferences on Firefox 39 on OS X, and my cache is 350mb by default (I never changed it).

Excellent point about one file update invalidating the bundle, totally missed that in my argument. And I like your approach in bundling by update frequency!

A bit off-topic, but I recommend Middleman as a nice, well, middle-ground: Middleman builds to static files like Jekyll, but pulls in Rails' asset pipeline features for a better experience.

He's implying that other sites may use the same popular Javascript libraries, so they may already be in the browser cache, before the first page load.

I've never understood why this was a good argument, because it just ignores that there are still going to be a lot of people who hit the worst-case scenario. When optimizing page-load time, you should always optimize for the worst-case scenario, not the best-case.

It really depends on your use-case & what you're doing. In many cases you will likely want to target ~ 95th percentile or similar.

Also, how likely is it that two websites use exactly the same CDN and version of e.g. jQuery or Angular?

This is probably a major contributing factor to the issue.

Personally, I've seen the greatest improvement in performance by avoiding latency more often than total download size. That's why concatenation works so well. It's just much more expensive to initiate two HTTP requests (four, if it does a HEAD first to get the Last Modified date), than one.

That said, I still limit total download size. JQuery is not a big enough contribution to my productivity to warrant an extra 86KB of data. React is like 132KB. Angular is 144KB. That's a lot of KB for anyone riding on the metro.

What he probably means is "I thought I should include a public CDN version of jQuery instead of combining it with my own scripts, so that it is served once across the internet and not just once across my website"

But if you're pulling in shared resources from a public CDN, like jquery, the browser probably already has it cached and won't need to download it at all.

I'd love to see some concrete numbers on public CDN hit rates. It feels to me like of those ideas that sounds great in theory, but in the real world doesn't really work because of the multitude of versions, libraries, and options for public CENsus.

I have some memory of someone doing this and finding the hit rates were abysmal—too many libraries and too many versions. And that was five years ago, and we just have more libraries and more versions today. I'd love to dig up the numbers… I hope they aren't somewhere internal to Opera (where I used to work)!

Reply on news.ycombinator.com