Pretty much every front-end developer knows that we need to deliver the smallest possible images to users without affecting their quality. We all know how to achieve that. But it’s a chore nobody likes doing. Also from a business standpoint, it takes time, and time is money. So, "good enough" is just good enough.
Let me share how we've improved and automated perfect image delivery without creating more work for developers.
Maybe it's not you, but it's many—probably most of us.
You export a picture in PNG at 2× the intended size to cater to high-density screens and use it in an tag. If you're willing to spend an extra 30 seconds (or more), you do better: you convert it into WebP and place both versions in a
This is the "good enough," and it often really is.
But it's not perfect. New iPads are large and can utilize 2.5× or even 3× images. On the other hand, a standard corporate Lenovo ThinkPad doesn't need that extra detail, and a 1× image is perfect.
And honestly, all that is fine for manual work. Nobody can spend 15 minutes on a single picture.
For my perfectionist brain, "good enough" isn't what the phrase says. Also, some of our clients are in highly competitive fields, so we started researching options. It didn't take long. We already knew that browsers send HTTP headers indicating the image formats they support.
What we needed was to find out that the
With this, we have all we need:
Here's how we automated the image optimization process:
Accept Any Image Upload
We let developers and admins upload and save whatever picture they want (of course developers are more careful, need to be). Our system can handle anything - even that 250 MB JPEG straight from a DSLR camera that we managed to successfully convert and resize and then burst in laugh when we saw the logs.
Automated Conversion and Compression
Once an image is uploaded, our system automatically:
Why 90%? Because the last 10% of quality often results in highly diminishing returns. You save significant storage space and bandwidth without any visible difference in visual quality.
Generate Multiple Resolutions
For each image, we generate multiple sizes based on pixel density multipliers:
3×
This ensures that devices with high-resolution screens get sharp images, while others receive appropriately sized images.
And for future-proofing, we just add or change numbers and all is automatic to handle (we don’t do VR / AR content just yet, but I suspect that’s the tech where it’ll come in handy).
Dynamic Image Serving
In our HTML templates, we specify the desired image dimensions (width or height). Our server-side code then:
Generates the appropriate
The browser automatically selects the best image based on the device's capabilities.
The result looks like this:
<picture>
<source srcset="/Upload/2024/03/11/tn-w200-frantisek.webp 1x,
/Upload/2024/03/11/tn-w300-frantisek.webp 1.5x,
/Upload/2024/03/11/tn-w400-frantisek.webp 2x,
/Upload/2024/03/11/tn-w600-frantisek.webp 3x">
<img src="/Upload/2024/03/11/frantisek.jpg" width="2222" height="2963" loading="lazy" alt="Video poster">
</picture>
If we, as developers, avoid perfect resizing and conversion of pictures, we can't expect common admins or clients to do it. Therefore, we let people upload what they want, and we process it (good UX and client relations).
Initially, we didn't expect resizing to be that intensive and we completely killed our demo server couple times. So we developed this approach:
I know we could use any of the public commercial services for picture resizing, but to be honest, this was an afternoon of work (meaning - way cheaper) and we have all aspects under control.
We are so happy with this solution that we're thinking about polishing this resize and conversion service and enabling it for your use. Is there any interest in such a service? Let me know. Maybe we can cut a great deal.
For Developers, By Developers - possibly a meme at this point, but hard truth in this case.
I can't share the resizing aspects, but I can show you the selection and
<picture>
<source srcset="/Upload/2024/03/11/tn-w200-frantisek.webp 1x,
/Upload/2024/03/11/tn-w300-frantisek.webp 1.5x,
/Upload/2024/03/11/tn-w400-frantisek.webp 2x,
/Upload/2024/03/11/tn-w600-frantisek.webp 3x">
<img src="/Upload/2024/03/11/frantisek.jpg" width="2222" height="2963" loading="lazy" alt="Video poster">
</picture>
We use a custom templating system where HTML is mixed with PHP (I know it’s not common, but it works best for our needs).
<div> <p>This code shows a logic. What we actually do is we have a database of files and their variants, so instead of paths, we work with arrays and objects. But, as I said, this beautifully shows the logic of what we do.</p> <p>And as you can see, if front-end dev writes this code or <img> tag, who cares in regards to time spent.</p> <h2> Let's Point Out Issues </h2> <p>This method is built such that it doesn't cause any issues in the real world. But it has two areas of improvement which I can't wait to nail down (yet again, just out of perfectionist’s perspective).</p> <ol> <li> <p><strong>Double Queueing</strong></p> <p>It queues for resizing after the first load of that image on the front end. If the website has high traffic, it can actually queue it twice. In real-world use - it's fine; so it processes twice. It happened only twice in a year on high-traffic websites.</p> </li> <li> <p><strong>Initial Display of Large Images</strong></p> <p>If an admin uploads large pictures, it takes 5–10 minutes to resize and convert since it's happening in scheduled tasks. Meanwhile, the large pictures are displayed on their webpages. In real-world use - usually only the admin sees it because new content often takes a little bit before users visit it. On high-traffic websites, we shorten this timer to as low as 1 minute, so again, not an issue.</p> </li> </ol> <h2> Storage Considerations </h2> <p>You might point out that now we have multiple images for every size and format, which could be storage-intensive. If your website is full of pictures and galleries, and you need thumbnails and detailed images for each, yes, it will use a lot of storage.</p> <p>But disk space is the cheapest component these days. The benefits in performance and user experience usually far outweigh the costs. And with that, you've lowered your CPU and entire infrastructure load.</p><p><strong>One side note -</strong> Why care about infrastructure? Someone else is dealing with that, right? That's what I hear a lot. The simple fact is that it's not true. If a hosting company has to add hardware for higher bandwidth due to increased loads without more customers, they won't be able to sustain it and will happily pass those costs to the server renters.</p> <h2> Our Real-World Results And Experience </h2> <p>In Google Search Console, Core Web Vitals are greener than ever, load times are generally much lower, and visitor session times are higher (a couple of percent, but I'll take it!). And there's no additional work for developers or admins - everything just works smoothly.</p> <p>I highly recommend every dev use something like this. It did a lot for us while we could actually forget this thing in the background exists and does its job. And I am literally writing this article longer than it was to set up and polish all the systems.</p> <h2> Conclusion </h2> <p>By automating image optimization, we've achieved:</p>
If you're tired of the chore of image optimization, consider automating the process. It's a win-win for everyone involved.
Do you use some systemic solutions for your images?
Or do you manually convert them?
Have you tried AVIFs? They have amazing benefits for larger images.
The above is the detailed content of Web Images: Resize and Convert Perfectly (and Automatically). For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
