-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
For low quality placeholders, an option to write a new file instead of inlining base64 encoded string #20
Comments
I have an open PR with an (almost) working solution: #21 There's one thing I still can't figure out. I want the browser to load all images specified in the Lazysizes says this is possible. But it doesn't appear to be the case, even if I set |
👋 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 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 |
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?
The text was updated successfully, but these errors were encountered: