How we improved our website's performance

Post by sumoboy » Mon, Jan 25, 2021, 6:12 AM UTC

wackget wrote: post #37

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…

Post by sdoering » Mon, Jan 25, 2021, 6:50 AM UTC

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

Post by mro_name » Mon, Jan 25, 2021, 8:13 AM UTC

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…

Post by boundlessdreamz » Mon, Jan 25, 2021, 8:46 AM UTC

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…

Post by seanwilson » Mon, Jan 25, 2021, 8:54 AM UTC

dingleberrydon wrote: post #62

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…

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