9 ms·

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 progres

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

KevanM 8y ago
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.
- Yaggo 8y ago
  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.)
  - pmlnr 8y ago
    This is called progressive enhancement and, sadly, nobody seems to be doing it any more.
    - SquareWheel 8y ago
      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.
      - PavlovsCat 8y ago
        > 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?
        SquareWheel 8y ago
        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).
- kaycebasques 8y ago
  > 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.
TomK32 8y ago
It even recommend the brand-new WebP format over PNG. Only thing I changed after this audit was to use http2 on my server.
- richbradshaw 8y ago
  I'm assuming you are being sarcastic about WebP being brand new - the format's been around for 8 years now.
arendtio 8y ago
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/checklist https://developers.google.com/web/progressive-web-apps/check...
- bitofhope 8y ago
  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.
  - Calib3r 8y ago
    Explorer & Edge make up more than 30% of internet traffic, yet you ignore testing them?
RandomGuyDTB 8y ago
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.
- semi-extrinsic 8y ago
  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.
theandrewbailey 8y ago
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 https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
- kaycebasques 8y ago
  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.
  - theandrewbailey 8y ago
    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 https://httparchive.org/reports/page-weight [1] https://www.nngroup.com/articles/how-long-do-users-stay-on-web-pages/ https://www.nngroup.com/articles/how-long-do-users-stay-on-w... [2] https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduc... [3] https://www.w3.org/Style/Examples/011/firstcss#external https://www.w3.org/Style/Examples/011/firstcss#external
kaycebasques 8y ago
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/readme.md#configjson 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.
- billyhoffman 8y ago
  +1M to the idea to leverage CUER data to filter recommendations. That would be awesome.
deleted 8y ago
[deleted]
robdodson 8y ago
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-nov-2018-18708787f239 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.

KevanM 8y ago

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.

Yaggo 8y ago
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.)
- pmlnr 8y ago
  This is called progressive enhancement and, sadly, nobody seems to be doing it any more.
  - SquareWheel 8y ago
    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.
    - PavlovsCat 8y ago
      > 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?
      - SquareWheel 8y ago
        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).
kaycebasques 8y ago
> 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.

TomK32 8y ago

It even recommend the brand-new WebP format over PNG. Only thing I changed after this audit was to use http2 on my server.

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

arendtio 8y ago

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/checklist https://developers.google.com/web/progressive-web-apps/check...

bitofhope 8y ago
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.
- Calib3r 8y ago
  Explorer & Edge make up more than 30% of internet traffic, yet you ignore testing them?

RandomGuyDTB 8y ago

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.

semi-extrinsic 8y ago
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.

theandrewbailey 8y ago

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 https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

kaycebasques 8y ago
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.
- theandrewbailey 8y ago
  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 https://httparchive.org/reports/page-weight [1] https://www.nngroup.com/articles/how-long-do-users-stay-on-web-pages/ https://www.nngroup.com/articles/how-long-do-users-stay-on-w... [2] https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduc... [3] https://www.w3.org/Style/Examples/011/firstcss#external https://www.w3.org/Style/Examples/011/firstcss#external

kaycebasques 8y ago

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/readme.md#configjson 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.

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

deleted 8y ago

[deleted]

robdodson 8y ago

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-nov-2018-18708787f239 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.