[gatsby-image] When loading is set to eager, don't lazy-load in SSR html

[timurc]

Summary

When using gatsby-image with JS enabled, the images are only loaded after all the JS is downloaded and parsed. That is fine in many (maybe most) cases. But sometimes, the Image in question is very substantial for the stuff above the fold – even more important that JS interactions. In this case, I want the image to be loaded instantly, when the browser is parsing the DOM. I expected that setting loading="eager" would do this – but it does not.

Motivation

I am currently updating an original gatsby 0.X page (https://timobecker.com) to the current version. Everything was fine and graphQL is awesome. But: I wondered why the perceived performance was a lot worse in the new version then in old version. Turns out, the most important thing on the gallery pages are the images. Using gatsby-image out of the box, even with loading="eager" activated, it takes 20 seconds to paint the image with "Fast 3G" throttle:

This is because it takes one more round-trip for the image to be rendered than in the original version. Also, the JS does carry some weight. Plus, with gatsby-image the blurred image is shown until the full download is finished, while the native browser way of showing the progressive rendering is giving a usable image a lot quicker. Not completely sharp, but a lot better than the blurred mush from gatsby-image. I fixed this by using a native <img />:

Now the performance is on par with the old version. Here is the component: https://github.com/voellig-ohne/timobecker/blob/upgrade-2019/components/article/index.js

Solution

I am not sure if gatsby-image should really behave this way or if that would be too magical. In the end I am fine with my solution of using native <img /> but it took me some time to get to this point. I think one of the three could fix it:

• As suggested above, if loading="eager" is set, render out the image directly in SSR.
• Have a separate gatsby-image-native that cuts out all the JS magic and truly lets the browser decide what to do. It would also have two added benefits:
  • It would be easier to style because it would not have all the added <div />s and just output an <img />.
  • Native progressive loading handled by the browser shows usable images a lot earlier.
• At the minimum, have a hint in the documentation that gatsby-image is not ideal if you want the image to appear as early as possible. It could advice to use the native <img /> and maybe there could be a new default GraphQL query fragment for this use-case.

I am really curious about your opinions on this!

[onestopjs]

I think by using gatsby-image you kind of opt-in to this behavior. In my opinion it is one of its "selling points". Using simple HTML <img /> seems the best option to me and I don't think a separate package is needed for this.

I agree that this is really worth noting in the docs, though.

[timurc]

Thanks for you reply!

Skimming the docs again, maybe this is why I thought it would not lazy-load: It says setting loading="eager"would opt-out of lazy-loading behavior – which is wrong on first load. This is why I felt like I would not opt-in to this behavior.

What would be the next step? To do a PR on the documentation?

[onestopjs]

Yeah! If you need any help, let me know :)

[polarathene]

The blurred preloader image is meant to be small enough to be embedded into the html payload. It has the benefit of giving a fast render and approximation before the proper image is loaded in. If the image supports progressive loading, then choosing to use the preloading placeholder will perhaps be in the way.

I haven't been using Gatsby lately, but I remember you can disable this placeholder, or choose a different type. If the image is still not visible, then perhaps what you'd really like is another option for when opt-ing out of a placeholder to just set visibility on the main image component?

---

Regarding the JS part. This is due to being a React component and lazy loading that defers mounting the image component to load the real image until it's visible. If you want to begin loading before any JS runs(by rendering the markup during SSR), I believe you need to use the critical prop.

It's true that there is a warning about it being deprecated and discouraging it's use for loading=eager instead, however the author that implemented such did not account for all code in gatsby-image that uses critical prop. I pointed this out back in May:

critical is now advised against being used to have usage replaced with loading attribute instead via this message and docs. However critical is still relevant in the Image constructor and componentDidMount(), this advice may cause issues to be opened due to confusion as the prop is not 1:1 replacement atm.

Looking over the commit history, it seems it was finally fixed 15 days ago in this PR 😃

So perhaps this issue is now solved?

BTW, I don't think you'd find the placeholder graphics to be taking additional round trips? They should be base64 embedded into the HTML(that does add some extra weight). There is also some possibly undocumented features for adjusting the dimensions of the placeholder(if you wanted to get more details for larger placeholders) as well as setting a different format. I personally prefer adding a CSS blur effect which afaik does not have any notable impact like it did years ago, but smooths out the pixels much more nicely.

