Earth Notes: On Website Technicals (2021-09)

Maybe nature is healing...

I am brewing up to serving the m-dot page when a browser requests a full-fat (www) main page, and has Save-Data enabled.

To work requires a little tweak to how the social media buttons JS is served, so that the above won't break them. I have that in train.

Then all that should be needed is a bit more Apache code on the desktop side to check for Save-Data (and set Vary) when serving those main pages. No other HTML (etc) changes. Simples.

I will get that in place later...

The 'full' link in the header navigation will be ineffective, but the site is returning a lower-weight object as the user asked for. (I could nominally fix the link with some Referer cleverness.)

And yes the served lite-instead-of-desktop HTML will be slightly heavier than it need be because it will contain redundant prefixes for absolute paths to the desktop root, but whatevs...

The first part of the config, added to the www setup, adds Save-Data to the Vary header for the top-level pages to which this might apply:

# Serve 'lite' versions of main HTML pages when Save-Data is on.
# Top-level .html files (not starting with "_") are candidates.
<IfModule mod_headers.c>
  <LocationMatch "^/[^_][^/]+\.html$">
    Header merge Vary Save-Data
  </LocationMatch>
  # Rewrite to m/ version if extant and Save-Data is present.
  # Make gz/br precompressed serving work...
  # If client accepts brotli (br) compressed files...
  RewriteCond %{HTTP:Save-Data} on [NC]
  RewriteCond %{HTTP:Accept-Encoding} br
  # ... and if the pre-compressed file exists...
  RewriteCond %{DOCUMENT_ROOT}/m%{REQUEST_FILENAME}br -s
  # ... then send .XXXbr content instead of .XXX compressed on the fly.
  RewriteRule ^/(.+)\.(html|css|js|xml)$ /m/$1.$2br [E=no-gzip:1,L]
  # If client accepts gzip compressed files...
  RewriteCond %{HTTP:Save-Data} on [NC]
  RewriteCond %{HTTP:Accept-Encoding} gzip
  # ... and if the pre-compressed file exists...
  RewriteCond %{DOCUMENT_ROOT}/m%{REQUEST_FILENAME}gz -s
  # ... then send .XXXgz content instead of .XXX compressed on the fly.
  RewriteRule ^/(.+)\.(html|css|js|xml)$ /m/$1.$2gz [E=no-gzip:1,L]
  # No precompression usable.
  RewriteCond %{HTTP:Save-Data} on [NC]
  RewriteCond %{DOCUMENT_ROOT}/m%{REQUEST_FILENAME} -s
  RewriteRule ^/(.+)\.(html|css|js|xml)$ /m/$1.$2 [E=no-gzip:1,L]
</IfModule>

(For simplicity this ignores the extra overhead of a slightly-wide match.)

The rule for serving the right combination of .webpL, L, .webp or original image has been tweaked too:

# Serve alternate compact WEBP images if possible.
# Ensure caches handle Accept and Save-Data correctly.
<IfModule mod_headers.c>
  <FilesMatch "\.(jpg|png)$">
    Header merge Vary Accept
    Header merge Vary Save-Data
  </FilesMatch>
  # Four cases for primary images (.png, .jpg):
  #      Save-Data   image/webp  Serve
  #  1   on          yes         .xxx.webpL if extant
  #  2   on          no          (or no .webpL), .xxxL if extant
  #  3   x           yes         .xxx.webp if extant
  #  0                           .xxx (no rewrite)
  # Aim to serve in priority: .webpL, L, webp, original.
  #
  # 1 - Save-Data, can accept WEBP, have .webpL file: serve it!
  RewriteCond %{HTTP:Save-Data} on [NC]
  RewriteCond %{HTTP:Accept} image/webp
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME}.webpL -s
  RewriteRule ^/(.+)\.(jpg|png)$ /$1.$2.webpL [L]
  # 2 - Save-Data, cannot accept WEBP or have no .webpL, have L file: serve it!
  RewriteCond %{HTTP:Save-Data} on [NC]
  RewriteCond %{HTTP:Accept} !image/webp [OR]
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME}.webpL !-s
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME}L -s
  RewriteRule ^/(.+)\.(jpg|png)$ /$1.$2L [L]
  # 3 - can accept WEBP, have .webp file: serve it!
  RewriteCond %{HTTP:Accept} image/webp
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME}.webp -s
  RewriteRule ^/(.+)\.(jpg|png)$ /$1.$2.webp [L]
  # 0 - by default do not rewrite.
</IfModule>

As of today, GSC is showing all-zeros Core Web Vitals for desktop, but 16 good for mobile, all of which are https://m. URLs. Futher, the mobile good cohort is slowly growing and in place several days.

Your site has 87.1% URLs with a good page experience.

Maybe this is still the rubble stopping bouncing after the AMP shutoff.

I still don't know what's going on with 'page experience' in GSC. All the signals (Core web vitals, Mobile Usability, HTTPS) are green. At this moment I am seeing ~83% URLs with a good page experience. But this number seems to be very volatile and I don't think it's changing much because of anything much I am doing except possibly continuing AMP DTs.

The other thing that could be happening is people coming back from holiday and surfing EOU, pushing up CrUX stats enough for GSC to use...