Skip to content
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

Closed
MaybeThisIsRu opened this issue Jun 30, 2020 · 4 comments

Comments

@MaybeThisIsRu
Copy link

MaybeThisIsRu commented Jun 30, 2020

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?

@MaybeThisIsRu MaybeThisIsRu changed the title Write a new file instead of using base64 encoded string For low quality placeholders, an option to write a new file instead of inlining base64 encoded string Jun 30, 2020
@MaybeThisIsRu
Copy link
Author

MaybeThisIsRu commented Jul 1, 2020

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 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.

@liamfiddler
Copy link
Owner

👋 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.

@MaybeThisIsRu
Copy link
Author

MaybeThisIsRu commented Jul 2, 2020

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.

@liamfiddler
Copy link
Owner

No problem. I'll close this issue and the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants