4 ms·

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 in

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?

nordsieck 11y ago
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.
- moron4hire 11y ago
  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.
  - adanto6840 11y ago
    It really depends on your use-case & what you're doing. In many cases you will likely want to target ~ 95th percentile or similar.
  - seanwilson 11y ago
    Also, how likely is it that two websites use exactly the same CDN and version of e.g. jQuery or Angular?
    - moron4hire 11y ago
      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.
sp332 11y ago
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.
- jon-wood 11y ago
  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.
  - gsnedders 11y ago
    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)!
strommen 11y ago
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.
- ohitsdom 11y ago
  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!
- arohner 11y ago
  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.
  - jwoah12 11y ago
    I just checked my preferences on Firefox 39 on OS X, and my cache is 350mb by default (I never changed it).
  - strommen 11y ago
    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.
  - 11y ago
ohitsdom 11y ago
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.
- nateberkopec 11y ago
  > 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.
- mutagen 11y ago
  Unfortunately the variety of library versions and public CDNs prevents users from realizing the benefits promised by caching most of the time.
nthj 11y ago
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.
SonOfLilit 11y ago
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"

nordsieck 11y ago

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.

moron4hire 11y ago
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.
- adanto6840 11y ago
  It really depends on your use-case & what you're doing. In many cases you will likely want to target ~ 95th percentile or similar.
- seanwilson 11y ago
  Also, how likely is it that two websites use exactly the same CDN and version of e.g. jQuery or Angular?
  - moron4hire 11y ago
    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.

sp332 11y ago

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.

jon-wood 11y ago
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.
- gsnedders 11y ago
  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)!

strommen 11y ago

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.

ohitsdom 11y ago
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!
arohner 11y ago
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.
- jwoah12 11y ago
  I just checked my preferences on Firefox 39 on OS X, and my cache is 350mb by default (I never changed it).
- strommen 11y ago
  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.
- 11y ago

ohitsdom 11y ago

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.

nateberkopec 11y ago
> 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.
mutagen 11y ago
Unfortunately the variety of library versions and public CDNs prevents users from realizing the benefits promised by caching most of the time.

nthj 11y ago

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.

SonOfLilit 11y ago

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"