To get an image on website is trivial. To get an important image to meet some metric (frequently performance/ page render speed) is more work. The article title is trying to be vague about technology/implementation, as the requirements shouldn't predetermine the outcome. I am capitalising HTML tags, to make it more readable, I know its lowercase in HTML5.

Image architectures

Off the top of my head, I can display a picture inside a browser via:

  • An IMG tag
  • PICTURE tag, RWD version of previous
  • The OBJECT tag
  • CSS background-image
  • Symbol fonts, and the relevant 'letter'
  • An inline image with SVG (so the image data is literally part of the HTML)
  • Most expensively, with “CSS + div drawing” (I have only seen this a few times, as a portfolio piece)
  • Download as attachment for large images

With 2020 technology, what is the fastest?
For this article, assume the picture is a line drawing, rather than video, or a photo. Secondly this is for static graphics. Thirdly, this is not applicable to email.

Basic optimisation steps

[To me, this section is old material, and entirely boring]

  • PNG palette size; when PNG is best, use pngcrush 1 2 or optipng 3 etc to reduce the palette to the colours you are using.
  • PNG image scaling 4 5 general algorithms 6 7
  • If using SVG, pls see SVG optmisation
  • If you inline images into the HTML, you can avoid extra HTTP requests (in June 2020, my site is doing this with the favico as an experiment; I will probably go back to a separate file after June). If there is any media filtering (e.g. the viewer is a search engine); this won't behave as expected.
  • With non-text picture formats, it is possible to inline things, as you can have a dataurl 8 and use base64 9 10; however you start paying with increased data bandwidth (+33% volume) instead of increased HTTP requests.
  • With a Picture element, you can send images to fit reported screen-size (obviously a 2000px wide image doesn't work well with a cheap low-res 'driod device)
  • Use a CDN, so data can get to your client faster; if the client isn't in the same country as your server.
  • Services like 11 which allow some movement at fairly low res, see docs 12
  • Disable any image scaling; if the image is too large, use option2

Aside: IMG are best for accessibility as every tool knows how to access them. How can you add a tooltip/ alt text to a background-image? Or the aria-hidden meta data for “ignore me”.
PICTURE elements support title, and aria items but not alt attrib (although a inner IMG for MSIE support would do).

