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.
Earlier this month, Google announced a new JPEG encoding algorithm that promises high quality images with a savings of up to 35% in file size. Guetzli (Swiss German for cookie) is Google’s new, open source method of encoding JPEGs that “strikes a balance between minimal loss and file size…”(source). Meaning, there tends to be fewer artifacts, thus creating an image that is both smaller and looks better.
If performance is important to you, having the right tools to test it is critical. These tools could include the developer tools that we find within modern browsers, or online tools like WebPageTest or Google’s PageSpeed Insights. Today, we’ll be looking at another tool. But unlike some online tools out there, it can be installed locally, giving us the ability to test pages (including local pages) from both the browser as well as the command line.
In the previous post, we set up a basic cache using services workers – one that simply cached responses to requests coming in so we could pull them from the service worker cache instead of over the network. And while this simple cache has some usefulness, there are a number of ways we can improve upon it. In this post, we’ll look at a few ways to level up our basic service worker cache, giving us more flexibility and precision in how we handle requests and responses.