4 ms·

I wonder what the performance increase would be of loading one big CSS file on the first page load and serving from local cache from then on, vs loading a small

I wonder what the performance increase would be of loading one big CSS file on the first page load and serving from local cache from then on, vs loading a smaller but different CSS file for each page you visit. My impression is that number of requests is a more critical optimization than file size (at least when serving CSS sized files)

ino 10y ago
Serving the page with inlined CSS also has the compression benefit of many html ids and classes being repeated in the CSS.
tkadlec 10y ago
Really depends. How big is the once CSS file you're loading and how much of the CSS is common from page to page? If 20kb is for a specific component on one or two, less-visited pages, then it probably doesn't make sense to lump everything together. A fairly safe default starting point would be: 1. Tiny subset of inlined critical CSS (See https://www.smashingmagazine.com/2015/08/understanding-critical-css/ https://www.smashingmagazine.com/2015/08/understanding-criti...) 2. Asynchronous + rel=preload loading of the main CSS of your site 3. Then, if there are hefty chunks of CSS for specific pages only, bring those in on those pages. This changes a bit if you're using HTTP/2. Then the multiplexing makes it beneficial to break the CSS into a few smaller files instead of one big one. In the end, you probably just have to experiment and test. :) No guaranteed "this is best" approach here.
rasz_pl 10y ago
caching is out of style nowadays, you lose precious user tracking, not to mention dynamic web. Its as bad as DNS TTL (some keep it at couple of minutes or lower).
madeofpalk 10y ago
It's going to depend a lot on the type of site you're building. Thankfully frontend pipelines like React + Webpack makes it fairly easy to test this out. We spiked out generating individual JS + CSS for each view but ultimately found it wasn't worth it - individual views amounted to very little code with the bulk of the filesize taken up by the common 'core' of our application, and dependencies. We scrapped this specific idea. What we did end up doing, however, was create a seperate stylesheet just for things required on the very minimal landing page and inject that straight into the <head>, which gave us significant speed improvements.
- madeofpalk 10y ago
  Just to clarify (after I've re-read my comment) - we didnt explicitly create a landing page stylesheet, instead we were able to use Webpack to automatically create a seperate stylesheet at build time containing just the styles used in the dependency tree of the landing page. Webpack is super handy like that - no need to be aware of this and manually keep track of a seperate stylesheet :)
foota 10y ago
From what I've heard, the answer depends greatly on whether we're talking http 1 or 2
- coltonv 10y ago
  HTTP/2 is pretty much everywhere now, including virtually all mobile devices. So targeting HTTP2 is pretty sensible IMO.

ino 10y ago

Serving the page with inlined CSS also has the compression benefit of many html ids and classes being repeated in the CSS.

tkadlec 10y ago

Really depends. How big is the once CSS file you're loading and how much of the CSS is common from page to page? If 20kb is for a specific component on one or two, less-visited pages, then it probably doesn't make sense to lump everything together. A fairly safe default starting point would be: 1. Tiny subset of inlined critical CSS (See https://www.smashingmagazine.com/2015/08/understanding-critical-css/ https://www.smashingmagazine.com/2015/08/understanding-criti...) 2. Asynchronous + rel=preload loading of the main CSS of your site 3. Then, if there are hefty chunks of CSS for specific pages only, bring those in on those pages. This changes a bit if you're using HTTP/2. Then the multiplexing makes it beneficial to break the CSS into a few smaller files instead of one big one. In the end, you probably just have to experiment and test. :) No guaranteed "this is best" approach here.

rasz_pl 10y ago

caching is out of style nowadays, you lose precious user tracking, not to mention dynamic web. Its as bad as DNS TTL (some keep it at couple of minutes or lower).

madeofpalk 10y ago

It's going to depend a lot on the type of site you're building. Thankfully frontend pipelines like React + Webpack makes it fairly easy to test this out. We spiked out generating individual JS + CSS for each view but ultimately found it wasn't worth it - individual views amounted to very little code with the bulk of the filesize taken up by the common 'core' of our application, and dependencies. We scrapped this specific idea. What we did end up doing, however, was create a seperate stylesheet just for things required on the very minimal landing page and inject that straight into the <head>, which gave us significant speed improvements.

madeofpalk 10y ago
Just to clarify (after I've re-read my comment) - we didnt explicitly create a landing page stylesheet, instead we were able to use Webpack to automatically create a seperate stylesheet at build time containing just the styles used in the dependency tree of the landing page. Webpack is super handy like that - no need to be aware of this and manually keep track of a seperate stylesheet :)

foota 10y ago

From what I've heard, the answer depends greatly on whether we're talking http 1 or 2

coltonv 10y ago
HTTP/2 is pretty much everywhere now, including virtually all mobile devices. So targeting HTTP2 is pretty sensible IMO.