Literature Survey

  • I need to restructure this data, its currently just a brain dump
  • Geographic proximity has a large impact on all network operations. Many people use CDN to be nearer their clients (yes this point is twice, as it is very significant). Reference: In my current role, page render time is doubled when I am using an NY based server, rather than one I can jog to in LDN. This is with the identical codebase, and sufficient server resources that server contention isn't an issue.
  • Obviously the mechanics of putting an image on screen aren't affected by which code invoked it. The mechanism does affect when the process is started, and the DOM paint order. I pulled some notes 13 14. This is focussed on JS rendering, so is abit tangential 15. As a resource focussed on tools in Chrome try 16 17.
  • Applying media attributes to CSS assets 18 will allow the browser to do less work, which is faster. Likewise marking optional JS (optional for first page render) as “defer” 19 20. Thirdly performance can be increased by avoiding unnecessary paints, detailed in 21
  • Notes on analysis of network performance, for mobile in 2013 22 (listed for background, otherwise skip this link).

  • WRT PNG, the technical term for 'shrink palette' is 'where possible use “PNG-8”'. It is stated to prefer to use pngquant 1 for this, as it handles transparencies in a more useful fashion than ImageMagick 2 3.
  • Common knowledge: DO NOT overwrite the same JPEG (or other lossy formats) image continuously, as it is a lossy format, and will store slightly less quality data each time you hit save. A management strategy is to keep a untouched master copy in TIFF, or camera RAW formats (if you do this, keep a change log, so you can easily build the result image again).
  • Common again: If printing is an important user story; you need to be using IMG or PICTURE, as most “prepare to print” processes strip random backgrounds (as a plain white background is much better on paper).
  • Also fairly common knowledge, reduce cookies used with the transmission images. They slowdown the request, which is via slower upload channel; but are unlikely to be used for the image.
  • Not specifically to do with images; but trimming unused sections from fonts/ libraries can speedup image loading, as there is less contention.
  • I saw today on twitter, a proposal for CSS ruleset “prefers-reduced-data” 4 5 current discussion 6. This would allow people who know they have slow bandwidth to get a better performing app.
  • To extend the previous item, in JS there is `navigator.connection` 7 in Chrome (and FF when enabled); which supplies some readonly data about client internet connection speed. I'm not sure practically this is any use (by the time you have downloaded JS, parsed JS, and executed it; its abit late to check line-speed).
  • A really big/detailed SVG may be affected by a “paint-order” attribute 8, but I have never made an image that complex.
  • PNG render time can be made less obstructive with interlacing 9 (may increase size) 10 11. Interlacing is good when you have many viewers/ customers in areas of less stable infrastructure ~ “the third world”; as there it will still take a time to download images.
  • It is important to use a correct size image for small screen devices (i.e. phones); but in realistic situations, interlacing is useful on phones (not so much impact on DSL lines). This is less conspicuous with 4g than 3g; however “realistic 4g” isn't the same level of service that you saw in the showroom.
  • JPEG render time be reduced by using newer versions of JPEG (JPEG 2000, JPEG XR). I don't use many photos in my boring b2b work, also this article is about line drawings 12 13 14. The second link is quite detailed. Notes on JXR (shortened form of 'jpeg xr', that seems common on the internet) 15 16 17 show that is it useless (MSIE only), and should be ignored.
  • If you need to use JPEG, Mozilla published mozjpeg 18 19, which will give you a better JPEG file.
  • Encode images in webp format 20 21 22 23 24 caniuse: 25
  • SVG rendering can be improved alot (by editing) when you are using an SVG image that was converted from another format. The SVG on 26 are a good example of this. The vector drawing doesn't look as good, and is slow.
  • Fonts haven't been mentioned so far; the control mechanisms “link rel” attribute for using them are discussed 27 28. Updated ~ 2020 ~ technology on what fonts formats to use is in web-font-2020. Note the first two links are using JS to load fonts, which would be slower. I would definitely host the font files on your own server that is fairly near your userbase physically, its not much hassle to set a mime header; but avoiding all the middle people is a noticeable performance gain.
  • Obviously for users who notice bandwidth effects, ensuring your font files support the relevant section of UTF-8, and only that section of glyphs will reduce the download size; and therefore increase speed; secondly “big widely usable fonts” encode a variety of font glyph weights, if you only include the weights you are using, this will again reduce download volume. You need some type of font editor to do this.
  • Article on measuring font downloading performance 29. This article also supplies ways to get the fonts on screen faster, by rearranging content; but I think they would just slow down everything that isn't a font.
  • Some browsers process 'text-rendering' CSS hint; to encourage a browser to be a fast renderer, or to more readable 30.
  • Just as a counter note, some people may block fonts 31 for security and performance reasons. Remember to degrade gracefully.

Conclusion

  • I need to build some of these, to look at the performance; and what the images look like with compression.
  • IMO, a font renderer library will be very optimised, so if we can trick using this to draw images we should have faster results. Extra test here.
  • I, on the odd occasion display a photo; and will keep using PICTURE tag to support a range of screen sizes.
  • I, on the odd occasion display a photo; and will attempt using WEBP format.
  • I more often render a graph, or display a diagram; and will keep using SVG.
  • When I need to display a corporate logo (not my employer) will try to use a symbol font
  • When I need to display my employers logo, I will try to gouge a budget to get the logo into the symbol font because I think its cool, but maybe over-engineering.
  • When I need to render an image in a generated PDF, I don't expect to be able to use SVG; I will have to fail over to PNG or TIFF.
  • When I need to render an image in an email, I will attach the image to the email and use JPEG or PNG (because a lot of people use outlook)

Some similar articles in research

Some similar articles in images