Earth Notes: On Website Technicals (2018-02)

Updated 2024-02-19.
Tech updates: Bing head, a saved byte, boxed cols and rounded corners, Google AdSense Auto Ads.
Bing wrong-headedness (not being able to read some correct heavily optimised HTML5) was unexpected, though a fix was easy; AMP turns out to be even more picky. This was also the start of a 10-month bumpy ride with Google's AdSense Auto Ads, turned off at least temporarily at the start of 2019 as far far too pushy (oh, and the "jank").

2018-02-25: Google AdSense Auto Ads

I am experimenting now with AdSense Auto Ads on this site and some others. In theory Google AdSense automagically picks the best number, places, colours, etc for ads, thus nominally balancing page weight and revenue with user experience.

I also have Ad balance enabled tentatively as an AdSense 'experiment' to help balance revenue against weight.

I get pitiful (pennies per day) revenue for this site, which is why I have turned it off entirely for the 'lite' site for example.

Because the Auto Ads code wants to live in the page head, and thus is on the CRP (Critical Rendering Path), I am having to avoid Auto Ads and use my normal ad injection when the header is already getting big such as with large chunks of supporting CSS.

Update 2018-05-06: after more Googling for Google AdSense info (yes, using Google's search engine) I found this: If you don't have access to the head tags of your page, then you can place the ad code at the top of the body instead... The sample code is slightly spoiled by some obvious errors as of today, but the intent is clear. So I can have videos and Auto Ads on the same page. Indeed, I can simply move the code out of the CRP. Today I have moved it to just after the first (h1) header tag. I may push it further down after the description and hero image in due course. I doubt many visitors would notice the difference though!

Update 2018-05-16: the Auto Ads script is now injected after the title, description, hero image, table of contents, etc, just before the body text from the HTML source. Next is usually a "See also" links sidebar, so a fair amount of real content in the CRP before the script bytes.

2018-02-18: Boxed Columns and Rounded Corners

I have been trying to tweak the presentation of the front page, to delimit the new/popular/updates columns a little better, and I have for now boxed them and rounded their corners with the CSS fragment border: 1px dotted gray; border-radius: 4px.

I am sure that George Bernard Shaw had a pithy quote about being able to improve any page with a rule on it by removing the rule, and he is probably still right, so this may go away again!

2018-02-01: Bing Head

Early in the month (possibly at the end of the previous one) I took a quick peek at my Bing Webmaster Tools and noticed that BWT was reporting a lot of SEO errors, most obviously that it could not see my title tags.

The HTML5 spec says that the html, head and body tags are optional where they can be unambiguously inferred. Google goes further and encourages removing them wherever possible to save bytes.

I am a sucker for saving bytes off-line and on the wire, and Googlebot and the W3C HTML5 validator and every browser I tried seemed happy.

Bing's bot seems lost without the opening head tag, though does not need the closer, nor any of the other optional tags. So, to keep Bing happy, for the 'full' pages, that one tag is re-inserted. (It is still stripped from the 'lite' page version.) Six bytes wasted before compression but everyone is fairly happy.

Byte regained

A little later I realised that I had at least one unnecessary newline in the head (and thus the critical rendering path) that I could remove. (And thus trim a few bits back from my earlier Bing TLC.)

I construct the HTML pages using a wrapper script with some 'here text' blocks, eg:

cat << WORD
blah blah blah $VARIABLES other nonsense
WORD

I worked out that I could steal that key newline back with a formulation:

awk '{printf(%s, $0}}' << WORD
blah blah blah $VARIABLES other nonsense
WORD

Micro-optimisations for the win! (And no, "echo -n" has never been reliable nor consistent across shells and OSes.)