Google ; New Breadcrumbs issue detected for site xxxxx 24 Jun 2021•Breadcrumbs

So I look into it, knowing I'd fixed that ages ago....

Google ; Last crawled : 13 Nov 2019

Triggering stuff because you eventually got round to looking at it 19 months later? and it's all like that full of massive holes that make zero sense.

Google; "This product doesn't show how many reviews it has"... Me; "It has no reviews" Google; "ERROR! ERROR! ERROR! ERROR! zero is not a valid number!!!!" Me; "Fuck you Google" Google; "This product doesn't show how many reviews it has"...

I'm not even going to get into how shitty pagespeed insights is* - it's not even close to lighthouse. It tells you to increase your caching but doesn't use caching in performance measurements. I presume google has a giant ass that it pulls most of the figures out of on each run. I live in an area of the UK with one of the worst mobile phone signals known to man, pages load in < 2 seconds google consistently claims at least double.

I really don't enjoy spending hours of my days having to check that Google haven't moved the goalposts yet again.

* I lied, I am.

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.

Lazy-loading can be implemented sloppily, but 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.

its look at any site in chrome dev tools.

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...

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/. 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.

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.

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.

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.

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.

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.

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.

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.

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/, and it hasn't for over a decade.

I must say that the FCC really messed up by redefining broadband when they were the ones that had originally defined it in terms of RF spectrum usage. Here in Canada, the telecom regulatory body set the Basic Service Objective to be 50 Mbps download and 10 Mbps upload. They didn't try to redefine what broadband is and overload a term that already had meaning in the telecommunications space.

Personally I think latency is more important with modern internet connections. 10 Mbps is still quite usable for a lot of things, but not if it's 500ms RTT via a satellite. Sadly most telecom regulators ignore latency.

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.

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 :)

This is an example of what I am talking about.

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.

Which of course you can only see weeks in retrospect.

Or to take it further, it's still nearly impossible to use google's tools and determine that a particular DIV or Ad is causing damaging shift _in aggregate_.

Worse, it's impossible (and probably will always be) to tell the dollar value of getting all the web vitals to "green". They are pretty agressive targets for most publishers I think, but it's unclear exactly how much these fixes are worth (in additional traffic, seo performance, carousel inclusion, etc).

This is a bit "the nature of the beast" when dealing with Google rankings, their most valuable corporate secret, but still, this is a big, hard, expensive job, with relatively clear inputs and measurement, but with totally opaque outputs / ROI.