Comments (10)
I'm wondering if we need to change the HTML gatherer to a DOM gatherer. In the Node code we can use JSDOM / cheerio, in the extension use DOMParser
. Then you have something you can query more effectively with querySelector('head meta[name="viewport"]')
.
I suspect many of the audits that will want to query DOM will want to do so that way rather than via RegExps.
from lighthouse.
sounds good. Will take a look at doing this instead.
from lighthouse.
Yeah def give it a go. I do some branching in the manifest gatherer for similar reasons (fetch in extension vs request in Node). This would likely be the same thing. The viewport is the only audit reliant on this atm, so it's impact should be minimal, and the viewport audit has tests so ... 👍
from lighthouse.
BTW if you use DOMParser
you need to know it doesn't throw if it can't parse. It will make you a doc with a <parseerror>
node .... yah I know.
from lighthouse.
I've started looking at one way to do this dom like selector in the audits and ended up doing the following - https://github.com/GoogleChrome/lighthouse/blob/html-theme-color-audit/gatherers/html.js
I essentially give the audits access to the window OR use JSDom for node environments. (In the chrome extension I have to ignore the jsdom module because babel / browserify doesn't like something in it).
@paulirish seems not too happy about JSDom being added, so simple solutions would be:
- Use basic regex to extract the head and body content of the HTML string and share that with audits (Nice and simple but still requires regex for extraction, which isn't that big of a deal).
- Use chrome driver to access to extract the head and body and share those strings with the audits (Slight variation on the above)
- Pass the driver to the audits to request anything they want (Feels O.T.T and may not be overly reliable if the audits are async)
- .....
from lighthouse.
First, on ChromeDriver... It's doing 90% of its browser interaction by via the Chrome Debugging Protocol that we're using directly. So it's pretty much the jQuery to our DOM. And in this case, we're too cool for jQuery. (That and we're unable to do everything we want via ChromeDriver and they dont work side by side)
Overall, we should always trust the browser as source of truth and take care when serializing/reparsing over in Node that we maintain 100% fidelity with what the browser sees.
I think we have a few options :
gather/theme-color-meta.js
- read DOM: We useDOM.querySelector
andDOM.getAttributes
etc, just like in gathers/manifest.jsgather/theme-color-meta.js
ask JS: We useRuntime.evaluate
and get the answers we need from clientside JS. (actually what's in the old viewport gather and audit)gather/DOM-snapshot.js
read entire DOM: We dump some representation of the full DOM tree and reuse that across tests.
Talking with @paullewis and both of us favor 1 or 2, assuming they are done as a specialist gather and definitely not in the audit. They are fairly one-off gathers and rely on a live runtime, but they should be straightforward and less brittle than... 3.. which would be very testable, but would also need ergonomics sugar to handle walking, querySelectoring, etc.
@gauntface do you have a preference of 1 or 2?
from lighthouse.
I'm probably more inclined for option 2 but curious why it was changed from
this?
On Fri, 25 Mar 2016, 00:25 Paul Irish, [email protected] wrote:
I read in the opensource handbook that you should upset everyone with a
big rejection of a new contributor's first PR.Or not. [image: 😕] Again, sorry for being terse and stuff.
I feed this thread more flowers for good luck: [image: 🌷] [image:
💐] [image: 🌹]
First, on ChromeDriver... It's doing 90% of its browser interaction by via
the Chrome Debugging Protocol
https://chromedevtools.github.io/debugger-protocol-viewer/ that we're
using directly. So it's pretty much the jQuery to our DOM. And in this
case, we're too cool for jQuery. (That and we're unable to do everything wewant via ChromeDriver and they dont work side by side)
Overall, we should always trust the browser as source of truth and take
care when serializing/reparsing over in Node that we maintain 100% fidelity
with what the browser sees.I think we have a few options :
- gather/theme-color-meta.js - read DOM: We use DOM.querySelector and
DOM.getAttributes etc, just like in gathers/manifest.js
lighthouse/gatherers/manifest.js
Lines 49 to 53 in af3ead2
- gather/theme-color-meta.js ask JS: We use Runtime.evaluate and get
the answers we need from clientside JS. (actually what's in the old
viewport gather
lighthouse/audits/viewport-meta-tag/gather.js
Lines 21 to 33 in 432323b
and audit
https://github.com/GoogleChrome/lighthouse/blob/432323b1035e0449bb1ebdc20f0ef53923365a3c/audits/viewport-meta-tag/audit.js
)- gather/DOM-snapshot.js read entire DOM: We dump some representation
of the full DOM tree and reuse that across tests.Talking with @paullewis https://github.com/paullewis and both of us
favor 1 or 2, assuming they are done as a specialist gather and definitely
not in the audit. They are fairly one-off gathers and rely on a live
runtime, but they should be straightforward and less brittle than... 3..
which would be very testable, but would also need ergonomics sugar to
handle walking, querySelectoring, etc.@gauntface https://github.com/gauntface do you have a preference of 1
or 2?—
You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub
#77 (comment)
from lighthouse.
I'm probably more inclined for option 2 but curious why it was changed from this?
Not sure. Lewis did it a while back.
Closing this as it seems to be mostly taken care of with the DOM based approach in the PR now. I'm adding some documentation so that there's justification for this sorta thing.
from lighthouse.
Oh, on Chrome Driver. It might make sense to use ChromeDriver for tests, but I have a feeling like it'd break since we require the protocol in either case (although devtools eng is working on fixing that bug).
from lighthouse.
note that we already have the latest (continuous build) Chrome downloading and starting up (listening on port 9222) on Travis, so anyone can start writing tests against a live browser today
from lighthouse.
Related Issues (20)
- Unexpected changes in main thread time reported around March 8th HOT 8
- Sequential network requests are simulated as parallel and the first rtt is ignored
- Lone surrogate character breaks PSI proto conversion HOT 4
- Was filing bug report when site crashed multiple before I could get the first report in HOT 2
- On certain audited pages, `totalBodyElements` are different from `MainDocumentContent` body nodes count HOT 1
- The Future of WordPress in the Age of AI Integration HOT 2
- Site security issues while making payment to Comcast. HOT 1
- SEO updates from recent search conversations
- Unexpected changes on main thread work from 11.6.0 to 11.7.1 HOT 3
- Viewport resizing to window size
- Lighthouse LCP Issue HOT 1
- LCP not recognized in many pages for this site. HOT 1
- Print stylesheet picked for Render-blocking resource HOT 1
- Incorrect user agent on pagespeed.web.dev HOT 1
- Protocol error (Target.getTargetInfo): Protocol error (Target.getTargetInfo): 'Target.getTargetInfo' wasn't found HOT 3
- Keep passing Core Web Vitals but failing LCP
- "Opportunities" no longer surfaced in report or in resulting output in Lighthouse 12 HOT 5
- CPU throttling is unstable
- Testing Page metrics for different HTTP versions HOT 1
- LH:ChromeLauncher Waiting for browser
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lighthouse.