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

191–200 of 264 posts

Re: Web.dev by Google

#191

Post by exprA »

NelsonMinar wrote: post #53

Talk about breaking the back button! Do a measurement on a website. Then click one of the Guide links like "Links do not have a discernible name". Page navigates away from the report to some documentation. Click back, report is gone. I get it, it's a single page webapp. But if you do that you need to make all the simple navigations open new tabs. There is a "open link in new button" icon next to each link, but that's…

Also broken everywhere else in the site for me: you never get back to where you were* , even on a “static” page full of links.

A horrible excuse of a web site – but perhaps that still makes for a good web app. I couldn't tell and don't know if I'd want to.

* edit for clarification: this includes position on previous page

Re: Web.dev by Google

#192

Post by jansan »

robdodson wrote: post #167

Hey folks, I wanted to share a quick status update to let y'all know which issues we're seeing and working on. Apologies for the hiccups and thank you all for trying the beta! https://medium.com/dev-channel/web-dev-status-update-11-12-1...

Much appreciated, thanks!

Re: Web.dev by Google

#193

Post by seanhunter »

I'm amazed by how far off-base they have managed to make this. The recommendations are bizarrely inaccurate.

1)it says that my (black) text doesn't have sufficient contrast against my (white) background. 2)It says that my page could benefit from having more of its resources served by http 2 (more than 100% presumably). 3)It says that links should have a name (this is not supported by html5) 4)It says my (100% valid) robots.txt file is not valid 5)it says my 100% no javascript static webpage which isn't a PWA should return a 200 when offline. Not sure how they think I should do that.

Re: Web.dev by Google

#194

Post by zwaps »

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 bullcrap. It never works correctly and then you just get a laggy and slow scrolling site where you have to wait all the time you use it. It's a news site. Just load the whole thing, it takes a couple of ms but then the site is actually usable! It's an actual document you can scroll through.

- Ask the user to install as an app, add offline usage etc? Why even?

- Dynamically compress everything? YES GOOGLE, when saving 8kb per picture, but in the end we need to pull 10mb of javascript libraries from sixty different sources all over the web to even display a text with one small picture ITS ALL WORTH IT

I don't make websites except my personal stuff. I understand you want to present your knowledge and skills. But please, the websites are getting worse and worse. The best way to present almost any information is in a classic html webpage. It wouldn't need to be like this, but almost any modern websdesign approach seemingly leads to slow, laggy and partly unusable websites, that do end up loading something, but often not the thing I actually want to read.

I am actually trained now to feel a sense of relief if I come across a straight html website, just because the user experience is so terrible now thanks to javascript.

As a consumer, I will continue to beg for simple websites that stay true to the idea of displaying a scrollable document with data and text.

Please, only use all these animations, loadings, dynamics, off-site frameworks, custom browser controls and single page documents if you are making a) a portfolio b) an actual application that is mostly simple buttons and does not present significant amounts of text or data

thank you

its bad guys

Re: Web.dev by Google

#195

Post by pmlnr »

Yaggo wrote: post #190
KevanM wrote: post #183

Earlier quoted context omitted.

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.

Properly made "web application" doesn't have to break the web. It can be curled, links work, back button works, etc. You just don't get any interactivity (besides links) without javascript, but it still works as browseable site (rendered server-side). You can have the cake & eat it. (I'm not saying that every application should behave like that. Often the extra work is not worth it. But a public, content-heavy site s…

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

Re: Web.dev by Google

#196

Post by sniuff »

koboll wrote: post #154
robdodson wrote: post #57

Earlier quoted context omitted.

Ah yeah that's something we want to fix. If you're signed in it keeps the report around but if you're signed-out it's stateless. It's definitely on our to-do list to fix.

Maybe just throw on a target='_blank', no need to do anything fancy

it's stateless

Re: Web.dev by Google

#197

Post by SquareWheel »

pmlnr wrote: post #195
Yaggo wrote: post #190

Earlier quoted context omitted.

Properly made "web application" doesn't have to break the web. It can be curled, links work, back button works, etc. You just don't get any interactivity (besides links) without javascript, but it still works as browseable site (rendered server-side). You can have the cake & eat it. (I'm not saying that every application should behave like that. Often the extra work is not worth it. But a public, content-heavy site s…

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.

Re: Web.dev by Google

#199

Post by PavlovsCat »

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.

WP describes it as

> Progressive enhancement is a strategy for web design that emphasizes core webpage content first. This strategy then progressively adds more nuanced and technically rigorous layers of presentation and features on top of the content as the end-user's browser/internet connection allow. The proposed benefits of this strategy are that it allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.

It's way, way more than JS.

> They are describing how to correctly write SPAs and other webapps.

In the context of "I have a website, not a web app", and web apps that "don't break the web", i.e. also behave well as web pages. If you are suggesting anyone is building backwards to that from a web app, instead of progressive enhancement, do you know an example?

Re: Web.dev by Google

#200

Post by jefftk »

gondo wrote: post #68
arkitaip wrote: post #63

Earlier quoted context omitted.

Most performance profilers will penalize you for embedding Google Analytics and Google Fonts because they have poor caching settings. What's so important about those resources that they can't be cached for longer periods?

tracking

While I don't know anything about fonts stuff, successful execution of the ad tag leads to an ad request, and this happens on every page view which has the script and not just the ones where the file has fallen out of cache. So there's no additional useful information Google would get from a low cache lifetime for the script.

The script request is to a cookiless domain for performance, unlike the ad request, so there's not even much useful information on that request.

(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)

Post reply on HN