I have a example gallery page that is around 20 images using gatsby-image, but it only pulls down around 500kb of data(less without scrolling). See it here, it takes about 2 seconds on fast3G, I noticed your screenshots are transferring 3.4MB! That's all images above the fold?

[polarathene]

You can see an example of using CSS blur with the placeholder and without here, where I did my best to justify the blur filter as suitable for todays websites. I have a final response to that from some time ago that I haven't posted. There was an optimization that could be applied to further reduce the small paint overhead for applying blur. I just haven't got around to prepare additional info to convey that and make a case for it once more.

[timurc]

hey @polarathene thanks for your thoughts! I will look into #17148 , it might indeed be related.

About my particular example: the added round-trip that I am talking about is the JS itself when the page loads with an empty cache. For that it does not matter if there is a blurred preview or not.

With the gatsby-image component:

Round 1: request html
Round 2: request js
Round 3: request image

Width 'native' <img />-element:

Round 1: request html
Round 2: request image

My idea was that it would be cool if gatsby-image would behave like the native scenario if loading="eager" is set. That would save a round-trip for critical images and thus enable faster visibly finished render. It could even be combined with the preview image, if the real image is rendered in front of the blurred one.

But I am also ok with the suggestion of @PsychedMagnet that one kinda buys in into these negative aspects when you use gatsby-image and that a hint in the doc to just use <img /> in some cases would be fine. Did not get to it yet though.

---

About the blur: it works really well in your example, but in my case the full width blurred preview, even blurred further looked terrible. It's also one more transition that makes it feel slower at normal connection speeds (at least to me):

blank page - blurred - done

vs

blank page - done

---

You're also right that the initial payload is rather high. That's because the responsive images on full with on a retina screen are 3000px wide. For the images at the bottom (the gallery) I use gatsby-image, because there the lazy-loading makes more sense. The top two ones load instantly for some reason (although set to be lazy) even without scrolling. Each of the images is around 1mb and that's why it is more than 3mb initial load. Because they load in parallel, it takes longer for the top image (most important) to be done. Would be nice if that could somehow be done in a more clever way. Who knows, maybe the native loading attribute from the browser will do that 🤷‍♂️. You can check it out yourself: https://timobecker.com/illustration/kosmoundklax/

[polarathene]

gatsby-image uses the picture element instead of just a single img element, when used with the relevant GraphQL fragment, you get your image resized and optimized for various sizes that the picture element will link to. If you really need to support a case for 3k px wide image, that should be doable still, I think you may need to be explicit about also using that when appropriate(unless it's for HiDPI displays, then it might get used there).

The top 2 images might be loading because of the IntersectionObserver rootMargin thing. Not sure, my example site I noticed loads the 1st image top left pretty much straight away.

How much of a win is it really in your case from the js delay in the way compared to the actual images? Unless you've got some heavy JS chain dependency going on, it should be fairly light like my example site? Not likely to make a huge difference is it?

I don't think there is much we can do for adjusting load priority atm. AFAIK that's handled by the browser with HTTP/2, the browser can make the requests for the assets and attach a priority hint, and the HTTP/2 server that returns the assets in a single stream(unlike HTTP/1.x), then decides how it will prioritize and send data back.

---

My blur uses CSS blur filter to look nice. gatsby-image just stretches a tiny 20 px wide thumbnail to the intended width/height, you get some blurry pixelated mess as a result. Mine also iirc had their resolution increased to 42px wide(like facebook does) via a feature I contributed, but I don't think it got documented.. For a larger image you could up that further as the size would still be tiny / quick in comparison(needs to be under 10kb to get inlined as base64 though.

If progressive image loading is better suited for your audience, go for it :)

As for the layered order, it should be a solid colour at the bottom, then the placeholder image, then SVG placeholder, and at the top above all is the real image that is loading but it's visibility is hidden until it's finished loading. critical changed that to always be visible afaik, and that recent PR should have fixed it so loading='eager' has the same effect. That should also now render it into the HTML during SSR, rather than wait until JS mounts it later.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!