5 ms·

* The web vitals themselves are unquestionably good for the user* Fast pages are good, but Google is using their tools like Page Speed to push you to adopt Go

* The web vitals themselves are unquestionably good for the user* Fast pages are good, but Google is using their tools like Page Speed to push you to adopt Google’s ideas of fast, like using WebP for images. So now you might have a bunch of cruft in your page to support multiple image types. Also, as user, I hate lazy loading. I can scroll faster than images load. I’d rather everything load in the beginning, and have images there as I scroll.

onli 5y ago
You can not scroll faster than images load. You can maybe jump via the scrollbar faster to a page position than images load, but that's it. That's at least with the HTML5 async image standard in Firefox. It's up to the browser after all, so if yours loads images too slow the issue might be there. And sure, if the images are huge they will take a long time to load, but that's also covered by the core web vitals. A site I built a while ago is a good test case for that imho, https://www.sustaphones.com/ https://www.sustaphones.com/. Long list, many small images, loaded from a CDN. I can maybe provoke a flicker with the scrollbar, but not with regular scrolling. Edit: That's for broadband. With a 56K modem or something that's of course a different story. But loading a bunch of images in advance on the modern web is also not a good option then.
- kuschku 5y ago
  On slower networks, it's common to load a page, do something else until the page is 100% done, and then expect to be able to view the whole page without any further loading.
  - onli 5y ago
    I'm aware :) My HP Veer had a funny "feature" where after some inactivity it would reload the page when you then scrolled it. It depends though on the content page and on how slow the network is exactly, doesn't it? I often enough preferred to have the text already and decide based on that whether to wait for the images. Async with non-jumping base content (which the core web vitals also cover) is great for that. And with it being a browser feature, even if Google pushes for it the user can always deactivate it. On real browsers at least.
    - WillPostForFood 5y ago
      I'm not talking about browser features, I'm talking about the lazy loading JavaScript libraries that many (most, I'd wager) use.
      - onli 5y ago
        That goes against that specific implementation then, not against the concept, and not against how the feature should be implemented now. I was critical at first as well. But I tested it on the site I linked and on other sites with bigger images, and it just worked that well that I stand to what I said. This feature is a net-positive and in most scenarios the loading will either not be noticeable, or it will be an advantage overall.
      - moritzwarhier 5y ago
        JS lazy loading is a thing of the past. Just because some sites are slow to adopt, that doesn't make it a valid argument against lazy loading per se. Native lazy loading is broadly supported, it works well, has no overhead, and you can override the behaviour if you always want eager loading. There's no point in complaining about it that I am able to grasp. I don't have data on this but I assume that JS lazy loading is dying rapidly because this is not a critical feature that must polyfilled for legacy browsers. Of course, plenty of sites will keep their JS lazy loading cruft until the next code refactoring / optimization. But I am very happy that native lazy loading has been standardized and implemented.
- mdoms 5y ago
  What absolute nonsense. It doesn't matter which "async image standard" you use, you're fundamentally limited by my internet connection. I agree completely with GP, I would rather open a page in the background, give it some time to load all of the images and then browse it. Lazy loading is a pain. Your test case is totally meaningless, the images are under 3kb. Full (non-lazy) image loading is far more important on websites with lots of large images.
  - onli 5y ago
    If you implement lazy image loading yourself in JS you will see that the implementation actually makes a big difference in how noticeable it is. The browser does a good job with it. Of course your internet connection can limit you, but it just won't do so on regular broadband connections for sound image sizes. You can always construct a theoretical case where it does not work great. But on those pages and connections loading all the images in advance will usually also lead to a bad experience.
- WillPostForFood 5y ago
  You can not scroll faster than images load. The typical WordPress lazy loading script doesn't start loading the image until it is scrolling into view. Try a typical food blog, scroll moderately slowly and you'll still get to see every single image load. edit: your example works great, but is in outlier in the implementation, and benefits from tiny images that load quickly.
  - onli 5y ago
    Since I'm just in this thread again anyway: If that was your experience with lazy loading images I can relate, and understand where the negative impression is coming from. That wordpress script is probably loading the image only when the DOM object becomes visible, which will always cause the loading process to be noticeable. Shortly on good connections with small images, so it won't matter much there, but that experience gets worse for slower connections and bigger images of course. My background that made me write the comment above is that I implemented lazy loading for a feedreader in JS, with predictive early loading to exactly avoid this problem, and I did test the browser feature just recently again. In those scenarios lazy loading really does work well enough for my statement to be true, according to my testing. For common connection speeds and image sizes only of course. Though I'd argue it also helps in less optimal scenarios exactly because it somewhat decouples the image loading from the page load - that that overall experience was horrible on long threads with many images in the feedreader was why the lazy loading feature was added, the contrast was stark. I should have defined that better in the comment above and given your experience more validity. Next time :)
    - WillPostForFood 5y ago
      I know this reply is days late, but I hope you see it. :) This is an example of what I am talking about. https://clayimports.com/collections/colors https://clayimports.com/collections/colors It "passes" the google lazy load audit, but is a terrible user experience. Doing no image load optimization would be much better than what they are doing presumably to please google.
      - 5y ago
