Spell checks part 2 (#1704)

* Spell checks part 2 * Fix Lighthouse issues
HTTPArchive · Dec 9, 2020 · 504c9f6 · 504c9f6
1 parent 480acbb
commit 504c9f6
Show file tree

Hide file tree

Showing 10 changed files with 229 additions and 99 deletions.
diff --git a/src/config/spelling_ignore_words.txt b/src/config/spelling_ignore_words.txt
diff --git a/src/content/en/2019/accessibility.md b/src/content/en/2019/accessibility.md
@@ -15,7 +15,7 @@ obto_bio: David Fox is the lead usability researcher and founder of LookZook, a
 kleinab_bio: Abigail Klein is a Google software engineer. She worked on Google Docs, Sheets, and Slides web accessibility where she added <a href="https://www.blog.google/outreach-initiatives/accessibility/whats-you-say-present-captions-google-slides/">automatic captions to Google Slides</a>, as well as improving screen reader, braille, screen magnifier, and high contrast support. She currently works on Google Chrome and ChromeOS accessibility. She has a bachelor's and master's degree in computer science from MIT, where she co-founded an assistive technology hackathon and was a lab assistant and guest lecturer of the assistive technology class.
 featured_quote: Accessibility on the web is essential for an inclusive and equitable society. As more of our social and work lives move to the online world, it becomes even more important for people with disabilities to be able to participate in all online interactions without barriers. Just as building architects can create or omit accessibility features such as wheelchair ramps, web developers can help or hinder the assistive technology users rely on.
 featured_stat_1: 22%
-featured_stat_label_1: Sites using sufficient colour contrast
+featured_stat_label_1: Sites using sufficient color contrast
 featured_stat_2: 50%
 featured_stat_label_2: Sites with missing image alt attributes
 featured_stat_3: 14%

diff --git a/src/content/en/2020/accessibility.md b/src/content/en/2020/accessibility.md
diff --git a/src/content/en/2020/compression.md b/src/content/en/2020/compression.md
@@ -63,10 +63,10 @@ There are two ways of doing the compression on the server side:
   - Dynamically Compressed (compress assets on-the-fly after a request is made)
 
 Since precompression is done beforehand, we can spend more time compressing the assets. For dynamically compressed resources we need to choose the compression levels such that compression takes less time than time difference between sending an uncompressed versus a compressed file. Currently practically all text compression is done by one of two HTTP content encodings: [Gzip](https://tools.ietf.org/html/rfc1952) and [brotli](https://github.com/google/brotli). Both are widely supported by browsers: [can I use brotli](https://caniuse.com/?search=brotli)/[can I use gzip](https://caniuse.com/?search=gzip)
-When you want to use gzip, consider using [Zopfli](https://en.wikipedia.org/wiki/Zopfli), which generates smaller gzip compatible files. This should be done especially for precompressed resourses, since here the greatest [gains are expected](https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf) . See this [comparison between gzip and zopfli](https://blog.codinghorror.com/zopfli-optimization-literally-free-bandwidth/) that takes into account different compression levels for gzip.
+When you want to use gzip, consider using [Zopfli](https://en.wikipedia.org/wiki/Zopfli), which generates smaller gzip compatible files. This should be done especially for precompressed resources, since here the greatest [gains are expected](https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf) . See this [comparison between Gzip and Zopfli](https://blog.codinghorror.com/zopfli-optimization-literally-free-bandwidth/) that takes into account different compression levels for gzip.
 
 
-Many popular servers support dynamically and/or pre-compressed HTTP  (https://en.wikipedia.org/wiki/HTTP_compression#Servers_that_support_HTTP_compression) and many of them support Brotli: https://en.wikipedia.org/wiki/Brotli
+Many [popular servers support dynamically and/or pre-compressed HTTP](https://en.wikipedia.org/wiki/HTTP_compression#Servers_that_support_HTTP_compression) and many of them support [Brotli](https://en.wikipedia.org/wiki/Brotli)
 
 
 Here are some general recommendations on what compression levels to use:
@@ -84,7 +84,7 @@ Here are some general recommendations on what compression levels to use:
       <tr>
         <td>precompressed</td>
         <td>11</td>
-        <td>9 or zopfli</td>
+        <td>9 or Zopfli</td>
       </tr>
       <tr>
         <td>dynamically compressed</td>

diff --git a/src/content/en/2020/http2.md b/src/content/en/2020/http2.md
@@ -34,7 +34,7 @@ This chapter reviews the current state of HTTP/2 and gQUIC deployment. It explor
 
 As the HTTP protocol has evolved, the semantics of HTTP have stayed the same; there have been no changes to the HTTP methods (such as GET or POST), status codes (200, or the dreaded 404), URIs, or header fields. Where the HTTP protocol has changed, the differences have been the wire-encoding and the use of features of the underlying transport.
 
-HTTP/1.0, published in 1996, defined the text-based application protocol, allowing clients and servers to exchange messages in order to request resources. A new TCP connection was required for each request/response, which introduced overhead. TCP connections use a congestion control algorithm to maximise how much data can be in-flight. This process takes time for each new connection. This "slow-start" means that not all the available bandwidth is used immediately.
+HTTP/1.0, published in 1996, defined the text-based application protocol, allowing clients and servers to exchange messages in order to request resources. A new TCP connection was required for each request/response, which introduced overhead. TCP connections use a congestion control algorithm to maximize how much data can be in-flight. This process takes time for each new connection. This "slow-start" means that not all the available bandwidth is used immediately.
 
 In 1997, HTTP/1.1 was introduced to allow TCP connection reuse by adding "keep-alives", aimed at reducing the total cost of connection start-ups. Over time, increasing website performance expectations led to the need for concurrency of requests. HTTP/1.1 could only request another resource after the previous response had completed. Therefore, additional TCP connections had to be established, reducing the impact of the keep-alive connections and further increasing overhead.
 

diff --git a/src/content/en/2020/mobile-web.md b/src/content/en/2020/mobile-web.md
@@ -240,14 +240,14 @@ According to CrUX data, 60% of mobile sites and 54% of desktop sites, have a goo
 }}
 
 #### Design elements
-To engage users, it’s important to help them quickly find what they’re looking for, and fulfil their intention.
+To engage users, it’s important to help them quickly find what they’re looking for, and fulfill their intention.
 
 ##### Landing pages
 Simple design tweaks go a long way, for instance a clear call-to-action, and making the value proposition evident to the user, with a few words.
 
 {{ figure_markup(
   image="landing-page-cta.png",
-  caption='Four key parts of the Pixel phone landing page.<br>(Source: <a href="https://winonmobile.withgoogle.com">https://winonmobile.withgoogle.com</a>)',
+  caption='Four key parts of the Pixel phone landing page.<br>(Source: <a href="https://winonmobile.withgoogle.com">Google</a>)',
   description="An image breaking down the four parts of the Pixel phone landing page: Value proposition, Call-to-action, No distraction, Main services.",
   width=1200,
   height=642
@@ -261,7 +261,7 @@ Consider the following examples from [5 lessons Eastpak learned from its mobile
 
 {{ figure_markup(
   image="eastpak-20-ctr.png",
-  caption='Eastpak improving the color contrast of their main call to action lead to a 20% increase in click through rate.<br>(Source: <a href="https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/5-lessons-eastpak-learned-its-mobile-audience/">https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/5-lessons-eastpak-learned-its-mobile-audience/</a>)',
+  caption='Eastpak improving the color contrast of their main call to action lead to a 20% increase in click through rate.<br>(Source: <a href="https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/5-lessons-eastpak-learned-its-mobile-audience/">Google</a>)',
   description="An image showing how Eastpak increased their click through rate by 20% by improving the color contrast of their main call to action button",
   width=1094,
   height=1122
@@ -272,7 +272,7 @@ Here, a simple change from a button that’s hard to see, to a button with contr
 
 {{ figure_markup(
   image="eastpak-12-ctr.png",
-  caption='Eastpak improving the color contrast of their checkout button lead to a 12% increase in conversion rate.<br>(Source: <a href="https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/5-lessons-eastpak-learned-its-mobile-audience/">https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/5-lessons-eastpak-learned-its-mobile-audience/</a>)',
+  caption='Eastpak improving the color contrast of their checkout button lead to a 12% increase in conversion rate.<br>(Source: <a href="https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/5-lessons-eastpak-learned-its-mobile-audience/">Google</a>)',
   description="An image showing how Eastpak increased their conversion rate by 12% by improving the color contrast of their checkout button",
   width=1166,
   height=1102
@@ -326,7 +326,7 @@ A [case study with fashion website lyst.com](https://www.thinkwithgoogle.com/int
 {# TODO: Insert image: search input lyst.com #}
 {{ figure_markup(
   image="search-input-lyst.png",
-  caption='Replacing the search icon with a search box on lyst.com improved conversion rate by 13% on mobile and 43% on desktop.<br>(Source: <a href="https://www.thinkwithgoogle.com/intl/en-cee/marketing-strategies/data-and-measurement/lyst-increases-overall-conversion-rate-25-making-usability-improvements/">https://www.thinkwithgoogle.com/intl/en-cee/marketing-strategies/data-and-measurement/lyst-increases-overall-conversion-rate-25-making-usability-improvements/</a>)',
+  caption='Replacing the search icon with a search box on lyst.com improved conversion rate by 13% on mobile and 43% on desktop.<br>(Source: <a href="https://www.thinkwithgoogle.com/intl/en-cee/marketing-strategies/data-and-measurement/lyst-increases-overall-conversion-rate-25-making-usability-improvements/">Google</a>)',
   description="A graphic showing how lyst.com replaced the search icon on their website with a search box, and as a result saw their conversion rate increase by 13% on mobile and 43% on desktop",
   width=1194,
   height=1170

diff --git a/src/content/en/2020/page-weight.md b/src/content/en/2020/page-weight.md
@@ -130,15 +130,15 @@ We know that images are a great source of page weight. This graphic below shows
 
 ## COVID-19
 
-2020 has been the most demanding of any year in Internet history. This is based on self reporting by [telco companies](https://www2.telegeography.com/network-impact) all over the globe. YouTube, Netflix, gaming console manufacturers and many more were asked to [throttle their networks](https://www.bloomberg.com/news/articles/2020-03-19/netflix-to-cut-streaming-traffic-in-europe-to-relieve-networks) due to anticipated bandwidth demands of Covid and the stay at home orders. There are now new suspects creating demands on the networks: we are now working from home, teleconferencing from home, and now schooling from home as well. In the midst of this crisis some government organizations have moved forward to optimize all aspects of the site and redesign and or updates. Two such examples of being [ca.gov](http://Ca.gov) ([link](https://news.alpha.ca.gov/prioritizing-users-in-a-crisis-building-covid19-ca-gov/)) and [gov.uk](http://gov.uk) . In these times, Covid has certified the Internet as an essential service, and being able to access crucial and life-saving information, Must be as friction free as possible, which includes a manageable page weight via discipline delivery of data.
+2020 has been the most demanding of any year in Internet history. This is based on self reporting by [telecom companies](https://www2.telegeography.com/network-impact) all over the globe. YouTube, Netflix, gaming console manufacturers and many more were asked to [throttle their networks](https://www.bloomberg.com/news/articles/2020-03-19/netflix-to-cut-streaming-traffic-in-europe-to-relieve-networks) due to anticipated bandwidth demands of Covid and the stay at home orders. There are now new suspects creating demands on the networks: we are now working from home, teleconferencing from home, and now schooling from home as well. In the midst of this crisis some government organizations have moved forward to optimize all aspects of the site and redesign and or updates. Two such examples of being [ca.gov](http://Ca.gov) ([link](https://news.alpha.ca.gov/prioritizing-users-in-a-crisis-building-covid19-ca-gov/)) and [gov.uk](http://gov.uk) . In these times, Covid has certified the Internet as an essential service, and being able to access crucial and life-saving information, Must be as friction free as possible, which includes a manageable page weight via discipline delivery of data.
 
 If we have been married to the Internet, Covid has forced us to renew our vows. Assuring that content is delivered as efficiently as possible over the Internet, page weight must be kept at the forefront at all times.
 
 ## A not so distant future
 
 We have watched for 25 years page weight grow steadily. It might have been one of the greatest stock investments — had it been one. But this is the web. And, we are trying to manage data, requests, file size and ultimately page weight. We have just combed over data, seeing how images are the greatest source of weight. This means, it will also be our greatest source of savings. 2020 was a pivotal year, a possible inflection point for HTTP Archive tracking of web data. 2020 marked the year the modern format webp was finally adopted by Safari, making this format finally supported by all browsers across the board. This means that the format could comfortably be used with little to no fall back. The most important point? The potential for significant page weight savings is unavoidable — at a possible 30%. Even more interesting is the idea of a more modern format: avif. This format has burst onto the scene with enough support today for approximately 70% browser market share, creating a scenario for small image file sizes - even smaller than webp. And lastly, and possibly most distant: media queries level 5, ‘prefers-reduced-data ‘. Though in very early draft, this media feature will be used to detect if a user may have a preference for variant resources in data sensitive situations
 
-Looking at the crystal ball, the third instalment of the Almanac and the page weight chapter could have a much different look in 2021. The big technological and engineering investments into images, might finally provide the diminishing returns we have been looking for.
+Looking at the crystal ball, the third installment of the Almanac and the page weight chapter could have a much different look in 2021. The big technological and engineering investments into images, might finally provide the diminishing returns we have been looking for.
 
 ## Conclusion
 

diff --git a/src/content/en/2020/performance.md b/src/content/en/2020/performance.md
@@ -333,7 +333,7 @@ On desktop, 76% of websites have a "not good" TTFB, while on mobile, that percen
 {{ figure_markup(
   image="performance-ttfb-by-geo.png",
   caption="Aggregate TTFB performance split by country.",
-  description="Bar chart showcasing that TTFB performance is consistently sub-par, with only 4 out of 28 countries having more than 30% websites with good TTFB. There is a significant number of websites categorised as needs improvement (always above 40%) with the fraction of poor experiences rising as the ranking position is lower.",
+  description="Bar chart showcasing that TTFB performance is consistently sub-par, with only 4 out of 28 countries having more than 30% websites with good TTFB. There is a significant number of websites categorized as needs improvement (always above 40%) with the fraction of poor experiences rising as the ranking position is lower.",
   chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vT3ukFCTxx__dTBLwDQ3K_hCtXdLRGOGUYdR_TO043n_aCTdcwkxPUku9Qfoal6BESiV5RMtd0nEbqT/pubchart?oid=1135415956&format=interactive",
   width="645",
   height="792",

diff --git a/src/content/en/2020/pwa.md b/src/content/en/2020/pwa.md
@@ -8,7 +8,7 @@ authors: [hemanth]
 reviewers: [thepassle, jadjoubran, pearlbea, gokulkrishh]
 analysts: [bazzadp]
 translators: []
-hemanth_bio: <a href="https://h3manth.com">Hemanth HN</a> is a FOSS Computer polyglot, FOSS philospher, GDE for web and payments domain, DuckDuckGo community member, TC39 delegate and Google Launchpad Accelerator mentor. Loves The WEB && CLI. Hosts <a href="https://TC39er.us">TC39er.us</a> podcast.
+hemanth_bio: <a href="https://h3manth.com">Hemanth HN</a> is a FOSS Computer polyglot, FOSS philosopher, GDE for web and payments domain, DuckDuckGo community member, TC39 delegate and Google Launchpad Accelerator mentor. Loves The WEB && CLI. Hosts <a href="https://TC39er.us">TC39er.us</a> podcast.
 discuss: 2050
 results: https://docs.google.com/spreadsheets/d/1AOqCkb5EggnE8BngpxvxGj_fCfssT9sZ0ElCQKp4pOw/
 queries: 14_PWA
@@ -24,7 +24,7 @@ unedited: true
 
 ## Introduction
 
-In 1990 we had the first ever browser called the “WorldWideWeb” and ever since the web and the browser have been evolving and for the web to progress itself into a native behaviour is a big win especially in this era of mobile domination. URLs and web browsers have provided a ubiquitous way to distribute information and so a technology which provides native app capabilities to the browser is a game changer. Progressive Web Apps provide such advantages for the web to compete with other applications.
+In 1990 we had the first ever browser called the “WorldWideWeb” and ever since the web and the browser have been evolving and for the web to progress itself into a native behavior is a big win especially in this era of mobile domination. URLs and web browsers have provided a ubiquitous way to distribute information and so a technology which provides native app capabilities to the browser is a game changer. Progressive Web Apps provide such advantages for the web to compete with other applications.
 
 Simply put, a web application which give native-like application experience can be considered as a PWA,. It is built using common web technologies including HTML, CSS and JavaScript and can operate seamlessly across devices and environments on a standards-compliant browser.
 
@@ -259,7 +259,7 @@ In order for a PWA to be fruitful it needs to have a manifest and a service work
 
 ### Top Manifest display values
 
-Out of the five most common `display` values, `standalone` dominated the list with `86.73%` of desktop and `89.28%` of mobile pages using this. This isn't suprising at all as this mode provides the native app-like feel. Next in the list was `minimal-ui` with `6.30%` of desktop and `5.00%` of mobile sites opting for them. This is similar to `standalone` except for the fact that some browser UI is retained.
+Out of the five most common `display` values, `standalone` dominated the list with `86.73%` of desktop and `89.28%` of mobile pages using this. This isn't surprising at all as this mode provides the native app-like feel. Next in the list was `minimal-ui` with `6.30%` of desktop and `5.00%` of mobile sites opting for them. This is similar to `standalone` except for the fact that some browser UI is retained.
 
 {{ figure_markup(
   image="pwa-most-used-display-values-for-service-worker-pages.png",
@@ -293,7 +293,7 @@ Out of all the top `categories`, shopping stood at the top at with `13.16%` on t
 {{ figure_markup(
   image="pwa-manifest-preferring-native.png",
   caption="Manifest preferring native.",
-  description="Horiztonal stacked bar chart showing that on desktop 98.24% of destop sites prefer native, and 98.52% of mobile sites prefer native.",
+  description="Horiztonal stacked bar chart showing that on desktop 98.24% of desktop sites prefer native, and 98.52% of mobile sites prefer native.",
   chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRRpTSA4fsHwUap-ByQ08j95uo7Zm1kY6lTSvA-DZT54g2QZ0guV7db3QyQwQgMPzsKsJ43gbzqfJst/pubchart?oid=1370804413&format=interactive",
   sheets_gid="153006256",
   sql_file="manifests_preferring_native_apps_sw.sql"