Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Check and penalise sites that require client-side JS #392

Closed
stuartlangridge opened this issue May 29, 2016 · 11 comments
Closed

Check and penalise sites that require client-side JS #392

stuartlangridge opened this issue May 29, 2016 · 11 comments

Comments

@stuartlangridge
Copy link
Contributor

stuartlangridge commented May 29, 2016

A progressive web app should be progressively enhanced, and so it shouldn't fail without client-side JavaScript. This may be difficult to test for (most sites don't show nothing, they show an empty app which never loads any content), but is an important metric.
@paullewis
Copy link
Contributor

paullewis commented May 29, 2016

There's definitely something here to check. I think we need to first figure out what's testable in this space, though. As you said, a site could throw something on screen. Though perhaps at least we can check that without JS there is at least something rendered, and perhaps that there is text content?

@stuartlangridge
Copy link
Contributor Author

stuartlangridge commented May 29, 2016 •
edited

I can think of a bunch of ways of doing this, but they're all hack city and will require me to hand back my web developer membership card -- disable JS and then check things like "if the page HTML contains no interactable elements like <a>, you probably haven't rendered anything" and "if clicking on everything on the page never changes anything about the page, you probably require your JS to load before anything works". This is like a Turing test; it's really easy to tell whether a site does nothing if you're a human. :(

@paullewis
Copy link
Contributor

paullewis commented May 29, 2016

Yep, perhaps our first attempt at this is fairly loose, and we look to iterate and improve. Certainly I think we can attempt something and see how it pans out. We might be able to get a bunch of signals together (and yep, all of them are hacktown!)

@addyosmani
Copy link
Member

addyosmani commented May 30, 2016

A progressive web app should be progressively enhanced, and so it shouldn't fail without client-side JavaScript

Two cents. I strongly advocate for fully functioning without client-side JS as much as possible, but I think it's valuable to be mindful of certain classes of application where this might not be quite as feasible (I guess this is where being fairly loose helps).

For example, https://voice-memos.appspot.com/ can do an SSR for the shell and provide you with static content but it's not particularly useful as an app without client-side JS. Would passing the test = you've rendered at least "something"? rendered and elements can be interacted with (even if they don't do anything useful)?

I imagine it'll be tricky. Interested to see where LH lands on this :)

@stuartlangridge
Copy link
Contributor Author

stuartlangridge commented May 30, 2016

Certainly I can get behind the idea that, say, Voice Memos might say "sorry, this just flat doesn't work because my JS library didn't load". But an app which says "Hi there {{user.name}}!" when that happens, nobody wants that :)

@samccone
Copy link
Contributor

samccone commented May 30, 2016

Here is a simple check...

Disable JS, reload the page ... is anything on the page? If so good job.. if not alert the user that they should provide at least some fallback content.

This is a fine first check and will catch the worst offenders (those that do 100% client side rendering).

We can do more in this space but this is a real good first step. Thanks for the idea @stuartlangridge

@stuartlangridge would you like to take a first stab at the implementation of this?

@stuartlangridge
Copy link
Contributor Author

stuartlangridge commented May 30, 2016

I'd like to take a look at this later this week if I can, yep. (I think even people doing totally client-only rendering put something on the screen; sites which are literally just <body></body> are thankfully rare these days (that much of the message has got through!)) but as you say it'll be a first step at least.

stuartlangridge added a commit to stuartlangridge/lighthouse that referenced this issue Jun 1, 2016
@stuartlangridge
Start adding a set of audits to check that sites are progressively
9cbeded 
enhanced, as per GoogleChrome#392.
This is the most very basic of such audits; it checks that the page
contains some textual content if scripting is disabled. Future and
further audits can be more discerning and check whether there is
_useful_ content.
@stuartlangridge stuartlangridge mentioned this issue Jun 1, 2016
Merged
stuartlangridge added a commit to stuartlangridge/lighthouse that referenced this issue Jun 1, 2016
@stuartlangridge
Start adding a set of audits to check that sites are progressively
5955191 
enhanced, as per GoogleChrome#392.
This is the most very basic of such audits; it checks that the page
contains some textual content if scripting is disabled. Future and
further audits can be more discerning and check whether there is
_useful_ content.
@paulirish
Copy link
Member

paulirish commented Jun 10, 2016

fixed now with #405 being landed

@The-Don-Himself
Copy link

The-Don-Himself commented Apr 28, 2017

Sorry for reviving this, but I have an issue regarding LH's implementation.

I have an Ember.js app whose progressive enhancement features are provided by fastboot.

I can confirm every page can show content without javascript enabled (although currently fully dynamic pages - those that require active sessions checking e.g home page - are only showing loading pages)

So even though everyone will see content without JS, my service worker currently caches ember's blank index.html, which could be improved later but is acceptable for now.

The Issue is that the Lighthouse report shows my web app as not progressively enhanced. Which implies to me that the checks for client-side js utilize the service worker which is itself js hence flawed. I could be wrong and more of a backend guy to did deeper into this. But can someone confirm this as an issue.

@patrickhulce patrickhulce mentioned this issue Apr 28, 2017
Closed
@patrickhulce
Copy link
Collaborator

patrickhulce commented Apr 28, 2017

Thanks for the report @The-Don-Himself! I can confirm your situation, and I've filed a new issue over in #2096 that you can follow :)

@The-Don-Himself
Copy link

The-Don-Himself commented Apr 29, 2017

@patrickhulce thanks for looking into this, I've subscribed to #2096 for updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@paulirish @addyosmani @paullewis @samccone @patrickhulce @stuartlangridge @The-Don-Himself