- bcrl 5y ago
  On Friday I completed the install of a new fibre connection for a customer. They had been stuck on a flaky 1.8Mbps ADSL service for years, and the incumbent wanted $30,000 to go 5 poles down the road to their hours. Yes, in 2021 there are still people who can scroll faster than images load.
  - onli 5y ago
    Granted. Like I specified, I talked about broadband there. He preferred to wait all the time until images are loaded to start reading articles, with a flaky slow connection, or to try start reading while parts of the site still load? Especially on a slow connection not having to load the images immediately, or at all if the visitor does not scroll down as much, can make browsing so much better.
    - bcrl 5y ago
      Your definition of broadband is wrong. Even 1.8 Mbps counts as broadband. Please be more precise in the terms that you use. The main problem the customer I was referring to had is that the user interfaces for these websites would not function until they finished loading after 30 to 90 seconds, despite the fact that the user interfaces rarely changed. These were for cloud based accounting and scheduling platforms the business was required to use. Developers really should have to try to use the systems they build on systems that have low bandwidth / high latency network connections rather than the typical fibre fed office environment. If you can build a website that works well for that use case, it's probably going to be incredibly snappy on a fast connection. Judging by how bloated the web is these days, that is rarely the case in today's world.
      - onli 5y ago
        What usually happens there is that the sites do not work because the JS wasn't downloaded and interpreted yet. That happens more often when all the images are always downloaded when loading the page. Lazy loading of images is one method to address exactly this problem :) My definition of broadband is correct, and 1.8Mbps does not match it. Where I live 1.8Mbps just is not legal broadband. In the US that also does not count as broadband anymore, see https://broadbandnow.com/report/fcc-broadband-definition/ https://broadbandnow.com/report/fcc-broadband-definition/, and it hasn't for over a decade.
walshemj 5y ago
The cruft in webpages is not from having support for multiple image types. its look at any site in chrome dev tools.
djtriptych 5y ago
WebP is good iff it improves rendering times (which it does). That's not google's fault really. Any way you can come up with to optimize images is valid under Core Web Vitals. I really don't think any of it is skewed towards Google's solutions except the testing/measurement methodology. I would love open source data collection across browsers for instance. Lazy-loading can be implemented sloppily, but browser-native lazy loading is now good enough to be considered optimal.
- WillPostForFood 5y ago
  browser-native lazy loading is now good enough to be considered optimal The problem is that Google Page Speed dings you for not having lazy loading, and people add crappy JavaScript lazy loading that satisfies Google, but makes the user experience worse. WebP is good iff it improves rendering times (which it does). That's not google's fault really. The problem has been, until recently, Safari didn't support WebP, so you had to implement a fallback to jpg. More complicated HTML, more images to compress and manage, all for a very marginal improvement.
  - hexa22 5y ago
    Most sites would use the user agent for this but I’m pretty sure HTML now has a picture tag which can have multiple sources so the browser can pick the source it wants.
- snowwrestler 5y ago
  How does WebP improve rendering times?
  - hexa22 5y ago
    It takes less space so it downloads faster.
