Another aspect of image optimization that I'm aware of, but haven't even bothered with yet, is handling the art direction problem of responsive images.
Like "pan and scan" conversions of widescreen movies to the old 4:3 TV size, if you're serving a narrower image to mobile devices than say a desktop browser, the ideal image to serve is probably not a generic resize, or center-cropped version of the image. Mozilla has a nice page on responsive images that explains it better than I could: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Res...
I've clicked into my non-indexed pages, and everywhere that people say it should say the reason why the page is not indexed, there simply isn't a reason mentioned. It just says the generic crawled but not indexed even when clicked into specific pages.
I've even watched YouTube videos of people going into their Search Console dashboard to make sure I'm not missing anything (and indeed I've seen where those people for some pages do see a reason, but for mine I do not).
Simply because when I google'd my use case I didn't discover that plugin!
Maybe it would make sense to decouple the image processing code from my library so the `jekyll_picture_tag` could be used, since it's a bit orthogonal to the Propshaft-esque asset loading.
It's important to note that this tool does not use the same container images or runtime environment that GitHub Actions actually runs. It's an approximation.
For simple use cases that won't matter, but if you have complex GitHub Actions you're bound to find varying behavior. That can lead to frustration when you're debugging bizarre CI failures.
Yeah, this is lame. With Gitlab you can choose the exact image that runs and provide your own. So you can easily run the exact same code in the exact same environment locally.
I guess it would be nice to have a tool to convert a Gitlab YAML to Docker incantations, but I've never needed to do it that often for it to be a problem.
In case anyone else is similarly curious, I managed to get the ubuntu images to build .qcow2 images with some lightweight patches to the packer files and the interior .sh provisioning scripts. I have intention of setting up (heh) GHA to build them on the regular but it has not yet risen to be the highest priority weekend project
If you may say "but, why?!" it's because I really wanted to know what versions of everything I could expect in GHA, and I detest "git commit -amdummy && git push" stupidity so I guess the answer is "because I'm wired that way"
I'll definitely give this a try - only wish I knew about it before I wrote my thing!
reply