[HN Gopher] How we improved our website's performance
___________________________________________________________________
How we improved our website's performance
Author : kkm
Score : 67 points
Date : 2021-01-22 18:37 UTC (2 days ago)
(HTM) web link (www.smashingmagazine.com)
(TXT) w3m dump (www.smashingmagazine.com)
| joegahona wrote:
| Page Speed Insights shows this site scoring a poor 39/100.
| olliepop wrote:
| key takeaways:
|
| - fonts can be unnecessarily huge
|
| - monolithic js = slow. Chunk at build time.
|
| - content-visibility: auto for lazy rendering
| wackget wrote:
| 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...
| nicbou wrote:
| 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:
| send just the content.
|
| [1] https://allaboutberlin.com/guides/german-health-insurance
| llacb47 wrote:
| Your website was way faster on mobile data, kudos.
| nicbou wrote:
| I was thinking of the person reading about something on the
| U-Bahn on their way home.
| CharlesW wrote:
| > _It should load in an instant._
|
| FWIW, it does load in an instant for me. (Lighthouse
| Performance = 99, Speed Index = 0.4s.)
| lwansbrough wrote:
| Me too, but I'm loading it on a $3000 computer with
| 150Mbps/<10ms internet. Generally it's a good idea to only
| focus on the mobile score. :)
| [deleted]
| lwansbrough wrote:
| Nice to see another company covering all these steps and
| validating the work we've done at my company. Unfortunately we
| weren't as successful, or at least, our results were not as
| fruitful. A good score for our site (tracker.gg) is 70 on mobile.
| Turns out it's pretty hard to optimize the bootstraping of an
| application that can render 20 different websites! Mobile devices
| spend 1200ms on the main thread. It will be interesting to see
| how these changes impact our page rank when Google starts
| incorporating Core Web Vitals into its algorithm this year.
| dmitriid wrote:
| Sorry for being snarky, but the title should really be: Team at a
| Static Website Discovers that Dozens of Megabytes of Unnecessary
| Javascript Is a Bad Idea, Learns Nothing.
| dairylee wrote:
| So brave.
| stanislavb wrote:
| So HN.
| timbit42 wrote:
| Well, if they "discover" it, then they did "learn" something.
| worldofmatthew wrote:
| Not fantastic:
| https://www.websitecarbon.com/website/smashingmagazine-com-2...
| tolstoyswager wrote:
| How could this be improved?
| worldofmatthew wrote:
| 250KB: https://cloud.netlifyusercontent.com/assets/344dbf88-f
| df9-42...
|
| 249KB: https://res.cloudinary.com/indysigner/image/fetch/f_au
| to,q_a...
|
| 180KB: https://res.cloudinary.com/indysigner/image/fetch/f_au
| to,q_a...
| seanwilson wrote:
| > 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/
|
| 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 wrote:
| That's one of the fastest loading modern pages I've ever been
| to. Kudos!
| markdown wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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/bl
| og/2020/11/timing-for...) so you have less of a choice
| here for what you prioritise.
| nicbou wrote:
| 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 wrote:
| > 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.
| franklyt wrote:
| 12 people for a static site seems like a huge team to me.
| tyingq wrote:
| I'm pretty sure most of them would double as writers, or
| illustrators, etc. It's not a normal magazine per-se, since the
| articles are all technical ones. It also mentions many of the
| 12 are part-time and/or wear other hats.
| brazzy wrote:
| "Modern" web development is apparently a game of Jenga.
| wackget wrote:
| 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.
| xmprt wrote:
| 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.
| CharlesW wrote:
| I don't understand the point you're making. Mind elaborating?
| brazzy wrote:
| There is a ridiculous number of moving parts, stacked on top
| of each other, interacting in unforeseeable ways to allow you
| to shoot yourself in the foot, and absolutely nothing is
| straightforward.
|
| OK, that basically describes any kind of software
| development, but web seems so much worse than anything else.
| And I say that as someone doing mainly Java backend
| development who's learned to live with the
| AbstractProxyFactoryManagerFactory jokes.
| lwansbrough wrote:
| 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.
| Frost1x wrote:
| 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.
| giantrobot wrote:
| 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
| majewsky wrote:
| Web is indeed unique. No one else would consider a magazine
| article "an application".
___________________________________________________________________
(page generated 2021-01-24 23:00 UTC)