moritzwarhier 5y ago
So disable native lazy loading in your about:config then? On sites that employ legacy JS-based techniques, disabling JS might help (sounds like you are talking about article-like content). I assume that those sites will vanish quickly though. "Lazy loading" interactive content is an entirely different thing. Shopping pages with tons of product images, Infinite scroll (yuck) are different...

onli 5y ago

You can not scroll faster than images load. You can maybe jump via the scrollbar faster to a page position than images load, but that's it. That's at least with the HTML5 async image standard in Firefox. It's up to the browser after all, so if yours loads images too slow the issue might be there. And sure, if the images are huge they will take a long time to load, but that's also covered by the core web vitals. A site I built a while ago is a good test case for that imho, https://www.sustaphones.com/ https://www.sustaphones.com/. Long list, many small images, loaded from a CDN. I can maybe provoke a flicker with the scrollbar, but not with regular scrolling. Edit: That's for broadband. With a 56K modem or something that's of course a different story. But loading a bunch of images in advance on the modern web is also not a good option then.

kuschku 5y ago
On slower networks, it's common to load a page, do something else until the page is 100% done, and then expect to be able to view the whole page without any further loading.
- onli 5y ago
  I'm aware :) My HP Veer had a funny "feature" where after some inactivity it would reload the page when you then scrolled it. It depends though on the content page and on how slow the network is exactly, doesn't it? I often enough preferred to have the text already and decide based on that whether to wait for the images. Async with non-jumping base content (which the core web vitals also cover) is great for that. And with it being a browser feature, even if Google pushes for it the user can always deactivate it. On real browsers at least.
  - WillPostForFood 5y ago
    I'm not talking about browser features, I'm talking about the lazy loading JavaScript libraries that many (most, I'd wager) use.
    - onli 5y ago
      That goes against that specific implementation then, not against the concept, and not against how the feature should be implemented now. I was critical at first as well. But I tested it on the site I linked and on other sites with bigger images, and it just worked that well that I stand to what I said. This feature is a net-positive and in most scenarios the loading will either not be noticeable, or it will be an advantage overall.
    - moritzwarhier 5y ago
      JS lazy loading is a thing of the past. Just because some sites are slow to adopt, that doesn't make it a valid argument against lazy loading per se. Native lazy loading is broadly supported, it works well, has no overhead, and you can override the behaviour if you always want eager loading. There's no point in complaining about it that I am able to grasp. I don't have data on this but I assume that JS lazy loading is dying rapidly because this is not a critical feature that must polyfilled for legacy browsers. Of course, plenty of sites will keep their JS lazy loading cruft until the next code refactoring / optimization. But I am very happy that native lazy loading has been standardized and implemented.
mdoms 5y ago
What absolute nonsense. It doesn't matter which "async image standard" you use, you're fundamentally limited by my internet connection. I agree completely with GP, I would rather open a page in the background, give it some time to load all of the images and then browse it. Lazy loading is a pain. Your test case is totally meaningless, the images are under 3kb. Full (non-lazy) image loading is far more important on websites with lots of large images.
- onli 5y ago
  If you implement lazy image loading yourself in JS you will see that the implementation actually makes a big difference in how noticeable it is. The browser does a good job with it. Of course your internet connection can limit you, but it just won't do so on regular broadband connections for sound image sizes. You can always construct a theoretical case where it does not work great. But on those pages and connections loading all the images in advance will usually also lead to a bad experience.
WillPostForFood 5y ago
You can not scroll faster than images load. The typical WordPress lazy loading script doesn't start loading the image until it is scrolling into view. Try a typical food blog, scroll moderately slowly and you'll still get to see every single image load. edit: your example works great, but is in outlier in the implementation, and benefits from tiny images that load quickly.
- onli 5y ago
  Since I'm just in this thread again anyway: If that was your experience with lazy loading images I can relate, and understand where the negative impression is coming from. That wordpress script is probably loading the image only when the DOM object becomes visible, which will always cause the loading process to be noticeable. Shortly on good connections with small images, so it won't matter much there, but that experience gets worse for slower connections and bigger images of course. My background that made me write the comment above is that I implemented lazy loading for a feedreader in JS, with predictive early loading to exactly avoid this problem, and I did test the browser feature just recently again. In those scenarios lazy loading really does work well enough for my statement to be true, according to my testing. For common connection speeds and image sizes only of course. Though I'd argue it also helps in less optimal scenarios exactly because it somewhat decouples the image loading from the page load - that that overall experience was horrible on long threads with many images in the feedreader was why the lazy loading feature was added, the contrast was stark. I should have defined that better in the comment above and given your experience more validity. Next time :)
  - WillPostForFood 5y ago
    I know this reply is days late, but I hope you see it. :) This is an example of what I am talking about. https://clayimports.com/collections/colors https://clayimports.com/collections/colors It "passes" the google lazy load audit, but is a terrible user experience. Doing no image load optimization would be much better than what they are doing presumably to please google.
    - 5y ago
