Technical Web Design
I once heard of a meeting which attempted to select between competing proposals for the design of a website simple by studying printouts of the designs. Whilst artistic design is a part of good website design (and a part about which, you will readily discern, I should say nothing), user interaction and technical aspects are also important. These notes consider the more technical aspects.
Standards
It is important that one's website displays correctly on a variety of browsers, including those yet to be released, and including more specialist browsers such as those with speach output, or other aids for the disabled. Even the best funded organisations struggle to gain access to future browsers, so it is best to ensure that one's site follows the published standards for HTML. Most browsers "helpfully" do their best with incorrect HTML, and show no warnings when doing so. However, the behaviour of different browsers in such circumstances can be very different.
Checking is easy: simply point one of the on-line checkers at one's page. The best-known are:
Also useful is the link validator validator.w3.org/checklink, because search engines are unlikely to be impressed by pages which are full of broken links.
Images
Images make a page look great, but they can also greatly increase its size. Not usually an issue to the developer, who generally has a very fast connection to the server hosting the page. But it can be an issue to those with slower connection, especially mobile-based. Increasing a page's download time does not improve the user's experience, and sending unnecessary data around costs money, and CO2. Google will complain about excessively large images if one uses its PageSpeed Insights tool.
Moving images
Who wants to leave their browser displaying a distracting moving image whilst they work on something else? It is a good way of persuading people to navigate away, even before one considers any impact on the battery life of mobile devices. An if one ever tries running a browser via some form of remote desktop, then it can eat network bandwidth too.
On demand videos are a very useful part of the web. Unsollicited animation is much more rarely helpful.
Scalable images
Text on webpages scales smoothly according to the resolution of the display used. Why cannot graphics too? The two main scalable graphics formats, the ancient EPS, and the more modern PDF, have never caught on for inline images in web pages. Browsers simply do not support them. So one is left with SVG.
SVG can combine text, lines, curves, etc in a similar fashion to PDF, and, like PDF, can include bitmap images too. Graphics programs such as Inkscape, Adobe Illustrator and CorelDRAW can produce it, as can software such as Gnuplot. It is a text format, and binary data (bitmaps) must be Base64-encoded, which inflates them by a third.
Web servers often assume SVG files are compressible, and
compress them on the fly before sending them (just as they do with
HTML files). However, one can achieve better compression ratios and
faster serving by pre-compressing. The standard suffix for a
pre-compressed SVG file is .svgz, rather than
the .svg of the uncompressed version. One should
compress with something like gzip -9
or zopfli.
Note too that SVGs containing fonts but without fonts embedded may render very differently on different systems, perhaps even with the text not appearing. I don't have a good answer...
Bitmaps
The first problem is choice of resolution. The days when an image
was served for a static size, e.g. "width=300", and one
expected that to mean 300 physical pixels on the device displaying
it are long gone. Now one often sizes images to a percentage of the
window width, and, even if a fixed size is used, there may be 1.5 or
2 (or more) physical pixels per virtual pixel in HTML-space.
But there is no need to go mad. People with 4K displays tend not to use them to run their browsers expanded to the full width of their screens, and, even if they do, they tend not to expect images to be the full width of the browser window. And in most cases the images are present for illustration, not minute examination. The resolving power of a Human eye is often quoted as one arc minute, or about 0.3mm at 1 metre. So a 1,200 pixel wide image a comfortable one metre away could expand to the width of an A3 piece of paper before the dots are too apparent. There is rarely a need for more pixels, and, for an image which is expected to take under half the width of the browser's window, 600 pixels would seem plenty.
Photo-like images
The ubiquitous JPEG seems most appropriate for these, rather than more modern formats with poorer browser support. JPEG is a lossy format, and sharp transitions (e.g. the edges of letters) get badly blurred. However, photos compress very well, much better than with PNG. Unlike SVG and PNG, JPEG has no support for transparency.
The JPEG compression algorithm consists of a lossy part and a lossless part. The lossless part can be done optimally, or quickly and sub-optimally. Most cameras use the quick and sub-optimal route, and also include data about the precise camera model used, which one might not wish to reveal.
The lossy part is controlled by an ill-defined "quality factor". One should reduce this until a loss of quality is apparent, and then increase again until acceptable quality returns. Many JPEGs on the web can be halved in size by tuning this parameter better.
One might also consider the benefits of trading quality factor against resolution. Increasing the resolution whilst decreasing the quality factor might lead to a similar file size, and yet an image which scales better.
Finally, if the image is greyscale, do use the greyscale version of JPEG. It will be smaller, and much quicker to decompress.
Other images
PNG remains the format of choice for images which cannot be produced as SVG and which have sufficient sharp transitions (text, lines, etc) that JPEG is inappropriate. PNG is lossless, so all PNG compressors will produce output which displays identically. File-sizes may differ by 20 to 30% though, so choose a good one, such as pngcrush, OptiPNG, zopflipng or bmp2png.
Finally, do you really need completely lossless compression? Would a reduction of a 24-bit colour iamge to 21 bits or 18 bits look almost as good (or even indistinguishable on most displays)? The panda at TinyPNG thinks so, as does the author of bmp2png (although they use different techniques).
WebP
Not recommended as currently not supported by Safari or Internet Explorer (May 2020). Also it is confusing: it combines a lossless and a lossy format under a single name. In terms of compression, the lossless format is better than PNG, and the lossy format is better than JPEG. Both are more complicated to decompress though. It offers large savings over JPEG and PNG done badly, and still significant savings over JPEG and PNG done well. The half-way house of PNG and JPEG done well, which retains compatibilty with the widest range of browsers, seems preferable.