5 ms·

The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a

The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. Have you considered inlining CSS in the head (as you've done), but then serving it again with a linked css file just before </body>. Then, with subsequent page loads (of the current or other pages), you don't have to inline any CSS anymore. Of course this requires that you serve two versions of all your pages, one for if that page is a first hit, and another to be served to users who already have your CSS cached.

charrondev 6y ago
Unfortunately this means it’s difficult to handle HTTP caching without having something in the URL, and at the same time you want to make sure search engines index the version without the indicator in the URL.
sdoering 6y ago
But with 8kb zipped (I assume that following pages aren't that much worse) why should one optimize with a solution that adds that much complexity? I believe that shaving a few additional kb from this already low number isn't worth the proposed complexity. But this is a tradeoff that everybody has to decide for themselves.
- markdown 6y ago
  > But with 8kb zipped (I assume that following pages aren't that much worse) why should one optimize with a solution that adds that much complexity? If that's the argument, why not just let them take the (tiny) initial 8kb hit as an external css file, and make the rest of the experience even "zippier"?
  - seanwilson 6y ago
    > why not just let them take the (tiny) initial 8kb hit as an external css file, One reason is Google will likely ding your Core Web Vitals score for it, which is becoming a ranking signal in May this year (https://developers.google.com/search/blog/2020/11/timing-for-page-experience https://developers.google.com/search/blog/2020/11/timing-for...) so you have less of a choice here for what you prioritise.
  - sdoering 6y ago
    I would believe that 8k via an additional request would harm performance more than to inline it. But haven't tested that yet.
    - markdown 6y ago
      It would most certainly marginally harm performance a single time, but every additional page load would be much improved.
nicbou 6y ago
Inlining is a measured risk. If your CSS is sufficiently small, and the number of pages per visit is low, it's still faster than cached CSS.
seanwilson 6y ago
> The problem with inlining all CSS is serving all the global styles all over again with every page load. > You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. Yep, it's unfortunate we still have to make tradeoffs like this. At least in this case, it's less than 8KB added per page vs something more complicated that might break. HTTP push was getting closer to offering some alternative like what you're suggesting (the server pushes the CSS file to the client in parallel to the initial HTML page, and the client can say if it already has the CSS file) but it's being deprecated now.
joegahona 6y ago
> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. The vast majority of users will visit one and only one page.
- httpsterio 6y ago
  why would you optimize your website for someone who only visits the one page?
  - phist_mcgee 6y ago
    Because for every second of delay you add, you reduce your potential audience by a large degree. You optimise for first impressions, even though you know that a major proportion will click away anyway.
  - seanwilson 6y ago
    On the extreme end, consider someone on a spotty and slow mobile connection going through Google results to find what they want. They're only going to give you a few seconds before they hit "back" on your site and try another. The round trip for the browser to fetch the CSS file after the HTML file arrives can be enough to cause that delay.
  - austhrow743 6y ago
    Because most days you don't add more than one piece of content.
mro_name 6y ago
true, but if the 1st impression is great and the 2nd isn't worse – what else do we want?
onion2k 6y ago
You'd need to add 'rel="prefetch"' to the link or the browser will block rendering until the CSS file has been downloaded, parsed, and added to the CSSOM.

charrondev 6y ago

Unfortunately this means it’s difficult to handle HTTP caching without having something in the URL, and at the same time you want to make sure search engines index the version without the indicator in the URL.

sdoering 6y ago

But with 8kb zipped (I assume that following pages aren't that much worse) why should one optimize with a solution that adds that much complexity? I believe that shaving a few additional kb from this already low number isn't worth the proposed complexity. But this is a tradeoff that everybody has to decide for themselves.

markdown 6y ago
> But with 8kb zipped (I assume that following pages aren't that much worse) why should one optimize with a solution that adds that much complexity? If that's the argument, why not just let them take the (tiny) initial 8kb hit as an external css file, and make the rest of the experience even "zippier"?
- seanwilson 6y ago
  > why not just let them take the (tiny) initial 8kb hit as an external css file, One reason is Google will likely ding your Core Web Vitals score for it, which is becoming a ranking signal in May this year (https://developers.google.com/search/blog/2020/11/timing-for-page-experience https://developers.google.com/search/blog/2020/11/timing-for...) so you have less of a choice here for what you prioritise.
- sdoering 6y ago
  I would believe that 8k via an additional request would harm performance more than to inline it. But haven't tested that yet.
  - markdown 6y ago
    It would most certainly marginally harm performance a single time, but every additional page load would be much improved.

nicbou 6y ago

Inlining is a measured risk. If your CSS is sufficiently small, and the number of pages per visit is low, it's still faster than cached CSS.

seanwilson 6y ago

> The problem with inlining all CSS is serving all the global styles all over again with every page load. > You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. Yep, it's unfortunate we still have to make tradeoffs like this. At least in this case, it's less than 8KB added per page vs something more complicated that might break. HTTP push was getting closer to offering some alternative like what you're suggesting (the server pushes the CSS file to the client in parallel to the initial HTML page, and the client can say if it already has the CSS file) but it's being deprecated now.

joegahona 6y ago

> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. The vast majority of users will visit one and only one page.

httpsterio 6y ago
why would you optimize your website for someone who only visits the one page?
- phist_mcgee 6y ago
  Because for every second of delay you add, you reduce your potential audience by a large degree. You optimise for first impressions, even though you know that a major proportion will click away anyway.
- seanwilson 6y ago
  On the extreme end, consider someone on a spotty and slow mobile connection going through Google results to find what they want. They're only going to give you a few seconds before they hit "back" on your site and try another. The round trip for the browser to fetch the CSS file after the HTML file arrives can be enough to cause that delay.
- austhrow743 6y ago
  Because most days you don't add more than one piece of content.

mro_name 6y ago

true, but if the 1st impression is great and the 2nd isn't worse – what else do we want?

onion2k 6y ago

You'd need to add 'rel="prefetch"' to the link or the browser will block rendering until the CSS file has been downloaded, parsed, and added to the CSSOM.