![]() ![]() On a retina device with a 2x device pixel ratio, we need a 2000px wide image to fill that space without the browser upscaling it. So, let’s say our website is 1000px wide as defined in CSS. That is, the ratio of one CSS pixel to one physical pixel. When we say 1x or 2x images we’re really talking about the devicePixelRatio. We can accomplish this with a few more lines of code in a new Lua block. We can now convert PNG to WebP on the fly, and with good performance! But we also want to create lower res versions automatically when required. In Ubuntu-land, to enable Lua support for NGINX, use this:įinally we use ngx.exec() to internally redirect to our newly saved WebP file! Subsequent requests will skip all this Lua code and just be served the file from disk. And once we have Lua support, we can use that fancy Lua-to-ImageMagick binding we found! Or at least, that’s the theory. It’s not usually enabled out of the box, but it’s easy enough to add with a simple module install. NGINX has supported Lua as a scripting language for some time. Ermm, why do we care about Lua and how does this get us closer to our goal? The NGINX Lua Module Luckily there is someone who built one for Lua. There’s a large number of binding libraries out there to support ImageMagick from almost any programming language. But how can we access it from within NGINX? Well, with a bit of trickery. It’s a library that can read image attributes like width and height, do resizing, and even change format. What we really need is something like ImageMagick. ![]() So it doesn’t get us any closer to our WebP format goal either! ImageMagick can do Everything The NGINX image module also does not support changing file formats. We just want a 1x that is half the resolution of the original, whatever that size might be. This is cool, but we don’t want to think about image sizes. You can even create endpoints that take custom width and height values. NGINX has long had an image module which can be used to resize images on the fly. Isn’t this what computers are for - to do the boring work for us? NGINX Image Module to the Rescue? But we only have a single high res PNG and it’s a lot of irritation to make the other three versions for every image we want on the site. Here’s a big hero image from our web performance guide:Įssentially, we need four versions of the same image: high res and low res versions of the image in both PNG and Webp format. Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should. What if, instead, we could let NGINX do the heavy lifting for us, and create the necessary images on the fly?ĭisclaimer: What follows is more of a proof of concept than a best practice. At Request Metrics we have a Photoshop template that will do some of the work for us on export, but it’s still a manual step. Automating the Pain AwayĬreating all the permutations of every image you need on your site can be time consuming and irritating. WebP is usually the best choice since it keeps size down, but not all browsers support it. Using the right file format is equally important. You’ll often end up with a cartesian explosion of the same image in different sizes and formats to support different scenarios.įor example, you don’t want to send a high res image meant for high DPI screens to a low DPI screen - you’d be wasting bandwidth and burning time. ![]() ![]() There are many formats and resolutions a developer must consider in order to maximize web performance. Images are a constant source of pain when developing websites. ![]()
0 Comments
Leave a Reply. |