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.
(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.)
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.
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?
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).
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.
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.
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.
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.
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.
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.
[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
> 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.
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...
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.
Only thing I changed after this audit was to use http2 on my server.
I think I'm gonna add an explanation for what CTRL+S does instead.
My score was 500: Lighthouse Internal Server Error.
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...
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.
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.
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 include audio so I could have a transcription to go with it. Not sure whether Lighthouse decided that 16px or 20px is less than 12px but apparently one of them is and makes up over 60% of the page.
I understand this is not made for people who serve static HTML files and handmade CSS from ~/sites/ but I'm pretty sure I hate the kinds of sites this is designed for. Should have a custom splash screen? Respond with 200 when offline? What's next, I get points for breaking the back button too? Why is using HTTPS and redirecting HTTP to it a PWA thing?
I'd hate to see the site that aces this audit.