Hacker News Reader

Core web vitals is a joke. Literally 4 days ago it started bitching to me about breadcrumbs telling me that data-vocabulary.org schema deprecated

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.

I tried to report a bug to Intuit about QuickBooks online the other day. 45 minutes later, the person answering the phone at the other end was finally able to give me a ticket number. I don't understand why it has become so hard to give feedback to developers to improve their product. I like it when people report bugs that give me a better understanding of how my software is being used -- am I really in the minority here?

Depends on the bug, if it hurts the business it's generally fixed instantly, if it's just an annoyance, feet are dragged.

No, it's just that bugs of the type you describe are the minority of those that people want to report.

If you want to write something about your experience with this, I'm sure the community here would appreciate a fact-based third-party article. If you wrote it in the same style as your comment here, we would put such an article in the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so it would get a random placement on HN's front page. Email me at hn@ycombinator.com if you'd like some tips about that.

Thanks! I'll run it by stakeholders internally and see if I can de-anonymize :)

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

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.

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.

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.

How does WebP improve rendering times?

It takes less space so it downloads faster.

The cruft in webpages is not from having support for multiple image types.

its look at any site in chrome dev tools.

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

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

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.

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.

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.

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.

I'm not talking about browser features, I'm talking about the lazy loading JavaScript libraries that many (most, I'd wager) use.

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.

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.

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.

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.

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.

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

It's partly JS, it's partly the data populating the tables.

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.

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.

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

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

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.

That's definitely too defensive and that makes it a bit annoying. I'm sure the page would work very well with the html lazy loading, the images are small enough.

Getting wildly different numbers from different tools is super annoying but I'm pretty sure the data they'll actually use in rankings is crowdsourced from Chrome users: https://web.dev/chrome-ux-report/

Which of course you can only see weeks in retrospect.

Yeah not only is there a 28 day lag time, but _new_ content on your site is grouped with "similar" URLs, using some secret Google special sauce to determine other pages on your site to use as a baseline. This has been one of the most frustrating parts.

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.