Fix typos and other small issues in speed documentation.

docs/speed/addressing_performance_regressions.md

 # Addressing Performance Regressions
 
 The bisect bot just picked your CL as the culprit in a performance regression
 and assigned a bug to you! What should you do? Read on...
 
+[TOC]
+
 ## About our performance tests
 
 The [chromium.perf waterfall](perf_waterfall.md) is a continuous build which
 runs performance tests on dozens of devices across Windows, Mac, Linux, and
 Android Chrome and WebView. Often, a performance regression only affects a
 certain type of hardware or a certain operating system, which may be different
 than what you tested locally before landing your CL.
 
 Each test has an owner, named in
-[this spreasheet](https://docs.google.com/spreadsheets/d/1xaAo0_SU3iDfGdqDJZX_jRV0QtkufwHUKH3kQKF3YQs/edit#gid=0),
+[this spreadsheet](https://docs.google.com/spreadsheets/d/1xaAo0_SU3iDfGdqDJZX_jRV0QtkufwHUKH3kQKF3YQs/edit#gid=0),
 who you can cc on a performance bug if you have questions.
 
 ## Understanding the bisect results
 
 The bisect bot spits out a comment on the bug that looks like this:
 
 ```
 === BISECT JOB RESULTS ===
 Perf regression found with culprit
 
@@ skipping 28 matching lines @@
   * **What regressed exactly?** The comment gives you several details:
     * **The benchmark that regressed**: Under `Bisect Details`, you can see
       `Benchmark :`. In this case, the `system_health.common_desktop`
       benchmark regressed.
     * **What platform did it regress on?** Under `Configuration`, you can find
       some details on the bot that regressed. In this example, it is a Mac Pro
       laptop.
     * **How do I run that locally?** Follow the instructions under
       `To Run This Test`. But be aware that if it regressed on Android and
       you're developing on Windows, you may not be able to reproduce locally.
-      (See Debugging regressions below)
+      (See [Debugging regressions](#Debugging-regressions) below)
     * **What is this testing?** Generally the metric
       (`timeToFirstContentfulPaint_avg`) gives some information. If you're not
       familiar, you can cc the [benchmark owner](https://docs.google.com/spreadsheets/d/1xaAo0_SU3iDfGdqDJZX_jRV0QtkufwHUKH3kQKF3YQs/edit#gid=0)
       to ask for help.
     * **How severe is this regression?** There are different axes on which to
       answer that question:
       * **How much did performance regress?** The bisect bot answers this both
         in relative terms (`Change : 15.25%`) and absolute terms
         (`1010.02 -> 1164.04`). To understand the absolute terms, you'll need
         to look at the units on the performance graphs linked in comment #1
@@ skipping 96 matching lines @@
       entering the commit position of a change into this url:
       `https://chromeperf.appspot.com/group_report?rev=YOUR_COMMIT_POS_HERE`
       All of these changes are generally changes found on a CL range, and may
       not be attributable to your CL. You can bisect any of these to find if
       your CL caused the improvement, just like you can bisect to find if it
       caused the regression.
     * **Use finch trial results.** There are some types of changes that cannot
       be measured well in benchmarks. If you believe your case falls into this
       category, you can show that end users are not affected via a finch trial.
       See the "End-user metrics" section of
-      [How does Chrome measure performance](how_does_chrome_measure_performance.md)
+      [How Chrome measures performance](how_does_chrome_measure_performance.md#End_user-metrics)
   * **Your change is a critical correctness or security fix.**
     It's true that sometimes something was "fast" because it was implemented
     incorrectly. In this case, a justification should clarify the performance
     cost we are paying for the fix and why it is worth it. Some things to
     include:
     * **What did the benchmark regression cost?** Look at the
       list of regressions in bug comment 1:
       `https://chromeperf.appspot.com/group_report?bug_id=XXXX`
       What is the absolute cost (5MiB RAM? 200ms on page load?)
       How many pages regressed? How many platforms?
@@ skipping 13 matching lines @@
     possible that your change did not regress performance, and only appears to
     be a problem because the test is measuring incorrectly. If this is the
     case, you must explain clearly what the issue with the test is, and why you
     believe your change is performance neutral. Please include data from traces
     or other performance tools to clarify your claim.
 
 **In all cases,** make sure to cc the [benchmark owner](https://docs.google.com/spreadsheets/d/1xaAo0_SU3iDfGdqDJZX_jRV0QtkufwHUKH3kQKF3YQs/edit#gid=0)
 when writing a justification and WontFix-ing a bug. If you cannot come to an
 agreement with the benchmark owner, you can escalate to benhenry@chromium.org,
 the owner of speed releasing.