Earth Notes: On Website Technicals (2020-05)

Updated 2020-05-31 11:44 GMT.
Tech updates: lower-fi audio and video for AMP, hi-fi for hi-res screens, podcast RSS episode images, lazier heroes...

2020-05-31: Lazier Heroes

Given Firefox's aggressive image-loading laziness (deferring anything not actually in the viewport), I'm making all the images on the home page lazy, bar the first big one (which may get inlined for lite/AMP anyway).

I'm also aiming to adjust the image insert mechanism to allow me to place such carousel images in tables etc (eg not as floats).

I'm warming up to this by inserting a hero image for the most popular page of the selection inserted automagically in the foot of each non-lite page.

2020-05-24: Hi-fi Desktop Heroes

For visitors to the full-fat / desktop version of the site, I'm considering enhancing select images for displays with a pixel density greater than 1, ie more physical pixels than CSS pixels.

The most obvious candidiates are the page-top hero images, which are there to be pretty, and could be made prettier for such devices.

For reference: my MacOS Air laptop is 1440x900 (pixel-ratio 1), and my Fairphone 3 is 2160x1080 landscape (pixel ratio 3).

In portrait, which is probably how most smartphones are used, according to MyDevice the widest smartphone screen listed is 1440 physical pixels.

It may therefore be worth providing a 1440w image (x1.8 for the 800 hero) option for those devices with ratio greater than 1.

I probably don't want to inflate my existing byte limits per image (absolute and per CSS pixel). So I shouldn't try for a larger image where the x1 image is at or close to the limit.

I also don't want to falsely inflate an image, so wouldn't do this where the source image is no larger than the CSS render size (eg 800px), and probably not unless it's at least the inflated intrinsic size (eg 1400w).

In any case something like this might form part of a media query (min-device-pixel-ratio: 1.5) or the newer (min-resolution: 1.5dppx) in sizes or on a source line in picture.

A simple first step may be on desktop mode to only use the 640px image if the viewport width is 640px or less and the resolution is not (much) higher than 1 eg (max-resolution: 1.5dppx). Or maybe use (max-resolution: 280dpi) for the latter for wider support, and to better pick out high-end devices where users may be less bandwidth-sensitive. (I could also throw in a maximum height so that the hero doesn't take too much of the vertical display area.) Older browsers that don't recognise dppx may wastefully pull in the full 800w image.

Testing the water, I am now selecting the 640w hero image with (max-width:640px) and (max-resolution:280dpi).

Podcast RSS Images

As a second experiment for today, I'm including each episode's primary SQTN, if any, in the podcast RSS feed entry for that episode. Possibly I should restrict to those that are square and in a reasonable size range (1400w to 7000w). But for now I'm assuming that most feeds won't use such an image at all, and that others will quietly ignore anything that they don't like.

2020-05-12: Feeds Moved

A few Atom feeds that were at the top level of EOU have been moved to under rss/. This is to help reduce the size of that critical directory. Decluttering may improve site-serving performance.

I also (belatedly) switched on a weekly fstrim to help maintain filesystem performance, with a new /etc/cron.daily/fstrim script.

2020-05-10: Lo-fi AMP

Until now, I served up full-fat video and audio to AMP page users. Since they are probably on mobile, with potentially only mono audio for example, and limited data plans, this probably wasn't the right thing to do. So now, for 'lite' and 'AMP' the lower-bandwidth versions of audio and video are now served (usually mono for audio also, for example).

Possibly I should make it clear for mobile/AMP users that they are getting the lo-fi version by default.

(For some files, especially small ones and/or those primarily for internal use, lo-fi versions may not be provided. They may then be created automatically in some cases for video, but not yet for audio.)

Sources and Links

  • Real-World Effectiveness of Brotli: If enabling Brotli is as simple as flicking a checkbox in the admin panel of your CDN, please go ahead and do it right now ... if you haven't or can’t enable Brotli, you’re not missing out on much.
  • Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID), Cumulative Layout Shift (CLS).
  • Feed your Image via Atom or RSS.
  • How to add the image as part of RSS feeds: Wrap your description in CDATA comments and insert the images as HTML img tags.
  • Add a podcast using an RSS feed: for Google at least each episode can contain image data which must be square, 600w to 7000w, pref 1200w or larger, JPEG or PNG.
  • Change Podcast Image: ... enter the new image URLs in the feed ... minimum 1400 x 1400 px, maximum 3000 x 3000 px, JPG or PNG, RGB, and file size less than 500kB. Note however that the episode images which appear in small form in at the top of iTunes (on a computer) when playing (and in large form when that is clicked) have to be actually embedded in the media file - please see this page. The images in the 'itunes:image' tags in the feed don't appear when subscribing in iTunes, and only in the Search results in the iTunes Store, though they may appear in the Podcasts app ...
  • chromestatus.com: HTML & JavaScript usage > all features > timeline: suggesting that in May 2020 ~2.3% of (sampled) pages use loading=lazy on at least one image (from zero a year before), cf 0.25% for eager.
  • Use density descriptors: These days [2018-11-05] most devices have a device-pixel-ratio between 1.0 and 4.0. ... This ratio doesn't have to be a whole number. 1.5, 2.4, and 2.5 are all device-pixel-ratios of common devices.
  • MyDevice: Compare devices a table including pixel ratios of 1:1 to 1:4. In portrait widest smartphone screen listed is 1440px.