Earth Notes: On Website Technicals (2020-05)Updated 2020-06-09 06:52 GMT.
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).
The warm up to this is inserting a hero image for the most popular page of the selection inserted automagically in the foot of each non-lite page.
There is now a
respsml class for responsive images (up to) 33% of main container width, that will be resized down if necesssary, and that will have a
srcset and a wrapper link created. This is in test on a couple of pages. There are still some rough edges to fix.
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
or the newer
sizes or on a
source line in
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
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.)