It’s very easy for unoptimized images to end up on a production site and slow down its initial load considerably. Inexperienced devs usually aren’t aware of this potential problem. They also aren’t aware of a wide range of tools and approaches for optimizing images.
This article aims to cover most of the tools and approaches for optimizing images for the web.
Good to see that it also covers native lazy image loading. The smallest image still remains an image not loaded unnecessarily 😉
Over the years Instagram (as a product) grew a lot. With more features to show, their web experience began to degrade. In a series of (upcoming) posts they’re covering what they have done to improve performance. In this first part they cover script preloading and image prefetching, reducing the loading time of the “feed page” by 50%.
Correctly prioritizing resource download and execution and reducing browser downtime during the page load is one of the main levers for improving web application performance. In our case, many of these types of optimizations proved to be more immediately impactful than code size reductions, which tended to be individually small and only began to add up after many incremental improvements.
The Webkit blog, on how to optimize your pages so that they don’t drain the battery of your visitors their devices:
Users spend a large proportion of their online time on mobile devices, and a significant fraction of the rest is users on untethered laptop computers. For both, battery life is critical. In this post, we’ll talk about factors that affect battery life, and how you, as a web developer, can make your pages more power efficient so that users can spend more time engaged with your content.
The three sections where to optimize covered are scripting, painting (the way stuff is rendered/animated), and networking (requests over the network)
One of the quickest wins—and one of the first things I recommend my clients do—to make websites faster can at first seem counter-intuitive: you should self-host all of your static assets, forgoing others’ CDNs/infrastructure. In this short and hopefully very straightforward post, I want to outline the disadvantages of hosting your static assets ‘off-site’, and the overwhelming benefits of hosting them on your own origin.
For the site tested, this resulted in a ~300ms win:
One of the main reasons for me is that you, as developer, stay in control of everything. I’ve had sites break due to some external files no longer being available.
The main goal of CSS Containment standard is to improve the rendering performance of web pages, allowing the isolation of a subtree from the rest of the document. This specification only introduces one new CSS property called contain with different possible values.
layout: The internal layout of the element is totally isolated from the rest of the page, it’s not affected by anything outside and its contents cannot have any effect on the ancestors.
paint: Descendants of the element cannot be displayed outside its bounds, nothing will overflow this element (or if it does it won’t be visible).
size: The size of the element can be computed without checking its children, the element dimensions are independent of its contents.
style: The effects of counters and quotes cannot escape this element, so they are isolated from the rest of the page.
Browser engines can use that information to implement optimizations and avoid doing extra work when they know which subtrees are independent of the rest of the page.