bcrl 5y ago
On Friday I completed the install of a new fibre connection for a customer. They had been stuck on a flaky 1.8Mbps ADSL service for years, and the incumbent wanted $30,000 to go 5 poles down the road to their hours. Yes, in 2021 there are still people who can scroll faster than images load.
- onli 5y ago
  Granted. Like I specified, I talked about broadband there. He preferred to wait all the time until images are loaded to start reading articles, with a flaky slow connection, or to try start reading while parts of the site still load? Especially on a slow connection not having to load the images immediately, or at all if the visitor does not scroll down as much, can make browsing so much better.
  - bcrl 5y ago
    Your definition of broadband is wrong. Even 1.8 Mbps counts as broadband. Please be more precise in the terms that you use. The main problem the customer I was referring to had is that the user interfaces for these websites would not function until they finished loading after 30 to 90 seconds, despite the fact that the user interfaces rarely changed. These were for cloud based accounting and scheduling platforms the business was required to use. Developers really should have to try to use the systems they build on systems that have low bandwidth / high latency network connections rather than the typical fibre fed office environment. If you can build a website that works well for that use case, it's probably going to be incredibly snappy on a fast connection. Judging by how bloated the web is these days, that is rarely the case in today's world.
    - onli 5y ago
      What usually happens there is that the sites do not work because the JS wasn't downloaded and interpreted yet. That happens more often when all the images are always downloaded when loading the page. Lazy loading of images is one method to address exactly this problem :) My definition of broadband is correct, and 1.8Mbps does not match it. Where I live 1.8Mbps just is not legal broadband. In the US that also does not count as broadband anymore, see https://broadbandnow.com/report/fcc-broadband-definition/ https://broadbandnow.com/report/fcc-broadband-definition/, and it hasn't for over a decade.

walshemj 5y ago

The cruft in webpages is not from having support for multiple image types. its look at any site in chrome dev tools.

djtriptych 5y ago

WebP is good iff it improves rendering times (which it does). That's not google's fault really. Any way you can come up with to optimize images is valid under Core Web Vitals. I really don't think any of it is skewed towards Google's solutions except the testing/measurement methodology. I would love open source data collection across browsers for instance. Lazy-loading can be implemented sloppily, but browser-native lazy loading is now good enough to be considered optimal.

WillPostForFood 5y ago
browser-native lazy loading is now good enough to be considered optimal The problem is that Google Page Speed dings you for not having lazy loading, and people add crappy JavaScript lazy loading that satisfies Google, but makes the user experience worse. WebP is good iff it improves rendering times (which it does). That's not google's fault really. The problem has been, until recently, Safari didn't support WebP, so you had to implement a fallback to jpg. More complicated HTML, more images to compress and manage, all for a very marginal improvement.
- hexa22 5y ago
  Most sites would use the user agent for this but I’m pretty sure HTML now has a picture tag which can have multiple sources so the browser can pick the source it wants.
snowwrestler 5y ago
How does WebP improve rendering times?
- hexa22 5y ago
  It takes less space so it downloads faster.

moritzwarhier 5y ago

So disable native lazy loading in your about:config then? On sites that employ legacy JS-based techniques, disabling JS might help (sounds like you are talking about article-like content). I assume that those sites will vanish quickly though. "Lazy loading" interactive content is an entirely different thing. Shopping pages with tons of product images, Infinite scroll (yuck) are different...