Closed MaybeThisIsRu closed 4 years ago
I have an open PR with an (almost) working solution: https://github.com/liamfiddler/eleventy-plugin-lazyimages/pull/21
There's one thing I still can't figure out. I want the browser to load all images specified in the src
attributes, but lazyload higher res versions specified in data-src
or data-srcset
. This doesn't appear to work either with lazysizes, or with native lazy loading.
Lazysizes says this is possible. But it doesn't appear to be the case, even if I set preferNativeLazyLoad
to false
and ensure only LazySizes is used.
👋 Hi @hirusi !
That isn't a use case I considered but it sounds useful. I'll look at the PR over the next few days. Thanks!
I'm not sure about the second problem - it's not something I've tested before.
Setting preferNativeLazyLoad
is the correct approach to ensure Lazysizes is always used.
If that didn't work I'd recommend you look at the markup in your built site (particularly the parts generated by this plugin) and confirm it matches the markup expected by lazysizes.
Hi @liamfiddler :)
Unfortunately, even though the syntax matches with what LazySizes have specified in their documentation, it just doesn't appear to be working the way they claim it should. That said, since this is the case, I am altogether dropping the LQIP pattern from my site, and sticking to just native lazy loading with no polyfilling. The extra JavaScript is not worth it in my scenario anymore.
Since this deviates heavily from the goal of this plugin, I believe it makes sense for me to just create a simple plugin instead. Doing only one thing - adding a loading="lazy"
attribute to all img tags, unless one exists already, and adding width and height attributes. It will be a heavily stripped down version of your plugin.
No problem. I'll close this issue and the PR.
I'm currently in the process of implementing a strong CSP on my static site.
One of the last things left for me is to set a strong
image-src
policy, which at the moment is not possible as this plugin generates a base64 output for the low quality placeholders.I understand that there is nothing faster than an inline string already present in DOM before a request is sent out for the actual image, but I would also prefer an option to write a low quality version as an image file - I would imagine this would still be in bytes/a few kilobytes for most pictures.
Yes, there is still a huge overhead for the request-response cycle. However, HTTP/2 does seem to mitigate that to some extent.
I would like to enforce a strong CSP, even at the expense of perfect user experience.
The underlying library Jimp supports writing files.
Is there any interest in providing such an option?