Each entry in the “Gems in the rough” series is a collection of tips, explanations, and/or idle observations which I hope will be at least somewhat useful to those of you with websites built by static site generators (SSGs).
Privacy-respecting YouTube embeds
Since it’s highly unlikely you spend time perusing any website’s privacy policy, much less this site’s, I wanted to note here a little change I made to the latter a few days ago. When I first posted the policy last year, it was pretty bare-bones because, frankly, I didn’t yet understand how invasive certain items could be. Fortunately, that particular ignorance didn’t last long; less than a week later, I added a “Notes about external services” section, which included the following:
Embedded videos
I no longer embed YouTube or other sites’ videos, since they can and do transmit personal information through cookies. In the two instances where I formerly did — “Some curmudgeonish thoughts” and “Coherence and COVID-19” — I replaced them with clearly identified links to their original locations, and footnoted each link with a reference and link to this privacy policy.
While it was satisfying to protect my visitors from those cookies, it was simultaneously galling that I no longer could provide the content enhancement that properly chosen video embeds can offer. And, yes, I later learned there’s a (sorta-)no-cookies YouTube domain but, until recently, I was unaware there was a way to use it for what appeared to be a normal embed — i.e., a video frame with an overlaid “play” button — without plenty of manual labor for which, at least until my recent retirement, I simply didn’t have time.
As a result, I was delighted a few weeks back when I happened upon “Faster YouTube embeds in Eleventy” by Sia Karamalegos. While it was (as the title implies) concerned mostly with doing higher-performance video embeds, it also showed me a way to have those embeds without worrying about the cookies. Ms. Karamalegos’s article described how to use the lite-youtube-embed package to provide just that. I promptly implemented her solution and was able to restore those two aforementioned YouTube video embeds, plus add any others in the future as I wish.
For example, adding the following to the Markdown in a suitably configured Eleventy site:
{% set videoTitle = "Every programming tutorial" %}
{% set videoId = "MAlSjtxy5ak" %}
{% include "layouts/partials/lite-youtube.njk" %}
. . . produces this embed of a short video which just happens to be one of my favorites because its sarcastic point is so spot-on:
Note: Clicking the video constitutes your consent to view it via YouTube (including cookies). To view it on the YouTube site instead, please use this link.
I altered the code a little bit to add the disclaimer after each video, which I believe keeps this site in good shape where the GDPR and other related privacy measures are concerned. I made this additional change after noting the concerns expressed in “Embed YouTube videos without cookies” by Per Axbom. In short: just using the (sorta-)no-cookies YouTube domain isn’t enough; it’s also necessary to advise your visitors that actually playing an embed from that domain, the domain name notwithstanding, still loads cookies.
Incidentally, this works in Hugo, too, and even more compactly in your Markdown content. Just create a Hugo shortcode with the same items that Ms. Karamalegos’s article prescribes for an Eleventy partial — with obvious adjustments for Hugo’s Go-based templating that I won’t describe in this space — and insert it in your Markdown (here, the shortcode file is called lite-youtube.html, so we call it with lite-youtube):
{{< lite-youtube videoTitle="Every programming tutorial" videoId="MAlSjtxy5ak" >}}
Faster CFP builds
Cloudflare continues to make back-end changes in Cloudflare Pages so it’ll be a good place for one’s static website to live. Until recently, the build process took far too long on each new push to a site’s CFP-linked online repository, as I noted in a previous “Gems in the rough” post.
The specific part of the process that racked up the biggest delay each time was the initialization of the build environment, typically taking at least two to three minutes on its own even before the build proceeded to, um, build the site and then deploy it to the Cloudflare network. But some particular fix came into play around the middle of August, after which that segment of each build began clocking in at just around thirty to forty seconds. So, now, a total build time for one of my CFP-linked repos will usually be slightly over a minute.
While that’s still about twice as slow as the build speed the same repo can achieve on Vercel, apparently due to how Vercel caches previously uploaded content, the CFP folks are aware of that continuing disparity and say they’re not done ramping up the build speed. Consider my eyes peeled. Speaking of which . . .
“Passtro” on Astro for now
I’ve given two recent mentions to the interesting Astro SSG project, which is still quite new and raw. Unfortunately, I realized that it’s so raw, and changing so rapidly, that I can’t keep up with it; so I’m going to take a pass on further work in Astro for the time being. It may also be that my admittedly limited skill set simply excludes me from Astro’s targeted user base and, if so, that’s absolutely fair. Be assured I have nothing but good feelings for this project and its wonderful community. I will remain a curious Astro-watcher and hope that, perhaps, I can rejoin its fold at some point.