How to make web images better
I took participation in survey from Chrome team about images
And the last question was "Anything else you’d like to tell us about images?". I thought and realized that there so many things to tell so after some point decided just to create this post and leave a link there 🙂First of all, I’m a pure back-end developer so I don’t know a lot of things about web but even from my small experience I had a lot of confusion and thoughts. Maybe some of them are stupid but a lot of other newcomers can have similar opinions.
Almost nobody using built-in browser compression
I prefer it use SVG vector images when possible and often it’s just more effective to use SVG file and then compress it with GZip or Brotli but then we need to add Content-Encoding header which is not always possible to configure especially if you just creating a bundle that will be deployed by someone else.
For example on in almost all legacy projects that I worked for as a Java Developer we just created a *.war file i.e. a zip archive with both assets and compiled code and then it was deployed to some old Tomcat webserver by sysadmins. So even if pre-compress all assets with Brotli (BTW which is not so easy to do with Maven because as far I remember the Brotli wasn’t yet ported to Java) so then we have to talk with sysadmins to enable serving pre-compressed files in Tomcat and then it turned out that is not so easy to do.
Especially this is a problem for limited web servers that work on embedded devices like OpenWrt and they don’t support compressed header but very limited in space. Here, for example, was some discussion about how to make favicon for OpenWrt’s Luci admin panel https://github.com/openwrt/luci/issues/2251
So it would be nice if browsers can support just files with a double *.svg.br extension and decompress them and show as SVG even if the Content-Encoding header wasn’t set. And then we can just specify <img src="/image.svg.br" /> in our code like a regular image.
As far I remember some browsers already support *.svggz extension but not *.svg.gz so we need to rename those files after gzipping.
Also, it would be nice to add support of ZStd compression which sometimes is better than Brotli on decompression or even LZ4 which can be useful for lightweight on-the-fly compression. But the best compression still gives the LZMA which is an old and well known compression and why it is not supported yet is totally unclear for me.
If you want to ask browser to download the file instead of showing it you can just use the Content-Disposition header. This is so easy to do and is almost safe change that it worth to considering.
Basically the same simple mechanism of auto-decompression by a file extension can be applied to all assets like JS, CSS and even on the HTML itself. Even raw bitmap images can use this because the PNG file is in fact just gzipped BMP file. So the whole PNG format could be simplified to *.bmp.gz files. The same is for woff font files which in fact just gzipped ttf files. But what will happen if you want to use Brotli instead of Deflate inside of the woff files? Does it supports different compressors or should we create a new file extension like woff3?
I guess there is a bunch of other formats that are just compressed containers for some data. But there are possibly hundreds of compressors, especially for media files. The double extensions can be a simple solution.
Here comes another interesting issue: if you have a set of images e.g. country flags that share a lot of common patterns so it may be built the common compression dictionary then it will be more effective to make a tar file first and only then compress it. This can reduce the resulted file size. But here comes another problem: how to use in the <img> attribute the file inside of the tar file?
We can do this easily in Java just use ! sign in URL like: my.jar!/assets/icon.png. So why not use a similar approach in browsers?
Dark images
Sometimes I using an extension that makes all websites looking in dark theme but images still are very bright and icons looks too colorful.
As far I know recently Safari added some feature to detect the dark mode of the browser but it would be great to add the same functionality as srcset to images. I mean that we can specify an image for the usual mode and separately for the dark mode (or even high contrast for blind people). As far I know the dark mode detection is made as CSS media query so here is another thing: it would be nice to change image source just by CSS.
For example if you have themes for website and you can simply upload one css file or another but for images, you can’t just change their src and you should use <div> with background image instead but then you have to specify image dimension for the div because it won’t be adjusted automatically on image loading.
Speaking more generally this is very unclear what is a "style" that can be changed via CSS and what is an attribute of the tag so this is a very controversial point but a real pain for developers. For example, a lot of devs even using the FontAwesome to declarative use logo images just by a specific some CSS class.
IMHO the correct solution is just make kind of JSON attributes files that are applied to the whole DOM tree, not only to style attribute as CSS makes.
Almost all images on a typical page are just icons. The same icons
And speaking about FontAwesome: for a lot of websites, especially some internal pages or admin panels, we just need some basic set of icons: edit, save, delete, search, setting, etc. In fact the basic set of icons is less than a hundred. Why not just add these icons to a browser and then allow to webmasters somehow use them? Yes, here is a big problem is how the icons actually look: should they be colorful or just be monochromatic like in FontAwesome or should the icons be the same as in your desktop applications? For example browsers already support System Colors i.e. you can make some element with the same color as a system button: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors
This is not widely used (I remember only one-two real life usage of the feature) but the main idea here is that browser can show some element more native to your system. But this is not needed in practice because you anyway have some design for website. This only makes sense if the user really wants to use some radically different color scheme like dark mode or high contrast.
Personally I don’t think that some browser can create ideal set of icons and especially ask another browsers to support this. But here can be a simple solution, the same as with fonts: all browsers already have the same basic set of fonts (Arial, Helvetica etc.) and if some font is not exists in system then browser can download the font file from the url specified by webmaster.
Here can be some similar solution: the browser already have images for some basic icons set and the same icons are accessible from CDN.
But to
Developers can see hash of the images, for example, sha384 of edit icon is sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC.
Then a developer can add just a regular image tag on the page with src to CDN and specified SRI hash:
<img src="https://some-cdn.com/edit.png" />
Browser can quickly lookup locally the image by the hash from SRI and don’t perform that call to download image from the CDN but just resolve it from local computer. So it kind of already precached images and the cache is shared between all websites. In fact there is few extensions for browsers that imitated "Local CDN" like
Actually while I wrote this I figured out that it will be enough just to create a good set of well designed icons on a CDN and promoted to developers as something that is good to use by default because those icons most probably was already cached in user’s browser. The only thing here is to allow to have cached files between different domains. I.e. if I once visited a site1.com that uses jquery-2.1.min.js file then when I visit site2.com that wan’t the same file with the same SRI hash it will be resolved locally from site1’s cache.
It’s important to make the lookup by the hash because the same jquery.js file can be delivered from different CDNs but in fact this is the same file.
Here can be a security hole if a hacker can find a hash collision with jquery-2.1.min.js then it can create a fake JS file which will be used instead of jquery-2.1.min.js
Another solution can be using of Emoji as icons. For example Save 💾 Search 🔍 Edit 🖊️ but I can’t find out a proper Emoji for remove or add button. I don’t think that the creators of Emojis was targeted to replace common computer icons. Here should be checked how rich are Emojis but actually a lot of developers just never thought about that this can be a good replacement for icons. At least from my experience.
We need some built-in browser image editor
At least simplest with crop and resize. Almost all images uploaded by users can be easily shrinked in size and converted to better formats but they just don’t care about image size. Why WebP is not used so much in internet? Because when I uploading the screenshot above to the post I just don’t wanted to spend some time and convert it from PNG to WebP or whatever this website supports. I can’t even don’t know about that possibility to minimize an image. But what if we can specify to a browser formats that website prefer and image size? For example
<input name="avatar" type="file" type="images"
preferred-formats="image/webp;auto-convert;max-width=320;auto-zoom"
max-size="15kb"/>
</code>
Or something like that. I.e. we can say: "Hey Browser, here is upload file for user’s avatar, we want any image files but we prefer WebP and if you can just convert it from JPEG to WebP yourself (auto-convert), also the image must be not wider than 320 pixels (max-width=320) but if user doesn’t want to resize the image then don’t decline it and just make this image smaller yourself (auto-zoom), by the way image file size is also limited to 15Kb.
What is important here is that after these lose compression we can show resulted image to a user so it can see the resulted quality even before uploading.
With this simple directive we can significantly reduce network load in the beginning. Yes, anyway, websites can have some image converters like ImageMagick on the server side but why to load network and servers if we can do this on browser’s side?
We, developers, are lazy to convert images
If you wan’t to make image optimization more popular just add WebP converter to Chrome Dev Tools. That’s it. It will easily increase popularity of the format in several times. When I wanted to try to convert images to the WebP it turned out that non of avalilable image editors doesn’t support it. When even MS Paint will have an option to save image as WebP file then it will be more popular. Instead I have to install some command line converter which is not so convenient. But having such converter built-it into browser can significantly simplify the process of converting.
Copyright tag
Most of images are taken from some stocks. When we use them in our articles we should add a short note at bottom about copyright of the image. This is annoying for readers, takes a visual place but what it mostly bad the text is pronounced by screen readers. So why not to introduce some new tag « which will wrap such info and just don’t show it at the page but makes thin info available via right click on the image.
Zoom
A lot of images, especially some schemas needs for some zoom-in functionality i.e. when I click on the image it will overlay and feet my screen width. Currently the only way to do this is to use some JavaScript. It would be nice to have this implemented by the browser itself. It can be some additional attribute zoom which indicates that on click on the image it should be overlay and zoomed.
For example usual website logo don’t need this but some picture with DB schema relations inside of an article will have such tag.
Without this I often just open the image in a separate tab and use Ctrl+ to zoom it and see details. This is very uncomfortable.
QR codes
This is something not really related but also quite important as for me. Recently I had a problem when I wanted to show a QR code with bitcoin address on my website. The generated QR code image was very big and wasn’t able to make it lower (we can’t use lose compression) so for me it was easier to add a JS library that generates a « with QR code. Anyway that JS library is quite big but what is more interesting is why QR codes are not supported by JS API or browsers?
Almost all browsers already have built-in QR support but it just not exposed via API so websites can’t use it. For example, imagine that you have a "Share QR" button by clicking on it browser can show a big QR code so it will be easy to scan from a phone.
How many websites use QR codes? Well, I guess quite a lot.
Update: Survey results https://web.dev/image-optimization-survey-2019/
stokito on software 
![https://some-cdn.com/edit.png"](https://some-cdn.com/edit.png"){kind=link}
Thanks for this! I’ve added the URL to the summary from the survey.