Hacker News Reader

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 should behave like that, whether it was single-page app or tradiotionally implemented.)

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?

If I understand your question, you're asking about adding functionality to a webapp to make it feel like a webpage rather than enhancing a page to add new features. The best two examples are actually mentioned above.

1. Using history.pushstate to intelligently add to page history for meaningful changes to the page. This ensures pressing "back" in your browser is still reliable.

2. Using server-side rendering on the first render. This keeps SPAs fast while the payload is being transferred.

Regarding Wikipedia's definition, that's a more broad definition than I'm used to seeing (speaking as a web developer). I've always heard it in reference to falling back gracefully from Javascript - usually with a <noscript> tag.

Supporting mobile, weaker networks, accessibility, etc. fall into much larger categories. Many of these topics require their own discussion and best practices.

Those topics are of course still important today (if not even more so).

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

>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-1000ms latency for a few days before I hit the 20Gb cap, then I get 0.5-1Mbs for the rest of the month. Hacker News is one of the few sites on the web that I can browse relatively painlessly when I'm up here.

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.

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 unfortunately rarely taught.

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

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.

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

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.

+1M to the idea to leverage CUER data to filter recommendations. That would be awesome.

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 suggested, and not only got FOUC'ed up the ass, the page took longer to load. (bbbbbut it's asynchronous, that's what makes it SO FAST!) Nope, that didn't last long. Not going to do it, Goog.

[0] I have a strict Content Security Policy that forbids inline JS and CSS, and am considering using a require-sri-for declaration. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

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.

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 (<10 Mbps), bad round trip time (>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

Thanks for the extra info. I assigned myself an issue to remind myself to look into the topic more: https://github.com/google/WebFundamentals/issues/6832

I think my comment may get buried but I'll try anyway :)

I'm one of the engineers working on web.dev and recently we had some issues with the way the report was being generated (detail here: https://medium.com/dev-channel/web-dev-status-update-14th-no...)

Specifically, there were audits flagged as "not applicable" and the alpha version of Lighthouse was instead flagging them as failures. That's why it looked like it was telling you to add audio or images—it was actually saying those audits are not applicable because your site doesn't use audio or images. I think that bug has been fixed in Lighthouse but feel free to reply to this comment if you're still seeing it.

We've also temporarily turned off the PWA audits—they were having some bugs of their own based on the infrastructure they were running on. Based on the feedback in this thread we'll look into making them configurable so folks can choose if they want to run them.

We'll also be opening up the repo shortly so folks can file bugs there directly.

It even recommend the brand-new WebP format over PNG.

Only thing I changed after this audit was to use http2 on my server.

I'm assuming you are being sarcastic about WebP being brand new - the format's been around for 8 years now.

My website scored a 46 as well. It's just a couple HTML pages with a single stylesheet but Google really wants me to configure it so you can read my internet webpage outside of the internet.

I think I'm gonna add an explanation for what CTRL+S does instead.

I tested one of my websites which is a simple Flask app, and where the front page is just text, images and links.

My score was 500: Lighthouse Internal Server Error.

You might want to brush up your knowledge on what a PWA actually is [1]. For example, that list contains 'Site works cross-browser'. I hope your website works cross-browser too ;-)

The only thing that sets apart a normal modern website (https, responsive, cross-browser, Each page has a URL) and a PWA is the ServiceWorker (and a few meta-tags). All the other aspects are more or less soft or minor aspects like "Page transitions don't feel like they block on the network".

This might sound pretty preachy, but in fact, I just want to give a better perspective on what PWAs are, so that they are not getting confused with the average single page JS bloat. Instead, PWA is more like best-practice (e.g. to avoid broken back buttons) paired with some mandatory tools.

[1]: https://developers.google.com/web/progressive-web-apps/check...

Hell yea my site works cross-browser. I've tested it with Firefox, Chromium, Midori, w3m, lynx, surf, and edbrowse and they all look fine.

I freely admit I have no idea what a PWA actually is, but that page is not helping me understand. All I find are vague descriptions about how they're reliable, fast and engaging, but nothing even approaching a definition. For all I know, a 16-ounce claw hammer is a PWA. It's certainly very reliable, fast and supremely engaging.

If PWA is all about the service worker, why are things like HTTPS, splash pages, 200 offline, or address bar matching brand colors(?!) included in the category? Those things don't make my site any faster or more responsive, and I doubt a service worker would either. Why on earth would I want my site to return 200 offline anyway? I don't wanna lie to a user.

Ok, lemme take a deep breath. I'm sure a PWA does not equal a single-page broken piece of JS monstrosity. I just don't think it's a good idea to give me bright red warning triangles about not having a service worker unless Google believe every site should have a service worker. In that case I disagree with them because I don't think I need a 200 OK if my network interface has caught fire in the middle of browsing.

Explorer & Edge make up more than 30% of internet traffic, yet you ignore testing them?

I don't have a computer running an operating system that supports either of those browsers so I can't test with them. However, I assume they can render basic HTML enough to make my site readable and I don't even think there's anything in the CSS to change that.

PWA = Progressive Web Application

It's basically a set of techniques and technologies developed in an attempt to produce a user experience similar to that of a native application when using a web application.

In the case of not having a service worker, well, a PWA without services workers doesn't make much sense. This is because service workers are used to cache content to create that 'native' feeling of your application not 404ing when you go through a tunnel.