Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web.dev by Google

web.dev

Post reply on HN
Print view View original

231–240 of 264 posts

Re: Web.dev by Google

#231

Post by kaycebasques »

bitofhope wrote: post #178

This is useless to me because I have a website, not a web application. I got a 46/100 on PWA which is astonishing because the site being tested is not a progressive web application at all. Imagine vim getting a 40/100 score in the category of web browsers. Weirdly good score. The accessibility audit is garbage as well. Apparently I should add an image to the site just so I can put an alt attribute in it. I should inc…

If you run Lighthouse (the tool that powers web.dev's auditing feature) from a CLI or as a Node module, you can tell it to only run the audits that are relevant to your needs.

https://github.com/GoogleChrome/lighthouse/blob/master/docs/...

I get the general frustration that non-technical teammates look at these reports and say, "we're doing terrible, you need to fix this" when in reality you know that the audits aren't relevant to your business. But it's tough to create an auditing tool for the web at large. There are a lot of businesses that would benefit from PWA features. The general idea was to raise awareness of how PWA features can often improve the UX of many sites. Not all, but many. My takeaway from this discussion is that we need to improve our messaging around the fact that these audits aren't commandments. Some of them may not be relevant to your top priorities. Maybe we could improve the report UI in DevTools and web.dev so that you can flag individual audits as irrelevant. On subsequent runs, those audits would be omitted from your reports. Or maybe we can somehow get more clever about how to present certain audits. E.g. based on Chrome User Experience Report data we identify that service worker usage in your industry is low, and we flag the service worker audit as potentially irrelevant to your needs. That would help solve the problem of non-technical people seeing a low score and assuming that it's a fault with your site, when in reality it's just an irrelevant audit.

Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.

Re: Web.dev by Google

#232

Post by kaycebasques »

theandrewbailey wrote: post #228
bitofhope wrote: post #178

This is useless to me because I have a website, not a web application. I got a 46/100 on PWA which is astonishing because the site being tested is not a progressive web application at all. Imagine vim getting a 40/100 score in the category of web browsers. Weirdly good score. The accessibility audit is garbage as well. Apparently I should add an image to the site just so I can put an alt attribute in it. I should inc…

I hate how Google's tools keep pushing deferred CSS. It kind of breaks how CSS is supposed to work. They want you to manually pick out the CSS that is relevant to the top of the page, and put it directly into your HTML. How on earth is that maintainable or scaleable? Or secure?[0] You easily run the risk of sending redundant bytes if the same styles are still in your external CSS. I tried that little script they sugg…

I agree that splitting up your CSS to only send the critical stuff first is tough to scale and it's tough to find a reliable solution.

> It kind of breaks how CSS is supposed to work.

Can you elaborate on this?

> You easily run the risk of sending redundant bytes if the same styles are still in your external CSS.

I think we're up against 2 less-than-optimal situations. Suppose you have 50KB of CSS.

* Ship it the traditional way. User waits on all 50KB before first paint.

* Ship it the code splitting way. User gets 10KB upfront, and leaves before the rest loads. But if they interact with the site extensively, then they trigger the redundant bytes that you're mentioning, so that the total download size comes out to be 75KB.

Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.

Re: Web.dev by Google

#233

Post by kaycebasques »

billyhoffman wrote: post #27

This is powered by Google Lighthouse, with the benefit of it being done via a web UI instead of a Dev Tools Audit. Which is both good and bad. Good because Lighthouse has some reasonable best practices to follow, and a few good performance timings, so lowering the barriers of entry is nice. Bad because many of Lighthouses best practices aren't always applicable (our major media customers constantly say "stop telling…

> Bad because many of Lighthouses best practices aren't always applicable

It's tough to create an auditing tool that caters to the web at large. See my other comment in this thread: https://news.ycombinator.com/item?id=18442686

> This all also overlooks the value that something like the Browser's User Timings provides... which Lighthouse doesn't surface up.

Lighthouse does surface up this info in the "User Timing Marks and Measures" audit: https://developers.google.com/web/tools/lighthouse/audits/us...

But I'm getting the impression that you want Lighthouse to surface up this information in a different way. Please feel free to elaborate.

Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.

Re: Web.dev by Google

#234

Post by kaycebasques »

KevanM wrote: post #183
bitofhope wrote: post #178

This is useless to me because I have a website, not a web application. I got a 46/100 on PWA which is astonishing because the site being tested is not a progressive web application at all. Imagine vim getting a 40/100 score in the category of web browsers. Weirdly good score. The accessibility audit is garbage as well. Apparently I should add an image to the site just so I can put an alt attribute in it. I should inc…

This, so much this. The skew to web applications rather than websites for tooling has been very disappointin and myopic view of what a 'website' is. It would make sense if I could give it a root URL and then a robot progressively ran tests over a month and then reported back, but one URL is a drop in a vast ocean for most of us.

> It would make sense if I could give it a root URL and then a robot progressively ran tests over a month and then reported back, but one URL is a drop in a vast ocean for most of us.

I think this is the end goal. Building the infrastructure to audit a single page is the first step towards that bigger outcome.

Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.

Re: Web.dev by Google

#235

Post by kaycebasques »

stupidbird wrote: post #99

I can't wait for one of the executives in my company to run into this, understand nothing but the numbers, and then complain about our numbers not being higher despite the fact that half of these metrics aren't applicable to our web app. I already have a boilerplate response to "why isn't our google pagespeed score higher" that I copy and paste. I know Google's happy about performance nagging, but I wish they were be…

I agree that this is a problem. See my other comment in this thread: https://news.ycombinator.com/item?id=18442686

Re: Web.dev by Google

#236

Post by alexbecker »

sumoboy wrote: post #50
yandrypozo wrote: post #18

I just ran their audit to https://mail.google.com , you guys (googlers) need to speed up your websites first, Gmail is terrible slow lately, just saying...

You think gmail is slow, try the new adwords interface.

Oh man, I used to be on the team that built that. It's just enormous. If you're on Chrome, the optimizations are sometimes enough to make it smooth. If you're on any other browser, god help you. I used to see 30s(!) reflows in Firefox.

Re: Web.dev by Google

#237

Post by alexbecker »

Zelphyr wrote: post #223
zwaps wrote: post #194

PLEASE PLEASE PLEASE WEBDEVS, STOP LOADING YOUR WEBSITE WITH CRAP TO MAKE THEM BETTER I fed a large news site that is not terrible to use into this, and it gave it 14/100 rating. This news site is perfectly fine, has a good design, good typography and loads without any scripts if you need it to. It loads quite fast. Among other things, Google recommends - Lazy loading: NOOOO, just load my document. I hate this bullcr…

I agree with you about lazy loading. It's just dumb. How is it better to give me a scaffold of a page before the content? The page may look nice but is unusable until the content has loaded. Why not just give me everything when it's ready? I've gotten into trouble for saying this before but things like recommending lazy loading is an example of Google imposing their wishes on the web and making it worse in the proces…

There are two kinds of lazy loading--that which blocks the content, and that which doesn't. If you have e.g. a bunch of JS libraries that aren't necessary to display the page, only for certain interactions, it makes sense to lazily load those. This is what "lazy loading" meant in my front-end team at Google anyway. (Whether you should even have all of this JS to begin with is another question, however.)

Re: Web.dev by Google

#238

Post by acdha »

SquareWheel wrote: post #197
pmlnr wrote: post #195

Earlier quoted context omitted.

This is called progressive enhancement and, sadly, nobody seems to be doing it any more.

Progressive enhancement is different than what the parent comment is suggesting. They are describing how to correctly write SPAs and other webapps. The reason progressive enhancement has fallen away is because Javascript support is now ubiquitous. Your browser has it. Your screen reader has it. Even web crawlers have it.

> The reason progressive enhancement has fallen away is because Javascript support is now ubiquitous. Your browser has it. Your screen reader has it. Even web crawlers have it.

That's only part of the problem: every day I encounter sites which fail because the developers assumed not just that everyone has JavaScript but that they can load tons of assets reliably and instantaneously. The key part of progressive enhancement is thinking about how to degrade gracefully when everything doesn't work perfectly, which also tends to offer a better experience for anyone who doesn't have a very high-speed near-perfect network connection.

A couple of weeks back, I was using a family member's Spectrum “high-speed” cable modem service at a whopping 5Mbps with latency measured in the hundreds of milliseconds. It really highlighted who was doing progressive enhancement and who was doing “works on my machine” when you saw one page load 90 seconds faster than the other.

Re: Web.dev by Google

#239

Post by magicalist »

softawre wrote: post #218
magicalist wrote: post #152

Earlier quoted context omitted.

As others have noted, looks like this is just running Lighthouse? That's been around for a long time.

From webhint's about/faq: > webhint’s development started inside the Microsoft Edge team

> webhint’s development started inside the Microsoft Edge team

...was that before lighthouse started? And was open source and seem viable at the time?

Re: Web.dev by Google

#240

Post by theandrewbailey »

kaycebasques wrote: post #232
theandrewbailey wrote: post #228

Earlier quoted context omitted.

I hate how Google's tools keep pushing deferred CSS. It kind of breaks how CSS is supposed to work. They want you to manually pick out the CSS that is relevant to the top of the page, and put it directly into your HTML. How on earth is that maintainable or scaleable? Or secure?[0] You easily run the risk of sending redundant bytes if the same styles are still in your external CSS. I tried that little script they sugg…

I agree that splitting up your CSS to only send the critical stuff first is tough to scale and it's tough to find a reliable solution. > It kind of breaks how CSS is supposed to work. Can you elaborate on this? > You easily run the risk of sending redundant bytes if the same styles are still in your external CSS. I think we're up against 2 less-than-optimal situations. Suppose you have 50KB of CSS. * Ship it the trad…

Thank you for your reply.

It breaks CSS, because having styles on the page couples presentation with content. The selling point of CSS is to change a style in one place, and have it affect multiple pages. If you break it up, you end up having to maintain multiple versions of your CSS. To do this in the name of performance strikes me as one of the very last things to do, given it's unfavorable maintenance cost.

> I think we're up against 2 less-than-optimal situations. Suppose you have 50KB of CSS.

> Ship it the traditional way. User waits on all 50KB before first paint.

Best practice for CSS is to link it in the first kilobyte or so of HTML[2][3]. Browsers have optimized for it: it makes the CSS request happen immediately, before the browser parses the rest of the HTML. Unless the user has a slow connection (200 ms), or the server is slow to serve a 50K static file (average CSS size[0]), that CSS will load within half a second, with first paint soon after. If you need to cut down that down, you should consider a CDN before deferred CSS.

> Ship it the code splitting way. User gets 10KB upfront, and leaves before the rest loads. But if they interact with the site extensively, then they trigger the redundant bytes that you're mentioning, so that the total download size comes out to be 75KB.

If CSS was split, and the user leaves[1] before the CSS completely loads, CSS isn't the source of slow page loads.

Google's tools need check if styles load within a second or two. If it's any more than 3 or 4 seconds, deferred CSS starts to make sense. If styles (or the entire page) load in less than that, don't bother.

[0] https://httparchive.org/reports/page-weight

[1] https://www.nngroup.com/articles/how-long-do-users-stay-on-w...

[2] https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduc...

[3] https://www.w3.org/Style/Examples/011/firstcss#external

Post reply on HN