Whenever you’re listening for events on the page, it’s important to make sure that the event listeners don’t get overwhelmed with processing incoming requests. Otherwise they can quickly become a bottleneck and cause an unnecessary performance hit.
Earlier this year, as I was looking through the results of a Lighthouse audit, I came across a recommendation to use passive event listeners. Since I didn’t know what this was referring to, I did a little investigation, and the following is what I discovered.
Animations can be an important part of a web page’s design. Used appropriately, they can enhance the user experience, and add a nice polishing touch. But at the same time, animations come at a cost. If done improperly, they could lead to unwanted jank, something we all want to avoid.
When it comes time to test out how a web page will work on a mobile device, there’s no substitue for using a real device. Modern browsers typically have some kind of mobile emulator available, which can be helpful. One of the nice things about these are they’re part of the browser’s existing developer toolset (Chrome’s Dev Tools, for instance), and so you can continue to inspect and develop the page with these tools, while still having a good idea of what it will look like when it’s on a smartphone or tablet. But what do you do when you want to actually inspect what’s going on in the browser on an actual phone?
When building a responsive web page, one of the goals–by definition–is to make sure the page works well on a wide variety of screen sizes. This includes how it displays any images it contains. But when an image needs to be displayed at a variety of sizes, you run into a dilemma: You want to make sure the original image is large enough to not get scaled up (and thus look pixelated) when filling the space. But at the same time, you want to avoid the performance hit of using an image that is significantly bigger than is necessary when displayed on smaller viewports.