This lead to a large download, which caused the painter and renderer - because they are different processes - to stall whilst the CSS file was downloaded and parsed. But, even though it was minified, the below the fold CSS was huge (around 300+ KiB). They had taken care of splitting their CSS & JS to above and below the fold, which is always great to see (and fantastic for SEO, folks). The client uses a Cache-Control header value which makes sense to them and didn’t want it to change. We use the Cache-Control header value as recommended by Netlify (as that’s where the site is hosted), which might not be suitable for everyone. Here’s a redacted cURL response for the RJJ website:Ĭache-Control: public, max-age =0, must-revalidate This is rather simple to do and can be done either in your browser’s dev tools or by using cURL. The client told us that everything was being minified during the build, so we checked the Cache-Control header. The website uses the JAMStack - which we’re pretty big fans of - so there wasn’t much to do on the server except to check that the Cache-Control policy was set to sane values and ensure that everything was minified whilst building. We were permitted to alter the HTML and server-side code, though. Because of this, we were instructed not to touch them.
They did have a lot of CSS and JS, but it was fairly well optimised. These kinds of requests usually come in when sites have unused CSS & JS and leverage heavy images. This one fact is why it’s easy to see that the Amazon homepage tends to load very, very quickly. I remember reading in the DevOps Handook about how Amazon had calculated that each 100ms of latency could cost them a million dollars in lost revenue. The SetupĪ client approached us last week with a simple request: With a one-line change to the HTML for a client’s website, we decreased average load times by 1,320ms.
The cover image for this post is by veri_ivanova
0 kommentar(er)
