4 ms·

> Around the same time we switched from an (outdated) manually created critical CSS file to an automated system that was generating critical CSS for every templ

> Around the same time we switched from an (outdated) manually created critical CSS file to an automated system that was generating critical CSS for every template — homepage, article, product page, event, job board, and so on — and inline critical CSS during the build time. Yet we didn’t really realize how much heavier the automatically generated critical CSS was. Is reducing the total amount of CSS per page so you don't have to calculate the critical CSS at all an option? To throw my own page into the ring, here's a non-trivial product website of mine where the homepage is 0.3MB total over the wire and renders in 0.4 seconds for me (includes custom fonts, payments, analytics, large screenshot and real-time chat widget): https://www.checkbot.io/ https://www.checkbot.io/ The major tricks I'm using is keeping the website CSS small (CSS for homepage + rest of site gzips to less than 8KB), inlining all CSS, rendering default fonts before the custom font has loaded, SVG for all images (this saves a ton), and not using JavaScript for content (which blocks rendering). The screenshot in the header is in SVG format and inlined directly into the page along with the CSS, so the moment the HTML arrives the browser can display all above the fold content. Logos are another good one for the SVG + inline treatment.

ramraj07 6y ago
That's one of the fastest loading modern pages I've ever been to. Kudos!
- seanwilson 6y ago
  Thanks! I wouldn't mind seeing a list of fast loading pages like this that have images + functionality that aren't mostly text. There's only so much you can do if your design requires large photos or a video in the header though.
markdown 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. 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
siquick 6y ago
Just wanted to say that I’ve been using Checkbot for years and it’s great
- seanwilson 6y ago
  Thanks, that made my day. :)
mro_name 6y ago
phantastic. Design is not how something looks, it is how it works. (said Steve Jobs) Do you folks know the entertaining talk http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm?
dingleberrydon 6y ago
Whoa. I've never seen a page load this fast. How did you do it? Is there a blog post somewhere?
- seanwilson 6y ago
  I need to write it up but the SVG screenshot is documented on https://www.checkbot.io/article/web-page-screenshots-with-svg/ https://www.checkbot.io/article/web-page-screenshots-with-sv... and I'm using all the tricks from https://www.checkbot.io/guide/speed/ https://www.checkbot.io/guide/speed/ that the Chrome extension checks for. The big wins are: don't require JS for any content in the page header, use minimal CSS + inline it, strongly prefer SVG images over bitmaps + inline them, use "font-display: swap" + go easy with how many fonts you need.
boundlessdreamz 6y ago
How did you create the screenshot SVG and other SVGs?
- seanwilson 6y ago
  SVG screenshots are documented here: https://www.checkbot.io/article/web-page-screenshots-with-svg/ https://www.checkbot.io/article/web-page-screenshots-with-sv... The main trick is to view your web app in a browser, print to PDF and then use Inkscape to auto convert from PDF -> SVG (with some caveats). Worst case you could recreate the screenshot from scratch in a vector editor. The SVG icons are licensed from https://icons8.com/ https://icons8.com/ (recommended!).
  - boundlessdreamz 6y ago
    Thank you. You have been tremendously helpful

ramraj07 6y ago

That's one of the fastest loading modern pages I've ever been to. Kudos!

seanwilson 6y ago
Thanks! I wouldn't mind seeing a list of fast loading pages like this that have images + functionality that aren't mostly text. There's only so much you can do if your design requires large photos or a video in the header though.

markdown 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. 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

siquick 6y ago

Just wanted to say that I’ve been using Checkbot for years and it’s great

seanwilson 6y ago
Thanks, that made my day. :)

mro_name 6y ago

phantastic. Design is not how something looks, it is how it works. (said Steve Jobs) Do you folks know the entertaining talk http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm?

dingleberrydon 6y ago

Whoa. I've never seen a page load this fast. How did you do it? Is there a blog post somewhere?

seanwilson 6y ago
I need to write it up but the SVG screenshot is documented on https://www.checkbot.io/article/web-page-screenshots-with-svg/ https://www.checkbot.io/article/web-page-screenshots-with-sv... and I'm using all the tricks from https://www.checkbot.io/guide/speed/ https://www.checkbot.io/guide/speed/ that the Chrome extension checks for. The big wins are: don't require JS for any content in the page header, use minimal CSS + inline it, strongly prefer SVG images over bitmaps + inline them, use "font-display: swap" + go easy with how many fonts you need.

boundlessdreamz 6y ago

How did you create the screenshot SVG and other SVGs?

seanwilson 6y ago
SVG screenshots are documented here: https://www.checkbot.io/article/web-page-screenshots-with-svg/ https://www.checkbot.io/article/web-page-screenshots-with-sv... The main trick is to view your web app in a browser, print to PDF and then use Inkscape to auto convert from PDF -> SVG (with some caveats). Worst case you could recreate the screenshot from scratch in a vector editor. The SVG icons are licensed from https://icons8.com/ https://icons8.com/ (recommended!).
- boundlessdreamz 6y ago
  Thank you. You have been tremendously helpful