Live data from Hacker News

Web.dev by Google

web.dev

251–260 of 264 posts

Re: Web.dev by Google

#251
post #220

These comments really highlight how Hacker News is slowly devolving into Slashdot with a stuck in the past mentality and no constructive criticism just groupthink attacks on "stuff we don't like or understand".

Please don't make this place even worse by posting low-information rants. Instead, provide correct information, so we can all learn something. If you don't want to do that or don't have time, it's simple to just not post.

https://news.ycombinator.com/newsguidelines.html

Re: Web.dev by Google

#252
post #219

Earlier quoted context omitted.

I see no explanation given why an asset that never changes would need to be requested once a day, and they clearly state they do record it. > We only [sic] see 1 CSS request per font family, per day, per browser. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure. I read that as what's written there. It's for tracking. Tracking popularity is still tracking.

> Tracking popularity is still tracking. Tracking usually refers to tracking users, which as I read the FAQ isn't what it's for.

They take and keep the tracking data. What they say they use it for doesn't change that. If they simply incremented a counter the bit about "keeping access to the data secure" would make no sense.

Re: Web.dev by Google

#253
post #227

Earlier quoted context omitted.

Sorry, I'm not letting you get away with an illogical argument here. There's nothing hypocritical about the authors of web.dev making an auditing tool because some other people who work for the same company work on site that (may) do badly. In fact, it wouldn't be hypocritical even if the authors of web.dev themselves worked on a site that did badly. It is, after all, a tool. It's not a declaration of superior intell…

The hypocritical statement is on the part of the company, not the specific authors. The efforts represent the company, as do their efforts in standards organizations, browser implementations, and email user interfaces. It is completely logical to question their inconsistencies especially as one of the primary drivers of standards. If the company cannot present a consistent front, we can ask ourselves whether their at…

Releasing a tool cannot be hypocritical. The existence of a tool to audit performance, accessibility, etc. is not a declaration of Google's moral or virtuous superiority. It's a tool.

Re: Web.dev by Google

#254
post #238

Earlier quoted context omitted.

> 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 enhanc…

I'd put network use in a different category. It is an important issue though. Thankfully the tools are getting better for this. The recently supported font-display property is a great one. It allows devs to choose how to handle web font rendering over slower internet connections. Now I just wish more devs would start to take advantage of all the great performance tools available. Those best practices are unfortunatel…

> I'd put network use in a different category. It is an important issue though.

My rationale for considering it to be included is that as the concept was developed I took the spirit of progressive enhancement to be doing the best with what your users have rather than only catering to people with the same setup you have.

> Now I just wish more devs would start to take advantage of all the great performance tools available. Those best practices are unfortunately rarely taught.

Agreed. I think one of the challenges has been both showing business value from performance — once you're putting things into a cost/benefit comparison it's a lot easier to get people to routinely consider the performance impact of their decisions.

Re: Web.dev by Google

#255
post #238

Earlier quoted context omitted.

> 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 enhanc…

>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. And that's still great internet compared to some places. I have a house out in the middle of nowhere that is only served by a single satellite internet provider (surrounded by trees that block the view to other providers' sats). I get 20Mbs at ~500…

A couple of years back I was at a conference in Rome. Literally in the heart of the city (the windows overlooked the Forum) and that meant that they had only satellite access because nobody had run cables through the historic buildings. I've never been more glad to have spent time optimizing our site for 2.5-3G performance than when we were demoing it during presentations and it seemed slow but almost everything else was unusable.

Re: Web.dev by Google

#256
post #238

Earlier quoted context omitted.

> 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 enhanc…

I'd put network use in a different category. It is an important issue though. Thankfully the tools are getting better for this. The recently supported font-display property is a great one. It allows devs to choose how to handle web font rendering over slower internet connections. Now I just wish more devs would start to take advantage of all the great performance tools available. Those best practices are unfortunatel…

for font-display, do you prefer swap or fallback?

Re: Web.dev by Google

#257
post #227

Earlier quoted context omitted.

Sorry, I'm not letting you get away with an illogical argument here. There's nothing hypocritical about the authors of web.dev making an auditing tool because some other people who work for the same company work on site that (may) do badly. In fact, it wouldn't be hypocritical even if the authors of web.dev themselves worked on a site that did badly. It is, after all, a tool. It's not a declaration of superior intell…

The hypocritical statement is on the part of the company, not the specific authors. The efforts represent the company, as do their efforts in standards organizations, browser implementations, and email user interfaces. It is completely logical to question their inconsistencies especially as one of the primary drivers of standards. If the company cannot present a consistent front, we can ask ourselves whether their at…

Maybe the web.dev is trying to convince other teams at Google to improve their products.

Re: Web.dev by Google

#258

Earlier quoted context omitted.

I'd put network use in a different category. It is an important issue though. Thankfully the tools are getting better for this. The recently supported font-display property is a great one. It allows devs to choose how to handle web font rendering over slower internet connections. Now I just wish more devs would start to take advantage of all the great performance tools available. Those best practices are unfortunatel…

for font-display, do you prefer swap or fallback?

It might depend on main body text versus title text. It's jarring when body text changes so I'd prefer fallback in that case. For a title which might have more branding concerns, I'd prefer swap.

Re: Web.dev by Google

#259
I have a question. How can I really figure out whether my (static) website uses http2? The google audit tells me that I should use http2 for all of my resources but loading my site in Safari or Chrome shows me that it uses the h2 protocol. Or are these unrelated?

Weirdly it also points out that my elements have non-unique Ids which is false and the list of failing elements shows that, it looks like they are stopping their search at the colon character, but they should not.

Re: Web.dev by Google

#260

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…

[deleted]
Post reply on HN