Merge pull request #67 from stoyan/brand

Consistent capitalization of WebPageTest

Author: tkadlec

src/_includes/layouts/index.njk

@@ -23,7 +23,7 @@
             <div>
                 <img class="hero" src="/img/custom-metrics-teaser.png" alt="">
                 <h2>Capturing Custom Metrics</h2>
-                <p>WebPagetest can execute arbitrary JavaScript at the end of a test, enabling a wide variety of custom defined metrics.</p>
+                <p>WebPageTest can execute arbitrary JavaScript at the end of a test, enabling a wide variety of custom defined metrics.</p>
                 <p><a href="/custom-metrics" class="btn">Learn about Custom Metrics →</a></p>
                 </div>
         </div>

src/custom-metrics/index.md

@@ -6,7 +6,7 @@ eleventyNavigation:
 ---
 # Custom Metrics
 
-WebPagetest can execute arbitrary javascript at the end of a test to collect custom metrics.  These can be defined statically in the server configuration or be specified at runtime on a per-test basis.
+WebPageTest can execute arbitrary javascript at the end of a test to collect custom metrics.  These can be defined statically in the server configuration or be specified at runtime on a per-test basis.
 
 ::: note
 [The HTTP Archive](https://httparchive.org/) uses WebPageTest custom metrics to power their reports, as well as the analysis in the [annual Web Almanac](https://almanac.httparchive.org/). The metrics are all available in a [public GitHub repository](https://github.com/HTTPArchive/custom-metrics) if you would like to dig in and get some ideas for what's possible.

src/dev/System Design/mobile_testing.md

@@ -6,7 +6,7 @@ For mobile testing you have a few options for network connectivity:
 * WiFi with no traffic shaping
 * WiFi with a fixed traffic shaping profile
 * WiFi with per-test traffic shaping
-This is what the mobile testing network looks like for the public instance of WebPagetest (at least as of this writing in 2014):
+This is what the mobile testing network looks like for the public instance of WebPageTest (at least as of this writing in 2014):
 
 ![Network Diagram](/img/mobile_testing.png)
 
@@ -23,7 +23,7 @@ For Windows there is also a support application adbwatch that watches adb and if
 
 The public instance currently has 10 devices connected to an Intel i5 NUC running Windows 7 with adbwatch managing the agent instances and keeping adb running.  One tip for running the NUC's as headless servers (for the newer haswell models that do not support AMT) is to use VNC and the Microsoft video drivers shipped with Windows, not the Intel ones.  If you use the Intel drivers the display will be disabled and VNC will not work.
 
-The data flow for test results and agent <-> WebPagetest server communication all happen from the tethered host so the only use of the data connection will be the actual test data (and any software updates).
+The data flow for test results and agent <-> WebPageTest server communication all happen from the tethered host so the only use of the data connection will be the actual test data (and any software updates).
 
 ## WiFi with no traffic shaping
 Testing over a WiFi connection gives you much more control over the stability of the results and usually produces much more consistent results than testing on a carrier network.  The main issues with running a stable WiFi test connection are:

src/dev/System Design/overview.md

@@ -1,7 +1,7 @@
 # Overview
 Note: These docs are outdated and parts reference the old agent architecture
 
-Here is the overall system design for WebPagetest:
+Here is the overall system design for WebPageTest:
 
 ![Overview](/img/overview.png)
 

src/getting-started.md

@@ -5,21 +5,21 @@ eleventyNavigation:
 ---
 
 # Quick Start Guide
-At its core, WebPagetest is used for measuring and analyzing the performance of web pages.  There are a lot of options that may seem intimidating at first but doing quick testing is pretty simple.  This guide will walk you through submitting a test and interpreting the results.
+At its core, WebPageTest is used for measuring and analyzing the performance of web pages.  There are a lot of options that may seem intimidating at first but doing quick testing is pretty simple.  This guide will walk you through submitting a test and interpreting the results.
 
 ## Running a Performance Test
 ### 1. Enter The Page URL:
-The first thing you need to do is decide on a page to test.  Most people start with the main page for their site (but don't neglect the other pages people visit either).  Once you have decided on a page you'd like to test you go to WebPagetest and give it the URL for the page you want tested:
+The first thing you need to do is decide on a page to test.  Most people start with the main page for their site (but don't neglect the other pages people visit either).  Once you have decided on a page you'd like to test you go to WebPageTest and give it the URL for the page you want tested:
 
 ![](/img/qs_url.png)
 
 ### 2. Select a Location:
-Next you should decide where you want the test to be run from.  WebPagetest has test machines that are physically located around the world and you should test from a location that is close to where your users are visiting from.  You can either pick a location from the list or if you click on the Change button you can pick a location from a map view (just click on a balloon to select a location and then click ok).  If you hold the pointer over the bubbles they will display a message telling you where the location is:
+Next you should decide where you want the test to be run from.  WebPageTest has test machines that are physically located around the world and you should test from a location that is close to where your users are visiting from.  You can either pick a location from the list or if you click on the Change button you can pick a location from a map view (just click on a balloon to select a location and then click ok).  If you hold the pointer over the bubbles they will display a message telling you where the location is:
 
 ![](/img/qs_map.png)
 
 ### 3. Select a Browser:
-Finally, you need to decide what browser to use for the test.  Different locations support different browsers so if a given location doesn't have the browser you are looking for, you can try a different location.  The Dulles, VA USA location supports all of the browsers that WebPagetest works with (Chrome, Firefox, Edge, Internet Explorer, Android, iOS).  We usually recommend using Chrome for initial testing because it has the most information reported.
+Finally, you need to decide what browser to use for the test.  Different locations support different browsers so if a given location doesn't have the browser you are looking for, you can try a different location.  The Dulles, VA USA location supports all of the browsers that WebPageTest works with (Chrome, Firefox, Edge, Internet Explorer, Android, iOS).  We usually recommend using Chrome for initial testing because it has the most information reported.
 
 ![](/img/qs_browser.png)
 

src/metrics/SpeedIndex.md

@@ -7,12 +7,12 @@ eleventyNavigation:
 # Speed Index
 The Speed Index is the average time at which visible parts of the page are displayed.  It is expressed in milliseconds and dependent on size of the view port.
 
-The Speed Index metric was added to WebPagetest in April, 2012 and measures how quickly the page contents are visually populated (where lower numbers are better).  It is particularly useful for comparing experiences of pages against each other (before/after optimizing, my site vs competitor, etc) and should be used in combination with the other metrics (load time, start render, etc) to better understand a site's performance.
+The Speed Index metric was added to WebPageTest in April, 2012 and measures how quickly the page contents are visually populated (where lower numbers are better).  It is particularly useful for comparing experiences of pages against each other (before/after optimizing, my site vs competitor, etc) and should be used in combination with the other metrics (load time, start render, etc) to better understand a site's performance.
 
 ## The Problem
 Historically we have relied on milestone timings to determine how fast or slow web pages were.  The most common of these is the time until the browser reaches the load event for the main document (onload).  The load event is easy to measure both in a lab environment and in the real world.  Unfortunately, it isn't a very good indicator of the actual end-user experience.  As pages grow and load a lot of content that is not visible to the user or off the screen (below the fold) the time to reach the load event is extended even if the user-visible content has long-since rendered.  We have introduced more milestones over time to try to better represent the timings (time to first paint, time to DOM content ready, etc) but they are all fundamentally flawed in that they measure a single point and do not convey the actual user experience.
 ## Introducing the Speed Index
-The speed index takes the visual progress of the visible page loading and computes an overall score for how quickly the content painted.  To do this, first it needs to be able to calculate how "complete" the page is at various points in time during the page load.  In WebPagetest this is done by capturing a video of the page loading in the browser and inspecting each video frame (10 frames per second in the current implementation and only works for tests where video capture is enabled).  The current algorithm for calculating the completeness of each frame is described below, but for now assume we can assign each video frame a % complete (numbers displayed under each frame):
+The speed index takes the visual progress of the visible page loading and computes an overall score for how quickly the content painted.  To do this, first it needs to be able to calculate how "complete" the page is at various points in time during the page load.  In WebPageTest this is done by capturing a video of the page loading in the browser and inspecting each video frame (10 frames per second in the current implementation and only works for tests where video capture is enabled).  The current algorithm for calculating the completeness of each frame is described below, but for now assume we can assign each video frame a % complete (numbers displayed under each frame):
 
 ![](/img/si_compare_progress.png)
 

src/private-instances/ec2_agents.md

@@ -22,7 +22,7 @@ The configuration of the test agents is done through user data strings when inst
 
 ## Parameters
 
-* **wpt_server** - the web server where WebPagetest is running
+* **wpt_server** - the web server where WebPageTest is running
 * **wpt_url** - (optional in place of wpt_server) Base URL to the work directory for fetching.  i.e. https://www.webpagetest.org/work/
 * **wpt_loc** - The location ID (if not specified it will fall back to wpt_location or be built from the region - ec2-us-east for example)
 * **wpt_key** - secret key for the specified location

src/private-instances/gce_agents.md

@@ -24,7 +24,7 @@ The agents are configured through a metadata string with the name "wpt_data":
 
 ### Parameters
 
-* **wpt_server** - the web server where WebPagetest is running
+* **wpt_server** - the web server where WebPageTest is running
 * **wpt_url** - (optional in place of wpt_server) Base URL to the work directory for fetching.  i.e. https://www.webpagetest.org/work/
 * **wpt_loc** - The location ID (if not specified it will fall back to wpt_location or be built from the region - ec2-us-east for example)
 * **wpt_key** - secret key for the specified location

src/user/2011 FCC Broadband Data.md

@@ -2,7 +2,7 @@
 The FCC prepared a report on the state of Broadband Internet access in the US and the data is useful for deciding on connectivity parameters used for testing.  I'm including the key charts here but the full report is available here: http://www.fcc.gov/document/measuring-broadband-america-report-consumer-broadband-performance-us
 
 ## Connectivity Emulation (dummynet)
-The purpose of the connectivity emulation in WebPagetest is to provide realistic "last mile" performance from the test agents (but not to alter additional latency in getting to servers physically distributed).  This means that the goal is to realistically emulate parts 2-6 of the network diagram from the FCC report with the public Internet segment being routed as it would normally:
+The purpose of the connectivity emulation in WebPageTest is to provide realistic "last mile" performance from the test agents (but not to alter additional latency in getting to servers physically distributed).  This means that the goal is to realistically emulate parts 2-6 of the network diagram from the FCC report with the public Internet segment being routed as it would normally:
 
 ![FCC Network diagram](/img/fcc_net.png)