feat: support webp format with jpg fallback #76
Conversation
src/lite-yt-embed.js
Outdated
| const img = new Image(); | ||
| img.onload = () => resolveAndSaveValue(true); | ||
| img.onerror = () => resolveAndSaveValue(false); | ||
| img.src = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA='; |
There was a problem hiding this comment.
There are better techniques on checking webp support like
document.createElement("canvas").toDataURL("image/webp").indexOf("data:image/webp") === 0
the example above will actually add new network request and will fail if not whitelisted in CSP img-src data:.
cc @paulirish
There was a problem hiding this comment.
Before adding the one from the PR, I tried that one you're mentioning.
Unfortunately, seems to be problematic with Safari and Firefox.
Anyway, I'm more than happy to change it if the solution based on canvas is more suitable according to @paulirish 👍
PS: You're mentioning "better techniques" in plural. Could you please share the other ones? I'm intrigued. :)
There was a problem hiding this comment.
You could simply use html5 approach
<picture>
<source srcset=poster.avif type=image/avif>
<source srcset=poster.webp type=image/webp>
<img src=poster.jpg>
</picture>
with it can cover more formats, also AVIF.
There was a problem hiding this comment.
document.createElement("canvas")
.toDataURL("image/webp")
.indexOf("data:image/webp") === 0
This is returning false on Safari while it supports webp. It seems that is not a good solution. :/
There was a problem hiding this comment.
You could simply use html5 approach
<picture> <source srcset=poster.avif type=image/avif> <source srcset=poster.webp type=image/webp> <img src=poster.jpg> </picture>
yeah i think this is my favored solution...
this, of course, means switching from a bg-image to using picture/source/srcset, but I suspect that may improve some other aspects. if anyone wants to give this a shot, i'd appreciate it.
|
@paulirish I've it already implemented and working with the HTML approach BUT... We still might need a way to detect if we have webp support in order to preload the image. As I see it, we have 3 options here: a) We remove completely the preload functionality as we're already improving moving to webp. 👍 Less code and it relies on HTML and no JavaScript and weird checks. b) We implement the "officialish" webp check support from webp docs: https://developers.google.com/speed/webp/faq#how_can_i_detect_browser_support_for_webp 👍 Preload c) We only preload 👍 Preload and supports 90% of the users with almost no code. I've implemented the third option as I think it could be the good one, without checking webp support but... Waiting your opinion @paulirish. PS: About the first check of webp support by @laukstein is only working for Chrome. |
|
Personally I'd prefer the option that wastes no bandwidth in any case. C, preloading regardless of support, is wasteful for those who don't have support. This may not be a big concern for most, but in places where data usage does cost it is a massive problem. Every byte matters. I'd default to option A for now, let the browser make the best choice. Then we can analyze responsible preloading solutions on it's own merit separately. |
|
Hey @paulirish. Just ping, waiting for your feedback. 🙇 |
In order to improve web performance we're using webp when available.
jpgfallback.CleanShot.2021-02-26.at.22.00.38.mp4
This is addressing some issues from: #70