add moar lighthouse references

src/content/en/tools/lighthouse/_toc.yaml

@@ -7,13 +7,29 @@ toc:
       section:
       - title: Cache Contains start_url From Manifest
         path: /web/tools/lighthouse/audits/cache-contains-start_url
-      - title: URL Responds with a 200 When Offline
-        path: /web/tools/lighthouse/audits/http-200-when-offline
+      - title: Content Size Correctly for Viewport
+        path: /web/tools/lighthouse/audits/content-sized-correctly-for-viewport
+      - title: Critical Request Chains
+        path: /web/tools/lighthouse/audits/critical-request-chains
+      - title: Estimated Input Latency
+        path: /web/tools/lighthouse/audits/estimated-input-latency
+      - title: First Meaningful Paint
+        path: /web/tools/lighthouse/audits/first-meaningful-paint
+      - title: Has a Registered Service Worker
+        path: /web/tools/lighthouse/audits/registered-service-worker
+      - title: HTML Has Viewport Meta Tag
+        path: /web/tools/lighthouse/audits/has-viewport-meta-tag
+      - title: Page Contains Some Content When Its Scripts Are Not Available
+        path: /web/tools/lighthouse/audits/no-js
       - title: Site Redirects HTTP Traffic to HTTPS
         path: /web/tools/lighthouse/audits/http-redirects-to-https
       - title: Site is on HTTPS
         path: /web/tools/lighthouse/audits/https
-      - title: Page Contains Some Content When Its Scripts Are Not Available
-        path: /web/tools/lighthouse/audits/no-js
-      - title: Has a Registered Service Worker
-        path: /web/tools/lighthouse/audits/registered-service-worker
+      - title: Speed Index
+        path: /web/tools/lighthouse/audits/speed-index
+      - title: Time to Interactive
+        path: /web/tools/lighthouse/audits/time-to-interactive
+      - title: URL Responds with a 200 When Offline
+        path: /web/tools/lighthouse/audits/http-200-when-offline
+      - title: User Timing Marks and Measures
+        path: /web/tools/lighthouse/audits/user-timing

src/content/en/tools/lighthouse/audits/content-sized-correctly-for-viewport.md

