-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
fix: better support for lazy img elements #11545
Conversation
🦋 Changeset detectedLatest commit: ed27773 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
I think we probably need to worry about dynamic |
Good points, updated PR. |
Is there anything else we ought to be worrying about? |
|
Hi again. Thanks for taking the time to look into this. Unfortunately, this solution doesn't seem to work if the <div style="height: 3000px; background: black;"></div>
<!-- Also doesn't work in {#each} blocks. -->
{#if true}
<img height="200" width="200" loading="lazy" src="https://picsum.photos/seed/{Math.random()}/200">
{/if} For some context, in my own SvelteKit project I have a page that has a grid of lazy images in an Experimenting some more, it seems that lazy loading breaks when there's a sibling element next to the conditional block, such as the div in my repro, or the conditional block is wrapped in another element. |
@yamplum Please could you create a new issue for this as it seems different from the original. Thank you :) |
Fixes #11497.
This was a tricky one. We already have a heuristic to use
importNode
in the codebase, so retrofitting it to supportloading="lazy"
was relatively trivial.However that didn't fix the problem. In fact, lazy images weren't working in Chrome for me either (I added a
onload
event to the images to test this behaviour).The reason was because our
comment
template was being cloned, even though it's just a comment node. I presume this is because we're inserting the elements that were fromimportNode
into an element fromcloneNode
. Either way, this PR seems to remedy the problem.Unfortunately, none of this is testable with JSDOM and I battled with Playwright, but to no avail.