Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we improved our website's performance

smashingmagazine.com

Post reply on HN
Print view View original

31–40 of 76 posts

Re: How we improved our website's performance

#31

Post by nicbou »

markdown wrote: post #27
seanwilson wrote: post #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…

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…

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.

Re: How we improved our website's performance

#32

Post by seanwilson »

markdown wrote: post #27
seanwilson wrote: post #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…

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…

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

Re: How we improved our website's performance

#34

Post by markdown »

sdoering wrote: post #30
markdown wrote: post #27

Earlier quoted context omitted.

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.

> 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"?

Re: How we improved our website's performance

#35

Post by seanwilson »

markdown wrote: post #34
sdoering wrote: post #30

Earlier quoted context omitted.

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.

> 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"?

> 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...) so you have less of a choice here for what you prioritise.

Re: How we improved our website's performance

#36

Post by wackget »

brazzy wrote: post #10

"Modern" web development is apparently a game of Jenga.

Only because developers absolutely insist on building things that way, for some reason I will never comprehend.

What's the first thing most people do when starting a new project? They ask "what framework should I build this on?" and start their tiny portfolio site built upon a massively overpowered suite of enterprise-level software with a million features they'll never, ever need.

Then they might drop in ten or fifteen separate external libraries because using vanilla HTML, CSS, and JavaScript is just "so 1995".

Then they start thinking about AJAX and microservices because rendering an entire page on the server side is utterly unthinkable in 2021.

Then they cram the site full of third-party services (because your tiny home-brew website will definitely benefit from Newrelic monitoring).

Then they might start on unit testing.

Finally they package everything up using at least seven different dependency managers, because a Github project without 100 useless ancillary files (grunt.js, app.yaml, travis.yml, composer.json, .gitignore, etc. etc.) is obviously not acceptable.

And this is why I hate modern web development.

Re: How we improved our website's performance

#37

Post by wackget »

olliepop wrote: post #21

key takeaways: - fonts can be unnecessarily huge - monolithic js = slow. Chunk at build time. - content-visibility: auto for lazy rendering

Chunking JS just leads to massive latency issues as the client is forced to download dozens (or hundreds) of "efficiently" chunked JS files.

The e-commerce platform Magento 2 is packed with this kind of bullshit and is part of the reason my colleagues and I abandoned it for our clients' large e-commerce websites:

https://magento.stackexchange.com/questions/104583/magento-2...

https://old.reddit.com/r/Magento/comments/bli7vz/seriously_w...

https://magento.stackexchange.com/questions/277544/page-load...

https://magento.stackexchange.com/questions/270553/is-it-pos...

Re: How we improved our website's performance

#38

Post by xmprt »

wackget wrote: post #36
brazzy wrote: post #10

"Modern" web development is apparently a game of Jenga.

Only because developers absolutely insist on building things that way, for some reason I will never comprehend. What's the first thing most people do when starting a new project? They ask "what framework should I build this on?" and start their tiny portfolio site built upon a massively overpowered suite of enterprise-level software with a million features they'll never, ever need. Then they might drop in ten or fift…

I remember reading a blog post about a fake conversation between two developers about web development and one way telling the other about how "easy" it is and goes through a 5 step process of how to build their 1 page website. That was written at least 5 years ago and things have only gotten worse since then.

Re: How we improved our website's performance

#40

Post by [deleted] »

nicbou wrote: post #7

It'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]
Post reply on HN