IDs in Base64 Image Placeholders #139
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 3 commits
December 9, 2021 15:55
Lighthouse sometimes dislikes ElderJS's base64 placeholder pictures. Usually, it lets you know that the placeholder needs to be resized. Unfortunately, Lighthouse doesn't help you identify the image well. Which means on pages with lots of pictures, this is a pain. Having an ID embedded in the data URL fixes this. It does make pages slightly larger, but I feel the tradeoff is worth it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey,
So this is a pull request I'm not sure if you'll want to merge or not. I'm pretty sure it doesn't break anything, but it adds behavior which some people may not need, but a few may find very useful.
One thing that is very important to modern SEO is getting good Lighthouse scores. This pull request deals with a specific Lighthouse notification you sometimes get - 'Displays images with incorrect aspect ratio' under 'User Experience' under 'Best Practices'.
The main issue is, when you generate placeholder images, sometimes Lighthouse doesn't like the placeholder size. So it'll pop up with this message. However, on sites with tons of pictures on a page (think > 5), Lighthouse is not great at letting you know which picture has the issue. So you have to guess.
This pull request adds a short 21 character ID to the base64 placeholder URL in a way that it doesn't interfere with the image. Sometimes it'll get truncated in the report, but it makes finding out which image had the issue very very easy (literally search the DOM in Chrome or take a look at your ejs-image-manifest.json).
Here's a picture example of one of the placeholders with the ID added, so you can see how it works. As you notice, which image it is is not clear, however, the id makes it easy to search for:
If you prefer a shorter ID, nanoid (the library used here) supports that very easily, and even has a tool for determining how often collisions are (we could definitely get a way with a shorter id in this case, however, I figured I'd just stick with the default).
Let me know what you think. If you want me to put a flag in the config for this, that'd be cool too, however, I'll want to put a cache-busting mechanism in first so that way it removes the id when people turn it off and adds it back when people turn it on. I'm working on something to help this plugin handle cache-busting and multi-level image directories a little better currently, so I'd probably tackle it after that.
Let me know what you think and I hope your having an awesome day.
P.S. I also have a tool that helps me take an image with this error, and give me resize dimensions that Google will like. I'm not sure if that would be helpful in the SEO plugin, or something else... but if you'd like me to provide it, I can. I'm not quite sure how it would integrate in though, as it is a bit intensive (opening up each image file is time intensive on large sites... but maybe caching will fix things here).