For 2 very good reasons:
I have heard others say things like âChrome already implements it,â or that sort of thing. But I use Safari, and I couldnât care less if most people use Chrome. Second, the whole world using Chrome doesnât affect Google PageSpeed Insights one iota. I think itâs still worth enabling even now in December 2020.
Indeed. Tragically, Normâs poll has a great feature to cure that horrible problem in this poll, yet the vast majority of people are casting votes for payment processing, for reasons I simply cannot fathom. The good news is that people who have already mis-voted 
can easily change their vote before it becomes final.
If you mean the 2x or 3x super large file size version of graphics, yes, the high resolution screens on mobile devices trigger those. In fact, Google PageSpeed Insights nailed my own site in the past because it detected I had also created 3x images in the past, so today I only create 1x and 2x images. Many Blocs users only create a single 2x image and put that in the 1x slot, but I do not agree with that approach here in Japan where most people still use older Windoze PCs that have low rez screens that would be better served by the lighter weight 1x images. PLUS, you can better optimize your 1x images in terms of sharpness, whereas a 2x image display on a 1x screen wonât have the same perfect sharpness as a properly sharpened 1x image would. I think itâs still worth making both 1x and 2x images.
Oh, I didnât get that at first. One would have to click âShow voteâ to be able to vote for another topic⊠
Itâs great it works for you, but that is way to expensive for our business in Japan, hard hit be a sour Coronavirus economy. Visitors are happy enough to browse our existing websites and we are content with that. I see absolutely no need for us to spend that kind of money per month on marginally or even substantially faster CDN solutions. If anything HTTP/3 would be welcomed over HTTP/2, assuming we could get that feature for free. Right now our web host, Superior Host, only offers it via VPS (Virtual Private Server).
Thank you for telling people what they need to do! We have over a thousand people in this forum, so if more members vote and vote wisely, we can easily overtake the other features currently trending.
Naturally, I am hoping that Norm will spot our intense passion in the forum and perhaps slip âthe better featureâ into Blocs 4.2 or 4.3 white at the same time giving majority voters their preferred feature too. Fingers crossed!
Think about it. If you put content on your page in Blocs and disable visibility across ALL BREAKPOINTS, why in THE world would you want that content written to your HTML file when you export? It makes no, sense right? Right. Hence that feature is very important, in my opinion. PLEASE VOTE!
Safari now has lazy loading as an experimental feature, Iâve not tried it yet though.
The keyword being âexperimentalâ and not yet mainstream, hence the need to enable Lazyloading in Blocs. But like I said, even if Safari supports it, when you run your sites through Google PageSpeed Insights, you will get a score based on what they see, not what Safari or Chrome sees, despite the fact Chrome is Googleâs baby. And currently, my sites get better scores and feel faster too with Blocsâ Lazyload enabled. I think itâs worth it for now. What about 3 years hence? Who knows. 
I believe they have a free version; not looked into the limitations though. It costs us around ÂŁ100 per year, split over 5 websites. But like I said, itâs not a solution for everyone.
I spotted that, but itâs too limited on storage for really big sites, or even medium sites with not only a lot of 2x images but also other media like PDFs.
Gosh, I wasnât even thinking about the 1x / 2x aspect of images⊠
that makes it even worse⊠
What I meant was:
example:
a would have a huuuuge image for desktop only, say an image of a dog 
on mobile I would NOT want the dog image to be shown, but instead a tiny image of a cat 
The dog-image would be hidden to viewers on mobile.
question:
When someone on mobile views the site, will the big dog image also be LOADED, although the image as such is not even visible to the visitor?
**IF yes:
THAT would be my number one feature wish to stop that useless loading !!!**
Iâm not sure, this problem is technically the very same like the mentioned âPrevent layout elements being exportedâ which is right now a feature wish that can be voted for?
@Norm @Eldar to the rescue 
Can you shed some light on this please?
Do you see what I mean here?
@JDW do you know the answer and IF the answer is yes: please do explain that (as you can do it better than I can 
) to make that a feature wish.
I supply sirv with two orientations, 16:9 and 1:1 and implement them with an embed code from sirv into blocs. I then let sirv work out the sizes, 1x, 2x 3x etc. It save me time doing all that image editing.
From what I can see, sirv only loads what is required for that breakpoint.
Not a solution for everyone, but it works for me
If you want a big graphic to appear only on desktop PCs, you could just put that on the page and set VISIBILITY to LG and perhaps MD (tablets), and then you could have a smaller graphic for SM and XS breakpoints. But consider the case of a Desktop PC user who decides to narrow the width of their browser window across breakpoints. They would end up being served BOTH images â the LG/MD version and then the SM/XS version too!
Also bear in mind that if you have a really huge graphic, it will be a large file size even for a 1x image. For some photographic images, I suppose a 1x image on a 2x screen wouldnât be too blurry, but you would lose the Retina Display effect. Thatâs why I tend to chose 2x images too and just keep the physical size of my images reasonable.
Background images with text and other things overplayed are a different matter altogether. A much lower resolution and a higher compression would still look nice, I think.
Lastly, please understand that the new feature we are voting on would only not be written to the HTML file in the event you killed visibility on ALL BREAKPOINTS. That is something very different from making an image display only one 1 or more breakpoints.
So what happens if you have a big graphic set to be visible only on LG and your web visitors only use iPhones? Well, assuming you have a separate graphic set to display only on SM and XS, then they would see only that image. They would not see the image set to be visible only on LG.
I built the top page graphic on my KIRAMEK website to change via breakpoint. Test the following page on a desktop PC and slowly reduce the browser window width and you will see the graphic be changed out at each breakpoint.
I did it that way because the left side of my graphic on LG is sharp and in-focus while the right side is blurry on purpose so the little hand and pouch are brought into more clear view. To retain that clarity across all breakpoints required me to redesign my graphic for each breakpoint. That is something a CDN will NOT do for you.
I DO understand wich images would be seen or not seen by visitors depending on their device.
My question ist about the LOADING of the images in the background. So my question is about needless loading of data that is NOT visible.
please see above dog / cat image question
The way I understand it, and someone more savvy about browsers than me can chime in if they think I am wrong here, is that a browser (desktop PC or mobile) will only LOAD visible images. Any images referenced in the HTML yet set to NOT DISPLAY will of course NOT LOAD. But of course, if you view the page HTML code, you will see REFERENCES to those images stored on your web server.
Setting images to hidden will not give you a performance hit, if that is what you are worried about.
So why then should we vote for content to NOT be written to the HTML file at all when visibility is displayed across ALL breakpoints? Because it has zero meaning for one, and because it is CODE-BLOAT for two. You might have a very complex set of rows and columns and textual data that is set to NOT be visible on any breakpoint, but that code remains in your HTML page and requires time to download. And if you have a lot of objects on your page set to be invisible across all breakpoints, all that totally unused code sits in your HTML file taking up space for no good reason at all.
But again, that is a different matter than what you are talking about. You are talking about images that are displayed in some breakpoints and not others, and I think I just answered how the browser treats those. The code must be downloaded as a part of your HTML file, but the image itself will only load in the browser if itâs visibility is enabled for the current breakpoint displayed on your screen.
@Jerome
You never answered the questions I asked you in my earlier post, so I wanted to follow-up with you about that. Thanks!
Hi @JDW
Sorry for the delay,
for me, the main issue is about the loading time of your fontsâŠ
You responded to me they are already handled from your server, so i donât know how you can improve further actually.
About the âhoverâ mode disabled on mobiles, iâm not even sure if that can affect your performance.
As mentionned before, the use of a CDN might be a solution.
Perhaps, but our company cannot afford to pay more for web site hosting than we pay now. Corona has had a rather devastating impact on many businesses across Japan, and our company is no exception.
I was hoping to hear speculation on why fonts are taking so long to load off our own server, seeing that graphics load fast. That part doesnât make sense to me.
Anyway, thank you for the reply.
there are free offers for small business on netlify, cloudflare, jsdeliver etc.
iâm about to dig into that as well.
Your fonts issue may be related to their japanese characteristics. There are many topics on how to render that.
cheers
Lato & Open Sans are the two English-only fonts that Google PageSpeed Insights is complaining about being ârender-blocking resources.â