googlechrome / lighthouse Goto Github PK
View Code? Open in Web Editor NEWAutomated auditing, performance metrics, and best practices for the web.
Home Page: https://developer.chrome.com/docs/lighthouse/overview/
License: Apache License 2.0
Automated auditing, performance metrics, and best practices for the web.
Home Page: https://developer.chrome.com/docs/lighthouse/overview/
License: Apache License 2.0
(orig reported at #73 )
Since we're using a bunch of es2015 features, node 4 isn't supported.
The cli should error and exit if you're not running using a 5.x runtime.
question: Should the error message recommend using nvm?
Perhaps ask the user if they have launched chrome via our helper script.
Loving the plugin so far. One thing that might be beneficial is to link to explanations for things. ex: I'm missing a canonical URL on one of my sites but if I don't know what a canonical URL is there's no explanation for how I can add one :D
Just tried running a lighthouse trace and hit the following issues:
launch-chrome.sh is OS X. Would it be worth considering moving this to an npm script and using which to pick the version of chrome to use
Node 5.9.1 is required. We could add a check for >= 5.9 and throw a warning otherwise
On linux I get the following error:
TypeError: Cannot read property '_destroySSL' of undefined
at destroySSL (_tls_wrap.js:370:7)
Going to dig into that one and try and figure out the problem but wanted to raise an issue on it..
Should we have an audit to discourage use of plugins? E.g. we already list use of Flash as a common mistake in our "mobile friendly documentation"
Some types of videos or content are not playable on mobile devices, such as license-constrained media or experiences that require Flash or other players that are not broadly supported on mobile devices. Unplayable content, when featured on a page of any website can be very frustrating for users.
A "simple" way to ensure that this is the case:
object-src 'none'
I suppose there's a few cases that we shouldn't bomb on.
I think we have decent coverage here, but we may need to bulk up tests for the manifest gatherer.
@brendankenny wanna take a stab here?
Over in my fMP pr I noted it'd be valuable to save the trace to disk.. mostly so that I can verify the metrics and summarized data is correct.
@brendankenny rightly pointed out that in addition to debugging, there's value for saving the artifacts locally for timeseries analysis (a la big-rig).
Personally, I'd be happy to save all my runs artifacts until i want to free up the disk space.
Any ideas on what setup would make sense? cmd-line option -> something?
https://github.com/GoogleChrome/lighthouse/blob/master/helpers/network-recorder.js#L21-L81
@brendankenny I think this is on you, sir. It's in case other people require('lighthouse') at some point in the future and we just, you know, stomp the global.
We can either use the DevToolsTimelineModel (which we currently do in FMP), or we can require in traceviewer.
My preference is to try and use the latter wherever we can, but fall back to the former where it offers other insights into the data.
Thoughts?
Non-async script resources that are layout-blocking.
None, some, jsdoc, esdoc? wdyt?
I think we want Blink style for the JS. What do others think?
Perhaps we can extend https://github.com/google/eslint-config-google
I'd be happy with a line length max > 110 though. :)
Brendan is put up a strawman for this.
It will include warning/severity levels and handling atomic results.
We may want to get rid of the transpilation to make dev a bit more sane.
I'm curious about using https://github.com/JamesMGreene/breq (require() polyfill via sync xhr).
Thoughts?
(Unrelatedly, doing the work in the background page will be easier to debug than doing it in popup.html).
Manual evaluation: manifest has name, background_color, theme_color, icons at 192px and up
name
background_color
theme_color
Docs: Splash screen on /web
See also "PWA validator" bookmarklet - #17
As Dion recommended, the extension can be a passive PWA inspection tool, lighting up as active when a manifest is detected.
I investigated using the chrome.declarativeContent
API for this, however it is limited to visible elements, and a <link>
element is not one.
The best solution appears to be a small content script, as "run_at": "document_idle"
, which looks for the manifest <link>
in the DOM and sets the page action icon/badge accordingly.
Does that sound about right to folks?
fewer dependencies?
try for instance
https://moji-brush.com
note how everything breaks.
I figure we can add a control that causes a full navigation of the page so we can capture page load traces and network events. This makes the extension less 'automatic', but the alternative would be to do the capture on every page load, which would be bad.
@paulirish wdyt? Am I missing something?
Manual evaluation: manifest has short_name, 144x144 png icon
image/png
or filename ending in .png
)update: ^ Copied from brendan's comment below.
See also "PWA validator" bookmarklet - #17
docs: install-to-homescreen on /web
Network Latency
150ms RTT
is a reasonable approximation for "typical mobile"500ms
(~85th percentile) would be a good approximation for "typical slow mobile"Network throughput
1.6Mbps
download throughput
Device Class
Nexus 5
for now.
emulateNetworkConditions
should be set for the page and SWsetCPUThrottlingRate
can help us approximate.
Detect whether a site is using CSP rules. If no unsafe
rules exist then say the site is using good CSP values. If an unsafe rule does exist, then warn that there could be possible issues with the policy being enforced.
Sound like a good audit to add?
old tests will need to be converted:
npm uninstall --save-dev chai
What should an audit return for statuses like "test not applicable" or "metric couldn't be computed", etc?
It's not reporting a test failure, nor a runtime exception.. @samccone recommended a result.fault
state, which is what i tried out here
thoughts?
Ideally, the first paint where the user feels that the primary content is visible
This means paints with only the topnav don't qualify. Any primary text must be visible (and not waiting for fonts). If an image is critical to the page (e.g. e-commerce product page), then first meaningful paint requires it to be visible.
Manual evaluation: Network Tab in DevTools timeline. Reload with screenshots/filmstrip enabled. Select the first screenshot with a meaningful view.
swapBuffers
from GPU/browser threads.Problem with apps that send different responses based on User-Agent.
app/manifest.json
isn't called with device mode on as it is called in the scope of the extension without device mode on. So user agent check kicks in sends no manifest for desktop. And this fails all the checks depending on manifest.Any ideas ?
The one in CWS is still based on the gist. Been a while, but I think the state of the master is good enough for CWS.
Right now it looks like it might be an auditing tool?
Komoroske brought this up during review.
To manage expectations, we need to point people to this repo and indicate things are still in development
I think it'd make most sense to do this on our side. That'd also allow us to handle the err in a generalized fashion.
@brendankenny and I were discussing how this would help the ergonomics of development some so we have a unified async structure.
I'm unsure on priority of improving this vs getting a few more tests written. Thoughts?
Wondering if we should add this to both the root package.json and the extension, or just the extension. WDYT?
@samccone is doing this now. Should have something that runs and reports the exact same thing quite soon.
I'll do this when my current PRs are merged or closed.
(orig reported at #73 )
We can probably just use some basic bash hackery of if hash chromium 2>/dev/null
etc etc.
It feels like the audits are a bit unwieldy as classes. I was curious what they'd look like a bit more nude..
Here's a before and after:
(I've removed annotations from both, as they're particularly nasty for audits.)
@paullewis I spoke to you briefly about this and I believe you weren't sold on it. I'm in no rush, but curious what you and others think.
Capturing how available the main thread is. This is a proxy metric to for potential input latency, as we cannot predict when input will hit the browser.
Timestamp: Main thread ready for interaction
in #27S-curve handled by Ben's math. Basic expectations:
Currently we: 1) get all SW registrations 2) filter to to see we have any in an "activated" state. This is good for right now, but it doesn't yet verify that offline caching provided via Service Worker
and it successfully page loads while offline. That'll be the next phase of this test.
Manual evaluation: Flip page offline via DevTools network throttling. Try it out
Something like this…
Afaik on the Android homescreen, if a short_name
contains too many characters it will be trimmed to something like My Totally Awesome App -> My Totally Awe...
. It may be useful to check the spec or with Mounir regarding expected lengths for these app names and whether flagging this via Lighthouse makes sense.
I've personally run into issues with needing to manually test this on-device (or rethink the names used) to avoid truncating, so throwing the idea out there.
A few audits rely on a parsedManifest..
report errors in parsing to user
Requirement: All assets served on HTTPS
Manual evaluation: Look at DevTools security panel to verify no problems, all green.
We merge the two: LighthouseLite (#37) and Lighthouse-core.
and drop into gatherers/theme-color.js
just pull out
lighthouse/helpers/manifest-parser.js
Line 77 in 0042483
Time 'To Interactive (or TTI) is a classic success metric across the web, games and application development. We're attempting to provide a robust version of it for the web platform.
Updated: April 6, 2016
There are two major timestamps, composed of smaller ones:
Visually ready is the Math.max() of these timestamps:
DOMContentLoaded
+ top frame's images (who started before DCL) are loaded (IMO, we should use this one)
font-awesome
?Once visually ready has hit, we begin considering thread availability.
requestIdleCallback
for deadlines
@skyostil added: "it's super hard to congest the compositor, but a fair indicator will be availability of time on main thread because a) a lot of work will be main-thread bound and b) CPU contention (he thinks) can sometimes block the compositor from allowing scroll."
@paullewis added: "some of this may be in our wording where we explain that we're treating main thread as a proxy for interactivity"
touchstart
, etc) the same as ones without?navigationStart
─⇥ visually readynavigationStart
─⇥ thread readyAt the moment viewport audit is running a regex over the entire html. It would be useful for this (and future audits) to seperate the body and the head as inputs. The other alternative would be to have these as gathers, but that feels like it wouldn't be as flexible.
Thoughts on having input.html + input.head + html body?
Calling requestAppBanner
will fetch the manifest, which we can pick up in the network requests record.
This avoids the DOM dance and make sure we're testing the same manifest that Chrome does.
for now you need --enable-add-to-shelf
for this to work
Manual evaluation: manifest has theme_color
, <head>
has <meta name="theme-color" content="_any valid CSS color_">
theme_color
.document.head
for the theme-color
meta.Currently both are required. Chrome will be transitioning to use manifest theme-color by default: go/fizz-feature-backlog has a tracking item for this.
See also "PWA validator" bookmarklet - #17
Docs: Support for theme-color in Chrome 39 for Android, and whatwg/meta-theme-color: Spec for the theme-color
meta extension
const LIFECYCLE = {
InititalBinding: 1,
BeforePageload: 2,
AfterPageLoad: 3,
AtRest: 4,
…
class Thingthing extends Gather {
static gather(opts) {
driver.waitFor(LIFECYCLE.BeforePageload)
.then(_ => …)
.then(_ => …)
.then(_ => driver.waitFor(LIFECYCLE.AtRest)
.then(_ => …)
Disclaimer: All the names are definitely wrong.
But that said, I'm thinking this seems a nice way of managing scheduling of all gather work, so we don't step on toes and minimize repetitive work.
All gathers MUST start with a waitFor
. It's possible they have a second.
Thoughts?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.