@@ -0,0 +1,35 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "Content Sized Correctly for Viewport" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-04 #}
+{# wf_published_on: 2016-10-04 #}
+
+# Content Sized Correctly for Viewport  {: .page-title }
+
+## Why the audit is important {: #why }
+
+This audit checks that the width of the content on your page is equal
+to the width of the viewport. When content width is smaller or larger than
+viewport width, that's often a cue that the page is not optimized for
+mobile screens.
+
+## How to pass the audit {: #how }
+
+This audit is a roundabout way of determining if your page is optimized for
+mobile devices. If your site is not optimized and you want it to be, then see
+[Responsive Web Design Basics](/web/fundamentals/design-and-ui/responsive/)
+to get started.
+
+You can ignore this audit if:
+
+* Your site does not need to be optimized for mobile screens.
+* The content width of your page is intentionally smaller or larger than the
+  viewport width.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+The audit passes if `window.innerWidth === window.outerWidth`.

src/content/en/tools/lighthouse/audits/critical-request-chains.md

@@ -0,0 +1,74 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "Critical Request Chains" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-06 #}
+{# wf_published_on: 2016-10-06 #}
+
+# Critical Request Chains  {: .page-title }
+
+## Why the audit is important {: #why }
+
+The Critical Request Chain is a concept from the Critical Rendering Path (CRP)
+optimization strategy. CRP enables the browser to load a page as quickly as
+possible by prioritizing which resources get loaded and the order in which
+they load.
+
+Check out the [Critical Rendering
+Path](/web/fundamentals/performance/critical-rendering-path/) docs to learn
+more.
+
+## How to pass the audit {: #how }
+
+This audit is currently not structured as something to "pass" or "fail". The
+information that this audit provides gives you an opportunity to improve
+the page load performance of your app.
+
+In the Chrome Extension version of Lighthouse, your report generates a diagram
+like the following:
+
+```
+Initial navigation
+|---lighthouse/ (developers.google.com)
+    |---/css (fonts.googleapis.com) - 1058.34ms, 72.80KB
+    |---css/devsite-googler-buttons.css (developers.google.com) - 1147.25ms, 70.77KB
+    |---jsi18n/ (developers.google.com) - 1155.12ms, 71.20KB
+    |---css/devsite-google-blue.css (developers.google.com) - 2034.57ms, 85.83KB
+    |---2.2.0/jquery.min.js (ajax.googleapis.com) - 2699.55ms, 99.92KB
+    |---contributors/kaycebasques.jpg (developers.google.com) - 2841.54ms, 84.74KB
+    |---MC30SXJEli4/photo.jpg (lh3.googleusercontent.com) - 3200.39ms, 73.59KB
+```
+
+This diagram represents the page's critical request chains. The path from
+`lighthouse/` to `/css` is one chain. The path from `lighthouse/` to
+`css/devsite-googler-buttons.css` is another chain. And so on. The top-most
+score of the audit represents this number of chains. For example, the diagram
+above would have a "score" of seven.
+
+The diagram also breaks down how much time was spent downloading each
+resource, and the number of bytes that was required to download each resource.
+
+You can use this diagram to improve your CRP by:
+
+* Minimizing the number of critical resources: eliminating them, deferring
+  their download, marking them as async, and so on.
+* Optimizing the number of critical bytes to reduce the download time (number
+  of roundtrips).
+* Optimizing the order in which the remaining critical resources are loaded:
+  downloading all critical assets as early as possible to shorten the critical
+  path length.
+
+Optimizing any of these factors results in a faster page load.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+Lighthouse uses network priority as a proxy for identifying render-blocking
+critical resources. See [Chrome Resource Priorities and
+Scheduling](https://docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwNFiEP4TZS-YLRp_RuMlc)
+for more information on how Chrome defines these priorities.
+
+Data on critical request chains, resource sizes, and time spent downloading
+resources is extracted from the Chrome Debugger Protocol.

src/content/en/tools/lighthouse/audits/estimated-input-latency.md

@@ -0,0 +1,59 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "Estimated Input Latency" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-05 #}
+{# wf_published_on: 2016-10-05 #}
+
+# Estimated Input Latency  {: .page-title }
+
+## Why the audit is important {: #why }
+
+Input responsiveness is a key factor in how users perceive the performance
+of your app. Apps have 100ms to respond to user input. Any longer than that,
+and the user perceives the app as laggy. See [Measure Performance with the RAIL
+Model](/web/fundamentals/performance/rail) for more information.
+
+See the [What the audit tests for](#what) section of this doc for an
+explanation of why this audit tests for a target score of 50ms (rather than
+100ms, which is what the RAIL model recommends).
+
+## How to pass the audit {: #how }
+
+To make your app respond to user input faster, you need to optimize how
+your code runs in the browser. Check out the series of techniques outlined
+in the [Rendering Performance](/web/fundamentals/performance/rendering/)
+docs. These tips range from offloading computation to web workers in order
+to free up the main thread, to refactoring your CSS selectors to perform
+less calculations, to using CSS properties that minimize the amount of
+browser-intensive operations.
+
+One important caveat of this audit is that it's not a complete measurement of
+input latency. As explained in the [What this doc tests for](#what) section
+of this doc, this audit does not measure how long your app truly takes
+to respond to a user input. In other words, it does not measure that your app's
+response to the user's input is visually complete.
+
+To measure this manually, make a recording with the
+Chrome DevTools Timeline. See [How to use the Timeline
+Tool](/web/tools/chrome-devtools/evaluate-performance/timeline-tool) for more
+help. The basic idea is to start a recording, perform the user input that
+you want to measure, stop the recording, and then analyze the flame chart
+to ensure that all stages of [the pixel
+pipeline](/web/fundamentals/performance/rendering/#the_pixel_pipeline) are
+complete within 50ms.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+The RAIL performance model recommends that apps respond to user input within
+100ms, whereas Lighthouse's target score is 50ms. Why? 
+
+The reason is that Lighthouse uses a proxy metric to measure how well your
+app responds to user input: availability of the main thread. Lighthouse
+assumes that your app needs 50ms to completely respond to the user's input
+(from performing any JavaScript executions to physically painting the new
+pixels to the screen). If your main thread is unavailable for 50ms or more,
+that does not leave enough time for your app to complete the response.

src/content/en/tools/lighthouse/audits/first-meaningful-paint.md

@@ -0,0 +1,34 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "First Meaningful Paint" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-05 #}
+{# wf_published_on: 2016-10-05 #}
+
+# First Meaningful Paint {: .page-title }
+
+## Why the audit is important {: #why }
+
+Page load is a key aspect of how a user perceives the performance of your
+page. See [Measure Performance with the RAIL Method](/web/fundamentals/performance/rail) for more information.
+
+This audit identifies the time at which the user feels that the primary
+content of the page is visible. 
+
+## How to pass the audit {: #how }
+
+The lower your First Meaningful Paint score, the faster that the page
+appears to display its primary content.
+
+[Optimizing the Critical Rendering Path](/web/fundamentals/performance/critical-rendering-path/)
+is particularly helpful towards achieving a faster First Meaningful Paint.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+First Meaningful Paint is essentially the paint after which the biggest
+above-the-fold layout change has happened, and web fonts have loaded. See the
+spec to learn more:
+[First Meaningful Paint: A Layout-Based Aproach](https://docs.google.com/document/d/1BR94tJdZLsin5poeet0XoTW60M0SjvOJQttKT-JK8HI/view).

src/content/en/tools/lighthouse/audits/has-viewport-meta-tag.md

@@ -0,0 +1,43 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "HTML Has a Viewport Meta Tag" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-04 #}
+{# wf_published_on: 2016-10-04 #}
+
+# HTML Has a Viewport Meta Tag {: .page-title }
+
+## Why the audit is important {: #why }
+
+Without a viewport meta tag, mobile devices render pages at typical desktop
+screen widths, and then scale the pages to fit the mobile screens. Setting
+the viewport enables you to control the width and scaling of the viewport.
+Check out the following links to learn more:
+
+* [Configure the Viewport](/speed/docs/insights/ConfigureViewport).
+* [Set the Viewport](/web/fundamentals/design-and-ui/responsive/#set-the-viewport).
+
+## How to pass the audit {: #how }
+
+Add a viewport `<meta>` tag in the `<head>` of your HTML.
+
+    <head>
+      ...
+      <meta name="viewport" content="width=device-width, initial-scale=1">
+      ...
+    </head>
+
+The `width=device-width` key-value pair sets the width of the viewport to
+the width of the device. The `initial-scale=1` key-value pair sets the initial
+zoom level when visiting the page.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+Lighthouse checks that there's a `<meta name="viewport">` tag in the `<head>`
+of the document. It also checks that the node contains a `content` attribute
+and that the value of this attribute contains the text `width=`. However,
+it does not check that `width` equals `device-width`. Lighthouse also does not
+check for a `initial-scale` key-value pair.

src/content/en/tools/lighthouse/audits/speed-index.md

@@ -0,0 +1,38 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "Speed Index" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-04 #}
+{# wf_published_on: 2016-10-04 #}
+
+# Speed Index  {: .page-title }
+
+## Why the audit is important {: #why }
+
+Speed Index is a page load performance metric that shows you how quickly
+the contents of a page are visibly populated. The lower the score, the better.
+
+## How to pass the audit {: #how }
+
+To lower your Speed Index score, you need to optimize your page to visually
+load faster. Two good starting places are:
+
+* [Optimizing Content Efficiency](/web/fundamentals/performance/optimizing-content-efficiency/).
+* [Optimizing the Critical Rendering Path](/web/fundamentals/performance/critical-rendering-path/).
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+Lighthouse uses a node module called 
+[Speedline](https://github.com/pmdartus/speedline)
+to generate the Speed Index score.
+
+For more information on the algorithms and methodologies behind Speed Index,
+see [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index).
+
+The target score is computed by a cumulative distribution function of a
+log-normal distribution. Check out the comments in the
+[source](https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/audits/speed-index-metric.js)
+of the audit if you need to know more.

src/content/en/tools/lighthouse/audits/time-to-interactive.md

@@ -0,0 +1,33 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "Time to Interactive" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-05 #}
+{# wf_published_on: 2016-10-05 #}
+
+# Time to Interactive  {: .page-title }
+
+## Why the audit is important {: #why }
+
+Page load is a key aspect of how a user perceives the performance of your
+page. See [Measure Performance with the RAIL Method](/web/fundamentals/performance/rail) for more information.
+
+This audit identifies the time at which a page appears to be ready enough that
+a user can interact with it.
+
+## How to pass the audit {: #how }
+
+Check out the resources in the [How to pass the audit](speed-index#how) section
+of the Speed Index audit for more help on improving page load performance.
+The lower your Time to Interactive score, the better.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+Time to Interactive is defined as the point at which layout has stabilized,
+key webfonts are visible, and the main thread is available enough to handle
+user input. 
+
+Note that this metric is in early phases and is subject to change.

src/content/en/tools/lighthouse/audits/user-timing.md

@@ -0,0 +1,38 @@
+project_path: /web/_project.yaml
+book_path: /web/tools/_book.yaml
+description: Reference documentation for the "User Timing Marks and Measures" Lighthouse audit.
+
+{# wf_updated_on: 2016-10-06 #}
+{# wf_published_on: 2016-10-06 #}
+
+# User Timing Marks and Measures  {: .page-title }
+
+## Why the audit is important {: #why }
+
+The User Timing API enables you to measure your app's JavaScript performance.
+The basic idea is that you decide which parts of your scripts you want to
+optimize, and then you instrument those parts of your scripts with the User
+Timing API. From there, you can access the results from JavaScript using the
+API, or view them on your [Chrome DevTools Timeline
+Recordings](/web/tools/chrome-devtools/evaluate-performance/timeline-tool).
+
+## How to pass the audit {: #how }
+
+This audit is not structured as a "pass" or "fail" test. It's just an
+opportunity to discover a useful API that can aid you in measuring your app's
+performance. The score that Lighthouse reports for this audit corresponds to the
+number of User Timing Marks and Measures that it finds in your app.
+
+When your app does include User Timing Marks and Measures, you'll see these
+Marks and Measures in your Lighthouse report.
+
+Check out [User Timing API](https://www.html5rocks.com/en/tutorials/webperformance/usertiming/)
+for an introduction on using the User Timing API to measure your app's
+JavaScript performance.
+
+## What the audit tests for {: #what }
+
+*Use this information to determine if the audit is relevant to your needs
+or is returning incorrect results.*
+
+Lighthouse extracts User Timing data from Chrome's Trace Event Profiling Tool.