Carregamento Preguiçoso de Imagens

Há alguns meses, @Johani lançou um excelente componente de tema para carregar imagens de forma preguiçosa (lazy load). Isso significa que as imagens só são carregadas conforme aparecem na tela, em vez de serem carregadas assim que aparecem em qualquer lugar da página, mesmo que ainda não sejam visíveis para o usuário.

Isso é ótimo para fóruns onde os tópicos contêm muitas imagens, especialmente para usuários com conexões de banda limitada.

Se você conhece alguns dos detalhes mais técnicos do Discourse, pode estar se perguntando: “Ei, @eviltrout, o Discourse não faz isso de certa forma já?” Sim, você faz rolagem infinita e os posts são carregados e removidos da memória conforme o usuário rola a página. Isso está correto! Mas geralmente fazemos isso em “blocos”, e em alguns quadros de imagens um único post pode conter dezenas de imagens grandes. Por que carregá-las todas de uma vez quando ainda não estão visíveis?

Nas versões mais recentes do Discourse, agora carregamos imagens grandes de forma preguiçosa, sem necessidade de componentes ou plugins adicionais. Se você rolar muito rápido, verá uma versão borrada de baixa resolução da imagem grande como um placeholder. Será algo assim:

image

detalhes técnicos: geramos uma imagem muito, muito pequena de 10x10 pixels com 32 cores e a armazenamos como um URI de dados no post, que o navegador escala para o tamanho correto — isso resulta em aproximadamente ~300 bytes

Em breve, ela será substituída pela imagem correta:

Continuaremos ajustando o recurso nas próximas semanas, então, por favor, compartilhem seus comentários e observações se tiverem!

50 curtidas

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

8 curtidas

Awesome!

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

11 curtidas

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 curtidas

Web bloat 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 curtidas

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

3 curtidas

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 curtidas

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

4 curtidas

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

-edit-

1 curtida

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 curtidas

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

6 curtidas

Here’s some improvements:

10 curtidas

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 curtida
9 curtidas

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 curtida

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 curtidas

I’ve been having issues with lazy load more and more lately, I see this at least once a day. It is hard repro, but I’m curious if there is anything I can do to troubleshoot this when it happens? The only thing related in the logs is this:

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 curtida

Do you have the same problem with themes and plugins disabled, have you tried in safe mode?

1 curtida

It is very hard to reproduce, I went into safe mode and had to browse through 30 or so topics before finally hitting one that didn’t work. No related errors in the logs this time. I’m trying to avoid the downtime of testing each plugin, that’s why I’m hoping there may be some hints elsewhere to determine what the culprit may be. Thanks Jeff.

3 curtidas