Lint templates

src/content/en/2019/markup.md

@@ -144,7 +144,7 @@ Additionally, 15% of desktop pages and 16% of mobile pages contain deprecated el
     <td>desktop</td>
   </tr>
   <tr>
-    <td><code>&lt;center><code></td>
+    <td><code>&lt;center></code></td>
     <td>7.96%</td>
     <td>8.30%</td>
   </tr>

src/content/en/2019/pwa.md

@@ -44,7 +44,7 @@ impressive, but taking traffic data from Chrome Platform Status into account, we
 [a service worker controlled 15% of all page loads](https://www.chromestatus.com/metrics/feature/timeline/popularity/990),
 which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. 
 
-<timeseries chart of 11_01b>
+``` <timeseries chart of 11_01b> ```
 
 **Figure 1:** Service Worker installation over time for desktop and mobile
 
@@ -73,11 +73,11 @@ cases that service workers enable are the most attractive feature for app develo
 push notifications. Due to its limited availability, and less common use case, background sync doesn’t 
 play a significant role at the moment. 
 
-<bar chart of 11_03 mobile>
+``` <bar chart of 11_03 mobile> ```
 
 **Figure 2a:** Service worker events on mobile, ordered by decreasing frequency.
 
-<bar chart of 11_03 desktop>
+``` <bar chart of 11_03 desktop> ```
 
 **Figure 2b:** Service worker events on desktop, ordered by decreasing frequency.
 
@@ -90,11 +90,11 @@ We note that these stats don’t account for dynamically imported scripts throug
 [`importScripts()`](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts) method, 
 which likely skews the results higher.
 
-<distribution of 11_03b mobile>
+``` <distribution of 11_03b mobile> ```
 
 **Figure 3a:** Percentiles of service worker file sizes on mobile.
 
-<distribution of 11_03b desktop>
+``` <distribution of 11_03b desktop> ```
 
 **Figure 3b:** Percentiles of service worker file sizes on desktop.
 
@@ -124,11 +124,11 @@ a non-trivial amount of mistyped properties, our favorite being `shot_name`. An
 is the `serviceworker` property which is standard, but not implemented by any browser vendor — 
 nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. 
 
-<bar chart of 11_04 mobile>
+```<bar chart of 11_04 mobile>```
 
 **Figure 4a:** Web App Manifest properties ordered by decreasing popularity on mobile.
 
-<bar chart of 11_04 mobile>
+```<bar chart of 11_04 mobile>```
 
 **Figure 4b:** Web App Manifest properties ordered by decreasing popularity on desktop.
 
@@ -139,11 +139,11 @@ By choosing `"standalone"`, they make sure no browser UI is shown to the end-use
 by the majority of apps that make use of the `prefers_related_applications` property: more that 97% 
 of both mobile and desktop applications do *not* prefer native applications.
 
-<11_04c mobile>
+```<11_04c mobile>```
 
 **Figure 5a:** Values for the `display` property on mobile.
 
-<11_04c desktop>
+```<11_04c desktop>```
 
 **Figure 5b:** Values for the `display` property on desktop.
 
@@ -155,11 +155,11 @@ web application. There were not too many manifests that made use of the property
 interesting to see the shift from *shopping* being the most popular category on mobile to *business*, 
 *technology*, and *web* (whatever may be meant with that) on desktop that share the first place evenly.
 
-<11_04d mobile>
+```<11_04d mobile>```
 
 **Figure 6a:** Values for the `categories` property on mobile.
 
-<11_04d desktop>
+```<11_04d desktop>```
 
 **Figure 6b:** Values for the `categories` property on desktop.
 
@@ -170,11 +170,11 @@ Lighthouse’s rule is probably the culprit for 192×192 being the most popular
 desktop and mobile, despite [Google’s documentation](https://developers.google.com/web/fundamentals/web-app-manifest#icons) 
 additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option.
 
-<11_04f mobile>
+```<11_04f mobile>```
 
 **Figure 7a:** Popular icon sizes on mobile.
 
-<11_04f desktop>
+```<11_04f desktop>```
 
 **Figure 7b:** Popular icon sizes on desktop.
 
@@ -184,11 +184,11 @@ in the Screen Orientation API specification. Namely there are `"any"`, `"natural
 `"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, `"landscape-primary"`, and `"landscape-secondary"`. 
 Portrait orientation is the clear winner on both platforms, followed by any orientation.
 
-<11_04g mobile>
+```<11_04g mobile>```
 
 **Figure 8a:** Popular orientation values on mobile.
 
-<11_04g desktop>
+```<11_04g desktop>```
 
 **Figure 8b:** Popular orientation values on desktop.
 

src/content/en/2019/seo.md

@@ -38,21 +38,21 @@ We assessed the content on the pages by looking for groups of at least 3 words a
 
 The median desktop home page has 346 words, and the median mobile home page has a slightly lower word count at 306 words. This shows that mobile sites do serve a bit less content to their users, but at over 300 words, this is still a reasonable amount to read, especially for a home page which will naturally contain less content than an article page, for example. Overall the distribution of words is broad, with between 22 words at the 10th percentile and up to 1,361 at the 90th percentile.
 
-<graph histogram number of words. Source: 10.09, column C, desktop & mobile>
+```<graph histogram number of words. Source: 10.09, column C, desktop & mobile>```
 
 #### Headings
 
 We also looked at whether pages are structured in a way that provides the right context for the content they contain. Headings (`H1`, `H2`, `H3`, etc) are used to format and structure a page and make content easier to read and parse. Despite the importance on headings, 10.67% of pages have no heading tags at all.
 
-<graph histogram number of heading elements. Source: 10.09a, column F>
+```<graph histogram number of heading elements. Source: 10.09a, column F>```
 
 The median number of heading elements per page is 10, with 30 words (on mobile) and 32 words (on desktop) used in headings. This implies that the websites that utilize headings put significant effort in making sure that their pages are readable, descriptive, and clearly outline the page structure and context to search engine bots.
 
 In terms of specific heading length, the median length of the first `H1` element found on desktop is 19 characters.
 
 For advice on how to handle `H1`s and headings for SEO and accessibility, take a look at this [video response by John Mueller](https://www.youtube.com/watch?v=zyqJJXWk0gk) in the Ask Google Webmasters series.
 
-<graph histogram h1 tag source: 10.16, column C, desktop & mobile>
+```<graph histogram h1 tag source: 10.16, column C, desktop & mobile>```
 
 ### Meta tags
 
@@ -64,15 +64,15 @@ Page titles are an important way of communicating the purpose of a page to a use
 
 Even though [Google usually displays the first 50-60 characters of a page title](https://moz.com/learn/seo/title-tag) within a SERP, the median length of the `<title>` tag was only 21 characters for mobile pages and 20 characters for desktop pages. Even the 75th percentile is still below the cutoff length. This suggests that some SEOs and content writers aren't making the most of the space allocated to them by search engines for describing their home pages in the SERPs.
 
-<graph histogram length <title> Source: 10.07b, column C, desktop & mobile>
+```<graph histogram length <title> Source: 10.07b, column C, desktop & mobile>```
 
 #### Meta descriptions
 
 Compared to the `<title>` tag, fewer pages were detected to have a meta description, as only 64.02% of mobile home pages have a meta description. Considering that Google often rewrites meta descriptions in the SERPs in response to the searcher's query, perhaps website owners place less importance on including a meta description at all.
 
 The median meta description length was also lower than the [recommended length of 155-160 characters](https://moz.com/learn/seo/meta-description), with desktop pages having descriptions of 123 characters. Interestingly, meta descriptions were consistently longer on mobile than on desktop, despite mobile SERPs traditionally having a shorter pixel limit. This limit has only been extended recently, so perhaps more website owners have been testing the impact of having longer, more descriptive meta descriptions for mobile results.
 
-<graph histogram length <meta description> Source: 10.07c, column C, desktop & mobile>
+```<graph histogram length <meta description> Source: 10.07c, column C, desktop & mobile>```
 
 #### Image alt tags
 
@@ -125,9 +125,9 @@ The number of internal and external links included on desktop pages were consist
 
 It's important to bear in mind that fewer internal links on the mobile version of a page [might cause an issue](https://moz.com/blog/internal-linking-mobile-first-crawl-paths) for your website. With [mobile-first indexing](https://www.deepcrawl.com/knowledge/white-papers/mobile-first-index-guide/), which for new websites is the default for Google, if a page is only linked from the desktop version and not present on the mobile version, search engines will have a much harder time discovering and ranking it.
 
-<graph histogram count of links by type Source: 10.10, column C desktop only>
+```<graph histogram count of links by type Source: 10.10, column C desktop only>```
 
-<graph histogram count of links by type Source: 10.10, column D, E, desktop only>
+```<graph histogram count of links by type Source: 10.10, column D, E, desktop only>```
 
 The median desktop page includes 70 internal (same-site) links, whereas the median mobile page has 60 internal links. The median number of external links per page follows a similar trend, with desktop pages including 10 external links, and mobile pages including 8.
 
@@ -149,7 +149,7 @@ A fast-loading website is also crucial for a good user experience. Users that ha
 
 The metrics we used for our analysis of load speed across the web is based on the [Chrome UX Report](../methodology#chrome-ux-report) (CrUX), which collects data from real-world Chrome users. This data shows that an astonishing 63.47% of websites are labelled as **slow**. Split by device, this picture is even bleaker for tablet (82.00%) and phone (77.61%). In the context of our results, per the [PageSpeed Insights classification system](https://developers.google.com/speed/docs/insights/v5/about#categories), a slow website is defined as having 10% of First Contentful Paint (FCP) experiences taking over 2,500 ms or 5% of First Input Delay (FID) experiences measuring over 250 ms.
 
-<graph data 10.15b: CruX image similar to [IMG](https://developers.google.com/web/updates/images/2018/08/crux-dash-fcp.png) per device + speed label>
+```<graph data 10.15b: CruX image similar to [IMG](https://developers.google.com/web/updates/images/2018/08/crux-dash-fcp.png) per device + speed label>```
 
 Although the numbers are bleak for the speed of the web, the good news is that SEO experts and tools have been focusing more and more on the technical challenges of speeding up websites. You can learn more about the state of web performance in the [Performance chapter](../performance).
 
@@ -185,9 +185,9 @@ Internationalization is one of the most complex aspects of SEO, even [according
 
 While 38.40% of desktop sites (33.79% on mobile) have the HTML lang attribute set to English, only 7.43% (6.79% on mobile) of the sites also contain an `hreflang` link to another language version. This suggests that the vast majority of websites that we analyzed don't offer separate versions of their home page that would require language targeting -- unless these separate versions do exist, but haven't been configured correctly.
 
-<graph 10.04b - [do we want to chart this data, e.g. what does it really mean for SEO?]>
+```<graph 10.04b - [do we want to chart this data, e.g. what does it really mean for SEO?]>```
 
-<include a chart of the languages and country combinations found, SEOs will want to see this breakdown>
+```<include a chart of the languages and country combinations found, SEOs will want to see this breakdown>```
 
 Next to English, the most common languages are French, Spanish, and German. These are followed by languages targeted towards specific geographies like English for Americans (`en-us`) or more obscure combinations like Spanish for the Irish (`es-ie`).
 

src/content/en/2019/third-parties.md

@@ -47,41 +47,41 @@ This chapter divides third-party providers into one of these broad categories. A
 
 Third-party code is everywhere. 93% of pages include at least one third-party resource, 76% of pages issue a request to an analytics domain, the median page requests content from at least 9 _unique_ third-party domains that represent 35% of their total network activity, and the most active 10% of pages issue a whopping 175 third-party requests or more. It’s not a stretch to say that third parties are an integral part of the web.
 
-<insert stylized value of metric 05_01>
+```<insert stylized value of metric 05_01>```
 
-<insert stylized value of metric 05_02>
+```<insert stylized value of metric 05_02>```
 
 ### Categories
 
 If the ubiquity of third-party content is unsurprising, perhaps more interesting is the breakdown of third-party content by provider type.
 
 While advertising might be the most user-visible example of third-party presence on the web, analytics providers are the most common third-party category with 76% of sites including at least one analytics request. CDNs at 63%, ads at 57%, and developer utilities like Sentry, Stripe, and Google Maps SDK at 56% follow up as a close second, third, and fourth for appearing on the most web properties. The popularity of these categories forms the foundation of our web usage patterns identified later in the chapter.
 
-<insert graphic of metric 05_11>
+```<insert graphic of metric 05_11>```
 
 ### Providers
 
 A relatively small set of providers dominate the third-party landscape, the top 100 domains account for 30% of network requests across the web. Powerhouses like Google, Facebook, and YouTube make the headlines here with full percentage points of share each, but smaller entities like Wix and Shopify command a substantial portion of third-party popularity as well.
 
 While much could be said about every individual provider’s popularity and performance impact, this more opinionated analysis is left as an exercise for the reader and other purpose-built tools such as [third-party-web](https://thirdpartyweb.today).
 
-<insert table of metric 05_06>
+```<insert table of metric 05_06>```
 
-<insert table of metric 05_09>
+```<insert table of metric 05_09>```
 
 ### Resource Types
 
 The resource type breakdown of third-party content also lends insight into how third-party code is used across the web. While first-party requests are 56% images, 23% script, 14% CSS, and only 4% HTML, third-party requests skew more heavily toward script and HTML at 32% script, 34% images, 12% HTML, and only 6% CSS. While this suggests that third-party code is less frequently used to aid the design and instead used more frequently to facilitate or observe interactions than first-party code, a breakdown of resource types by party status tells a more nuanced story. While CSS and images are dominantly first-party at 70% and 64% respectively, fonts are largely served by third-party providers with only 28% being served from first-party sources. This concept of usage patterns is explored in more depth later in this chapter.
 
-<insert graphic of metric 05_03>
+```<insert graphic of metric 05_03>```
 
 Several other amusing factoids jump out from this data. Tracking pixels (image requests to analytics domains) make up 1.6% of all network requests, six times as many video requests are to social networks like Facebook and Twitter than dedicated video providers like YouTube and Vimeo (presumably because the default YouTube embed consists of HTML and a preview thumbnail but not an autoplaying video), and there are still more requests for first-party images than all scripts combined.
 
 ### Request Count
 
 49% of all requests are third-party. At 51%, first-party can still narrowly hold on to the crown in 2019 of comprising the majority of the web resources. Given that just under half of all the requests are third-party yet a small set of pages do not include any at all, the most active third-party users must be doing quite a bit more than their fair share. Indeed, at the 75th, 90th, and 99th percentiles we see nearly all of the page being comprised of third-party content. In fact, for some sites heavily relying on distributed WYSIWYG platforms like Wix and SquareSpace, the root document might be the sole first-party request!
 
-<insert graphic of metric 05_11>
+```<insert graphic of metric 05_11>```
 
 The number of requests issued by each third-party provider also varies considerably by category. While analytics are the most widespread third-party category across websites, they account for only 7% of all third-party network requests. Ads, on the other hand, are found on nearly 20% fewer sites yet make up 25% of all third-party network requests. Their outsized resource impact compared to their popularity will be a theme we continue to uncover in the remaining data.
 
@@ -91,27 +91,27 @@ While 49% of requests are third-party, their share of the web in terms of bytes
 
 Despite serving 57% of scripts, third parties comprise 64% of script bytes. meaning their scripts are larger on average than first-party scripts. This is an early warning sign for their performance impact to come in the next few sections.
 
-<insert graphic of metric 05_04>
+```<insert graphic of metric 05_04>```
 
-<insert graphic of metric 05_12>
+```<insert graphic of metric 05_12>```
 
 As for specific third-party providers, the same juggernauts topping the request count leaderboards make their appearance in byte weight as well. The only few notable movements are the large, media-heavy providers such as YouTube, Shopify, and Twitter which climb to the top of the byte impact charts.
 
-<insert table of metric 05_07>
+```<insert table of metric 05_07>```
 
 ### Script Execution
 
 57% of script execution time is from third-party scripts, and the top 100 domains already account for 48% of all script execution time on the web. This underscores just how large an impact a select few entities really have on web performance. This topic is explored more in depth in the [Repercussions > Performance](#performance) section.
 
-<insert graphic of metric 05_05>
+```<insert graphic of metric 05_05>```
 
-<insert graphic of metric 05_13>
+```<insert graphic of metric 05_13>```
 
 The category breakdowns among script execution largely follow that of resource counts. Here too advertising looms largest. Ad scripts comprise 25% of third-party script execution time with hosting and social providers in a distant tie for second at 12%.
 
-<insert table of metric 05_08>
+```<insert table of metric 05_08>```
 
-<insert table of metric 05_10>
+```<insert table of metric 05_10>```
 
 While much could be said about every individual provider’s popularity and performance impact, this more opinionated analysis is left as an exercise for the reader and other purpose-built tools such as the previously mentioned [third-party-web](https://thirdpartyweb.today).
 

src/package.json

@@ -20,6 +20,7 @@
     "ejs": "^2.7.1",
     "fs-extra": "^8.1.0",
     "jsdom": "^15.2.0",
+    "prettier": "^1.18.2",
     "showdown": "^1.9.0"
   }
 }