Lazy Loading Images

A few months ago, @Johani released an excellent theme component to lazy load images. This means images are only loaded as they scroll into view, rather than being loaded as soon as they appear anywhere on the page, even if they aren’t visible to the user yet.

This is a great thing to have on forums where topics have many images in them, especially for users on connections with limited bandwidth.

If you know some of the more technical details of Discourse, you might ask, hey @eviltrout doesn’t Discourse already kind of do this? You do infinite scrolling and posts are streamed in and out of memory as the user scrolls. Yes, that’s right! But we generally do so in “chunks”, and on some image boards a single post could have dozens of large images. Why load them all at once when they aren’t visible yet?

In the latest builds of Discourse, we now lazy load large images, no extra components or plugins are necessary. If you scroll really fast you’ll see a blurry low-res version of a large image as a placeholder. It’ll look something like this:

image

technical details: we generate a very, very small 10x10 32-color image and store it as a data URI in the post, which the browser scales to the correct size – this ends up being around ~300 bytes

It’ll soon be replaced by the correct image:

We will continue to tweak the feature over the next little while, so please provide feedback and notes if you have them!

50개의 좋아요

Should improve page loading performance nicely, especially on slow connections. Thanks for this improvement!

8개의 좋아요

Awesome!

This is why I love Discourse - you keep adding stuff I didn’t think we needed! :+1:t3:

11개의 좋아요

One thing I’m looking into is applying this to non-lightboxed images, such as those included via oneboxing links.

One issue is it’s a little tricky to know when to apply the logic, since we don’t know the filesize of the destination image. Originally my plan was to append the filesize of images, but it turns out that is quite tricky since we don’t always have a downloaded copy of the image available.

I think I’ll have to come up with a magic width x height, maybe 300x300px or so, and if the image has dimensions larger than that it’ll be lazy loaded. We do have those dimensions available regardless of onebox or upload.

14개의 좋아요

How web bloat impacts users with slow connections I find this article to be a good one on the subject of slow connections, do bear in mind that it has a very minimalistic theme, so don’t judge it by it’s cover so to speak. It might not quite be applicable here, but it’s always good to keep in mind.

I sometimes wish there were ways with Web APIs to detect if someone is on a connection where they pay a lot for bandwidth or one that’s slow.

2개의 좋아요

Probably fine, but to cover animated GIFs which are still quite common I would relax that to something like 200×200.

3개의 좋아요

Yeah I am not sure what the downside will be of going all the way down to 50x50, as long as we do not hit emojis it should be good. Even at 50x50 we may still save 25x if you don’t end up looking at the image

5개의 좋아요

I vote for 150×150 then, as we definitely want to steer clear of anything remotely emoji-like in size..

4개의 좋아요

I mean, previously, image greater than 4MB isn’t loaded properly (using mobile to access)

-edit-

1개의 좋아요

That is completely unrelated. Max allowed image size is controlled in site settings. We already lightbox and thumbnail all images that are posted above a certain size. This is about topics with dozens or hundreds of images in them, not the size of any single image.

7개의 좋아요

I just want to say thank you for including this feature.

6개의 좋아요

Here’s some improvements:

https://github.com/discourse/discourse/commit/0e710dc573a02cdfb05f8c88d3024aacbbb81872

10개의 좋아요

Man, I thought I was going crazy. This feature is great for low bandwidth, but now i’m seeing this lazy loading all over the place when I am scrolling our forum. I have so much bandwidth and I’m on a computer. Maybe there should be some sort of buffer around areas you can’t see that load right before you scroll to them? Maybe only for mobile?

1개의 좋아요

https://twitter.com/addyosmani/status/1114777583302799360?s=17

9개의 좋아요

It’s not just about your bandwidth, it’s about unnecessarily loading the server/CDN.

As @falco linked above, the trend is towards more just-in-time asset delivery.

Is there anyway that the admin can still play with CSS to modify the lazy loading behavior? The somewhat unintended consequence is that some users are now saying that pictures load on demand more slowly compared to before. I was wondering if its possible to modify the CSS such that instead of either loading all pictures in the next e.g. 20 posts (prior behavior) or pictures only in the current post (current behavior), that we do something in the middle, e.g. load pictures in the next e.g. 3-5 posts.

1개의 좋아요

It’s done with Javascript right now. There is no way to adjust it currently, but we might consider it in the future based on feedback.

4개의 좋아요

요즘 점점 더 자주 lazy load 관련 문제를 겪고 있습니다. 하루에 최소 한 번은 이런 현상을 확인합니다. 재현이 어려운 문제이지만, 이런 일이 발생했을 때 디버깅할 수 있는 방법이 있는지 궁금합니다. 로그에서 관련되는 유일한 항목은 다음과 같습니다:

Uncaught [object Object]
Url: https://community.naturephotographers.network/assets/ember_jquery-57d09ec67e9e407d9b0d42aa1fefd1a470c45310d953b07793a3ca8adc6ec599.js
Line: 1
Column: 267440
Window Location: https://community.naturephotographers.network/t/twin-cuties/12785

1개의 좋아요

테마와 플러그인을 비활성화했을 때도 동일한 문제가 발생합니까? 안전 모드에서 시도해 보셨나요?

1개의 좋아요

재현이 매우 어렵습니다. 안전 모드로 진입한 후 약 30개 정도의 주제를 살펴본 끝에 마침내 작동하지 않는 주제를 하나 찾았습니다. 이번에는 로그에 관련 오류가 없습니다. 각 플러그인을 하나씩 테스트하는 동안의 다운타임을 피하고 싶어서, 원인을 파악할 수 있는 단서를 다른 곳에서 찾을 수 있기를 바라고 있습니다. Jeff, 감사합니다.

3개의 좋아요