key takeaways:
- fonts can be unnecessarily huge
- monolithic js = slow. Chunk at build time.
- content-visibility: auto for lazy rendering
How we improved our website's performance
21–30 of 76 posts
Re: How we improved our website's performance
#22"Modern" web development is apparently a game of Jenga.
It certainly feels that way sometimes. But web is rather unique. There aren't any other platforms that demand you deliver an application for "a device" (specifications unknown!) in under 1 second.
There's such a thing as an unreasonable, unrealistic, or downright stupid demand as well. What you often see is a house of cards hacked together to try and support such demands on the web.
Sending reasonably well visually formated text is definitely a reasonable demand though.
Re: How we improved our website's performance
#23"Modern" web development is apparently a game of Jenga.
It certainly feels that way sometimes. But web is rather unique. There aren't any other platforms that demand you deliver an application for "a device" (specifications unknown!) in under 1 second.
That's why there's all kinds of helpful features in HTML/CSS like media queries. You can serve up raw content and let the device make decisions on what resources to use to display the content. You can tell the device the most optimal resources for its particular constraints.
As a for instance you your script tag can just include a bunch of @import statements. Thankfully @import statements support media queries [0]. So you get the utility of external style sheets but can load one optimized for the client device. Unlike media queries on link tags the browser doesn't load style sheets (well they're not supposed to) that don't match the media queries.
It's also trivial to include a tiny bit of base styling with every page in a script tag. It doesn't blow any size budgets and makes sure a page is readable even with no external assets.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/@import
Re: How we improved our website's performance
#24It's still way too slow. It's a big page of text. It should load in an instant. In my browser, I see 1.75 MB sent over the wire and a 2.5 second load time. My big pages of text [1] need 105 kB and load in 0.4 seconds. Their compressed critical CSS is the same size as my entire uncompressed CSS file. They send more CSS bytes than I send bytes in total. If you want to make a content website fast, it's quite simple: sen…
[deleted]
Re: How we improved our website's performance
#25> 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):
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.
Re: How we improved our website's performance
#26> 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…
That's one of the fastest loading modern pages I've ever been to. Kudos!
Re: How we improved our website's performance
#27> 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…
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 .
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.
Re: How we improved our website's performance
#28It's still way too slow. It's a big page of text. It should load in an instant. In my browser, I see 1.75 MB sent over the wire and a 2.5 second load time. My big pages of text [1] need 105 kB and load in 0.4 seconds. Their compressed critical CSS is the same size as my entire uncompressed CSS file. They send more CSS bytes than I send bytes in total. If you want to make a content website fast, it's quite simple: sen…
Your website was way faster on mobile data, kudos.
I was thinking of the person reading about something on the U-Bahn on their way home.
Re: How we improved our website's performance
#29> 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…
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 . Then, with subsequent page loads (of the current or other pages), you don't have to…
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.
Re: How we improved our website's performance
#30> 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…
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 . Then, with subsequent page loads (of the current or other pages), you don't have to…
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.