diff --git a/src/content/en/2019/media.md b/src/content/en/2019/media.md index f8968a43417..ab5f7dc98d6 100644 --- a/src/content/en/2019/media.md +++ b/src/content/en/2019/media.md @@ -51,7 +51,7 @@ For the median web page on desktop, only 46% of the display would have layout co Media resources are critical for the user experience! # Images -Much has already been written on the subject of managing and optimizing images to help reduce the bytes and optimize the user experience. <> It is an important and critical topic for many because it is the creative media that define a brand experience. Therefore optimizing image and video content is a balancing act between applying best practices that can help reduce the bytes transferred over the network while preserving the fidelity of the intended experience. +Much has already been written on the subject of managing and optimizing images to help reduce the bytes and optimize the user experience. `<>` It is an important and critical topic for many because it is the creative media that define a brand experience. Therefore optimizing image and video content is a balancing act between applying best practices that can help reduce the bytes transferred over the network while preserving the fidelity of the intended experience. While the strategies that are utilized for images, videos and animations are, in broad strokes similar, the specific approaches can be very different. In general, these strategies boil down to: * File Formats - utilizing the optimal file format diff --git a/src/package-lock.json b/src/package-lock.json index ae7a09416cf..8b569a225cf 100644 --- a/src/package-lock.json +++ b/src/package-lock.json @@ -515,9 +515,9 @@ "dev": true }, "jsdom": { - "version": "15.2.0", - "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-15.2.0.tgz", - "integrity": "sha512-+hRyEfjRPFwTYMmSQ3/f7U9nP8ZNZmbkmUek760ZpxnCPWJIhaaLRuUSvpJ36fZKCGENxLwxClzwpOpnXNfChQ==", + "version": "15.2.1", + "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-15.2.1.tgz", + "integrity": "sha512-fAl1W0/7T2G5vURSyxBzrJ1LSdQn6Tr5UX/xD4PXDx/PDgwygedfW6El/KIj3xJ7FU61TTYnc/l/B7P49Eqt6g==", "dev": true, "requires": { "abab": "^2.0.0", @@ -530,7 +530,7 @@ "domexception": "^1.0.1", "escodegen": "^1.11.1", "html-encoding-sniffer": "^1.0.2", - "nwsapi": "^2.1.4", + "nwsapi": "^2.2.0", "parse5": "5.1.0", "pn": "^1.1.0", "request": "^2.88.0", @@ -693,9 +693,9 @@ "dev": true }, "nwsapi": { - "version": "2.1.4", - "resolved": "https://registry.npmjs.org/nwsapi/-/nwsapi-2.1.4.tgz", - "integrity": "sha512-iGfd9Y6SFdTNldEy2L0GUhcarIutFmk+MPWIn9dmj8NMIup03G08uUF2KGbbmv/Ux4RT0VZJoP/sVbWA6d/VIw==", + "version": "2.2.0", + "resolved": "https://registry.npmjs.org/nwsapi/-/nwsapi-2.2.0.tgz", + "integrity": "sha512-h2AatdwYH+JHiZpv7pt/gSX1XoRGb7L/qSIeuqA6GwYoF9w1vP1cw42TO0aI2pNyshRK5893hNSl+1//vHK7hQ==", "dev": true }, "oauth-sign": { @@ -881,21 +881,21 @@ } }, "request-promise-core": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/request-promise-core/-/request-promise-core-1.1.2.tgz", - "integrity": "sha512-UHYyq1MO8GsefGEt7EprS8UrXsm1TxEvFUX1IMTuSLU2Rh7fTIdFtl8xD7JiEYiWU2dl+NYAjCTksTehQUxPag==", + "version": "1.1.3", + "resolved": "https://registry.npmjs.org/request-promise-core/-/request-promise-core-1.1.3.tgz", + "integrity": "sha512-QIs2+ArIGQVp5ZYbWD5ZLCY29D5CfWizP8eWnm8FoGD1TX61veauETVQbrV60662V0oFBkrDOuaBI8XgtuyYAQ==", "dev": true, "requires": { - "lodash": "^4.17.11" + "lodash": "^4.17.15" } }, "request-promise-native": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/request-promise-native/-/request-promise-native-1.0.7.tgz", - "integrity": "sha512-rIMnbBdgNViL37nZ1b3L/VfPOpSi0TqVDQPAvO6U14lMzOLrt5nilxCQqtDKhZeDiW0/hkCXGoQjhgJd/tCh6w==", + "version": "1.0.8", + "resolved": "https://registry.npmjs.org/request-promise-native/-/request-promise-native-1.0.8.tgz", + "integrity": "sha512-dapwLGqkHtwL5AEbfenuzjTYg35Jd6KPytsC2/TLkVMz8rm+tNt72MGUWT1RP/aYawMpN6HqbNGBQaRcBtjQMQ==", "dev": true, "requires": { - "request-promise-core": "1.1.2", + "request-promise-core": "1.1.3", "stealthy-require": "^1.1.1", "tough-cookie": "^2.3.3" }, diff --git a/src/package.json b/src/package.json index f2513c0647d..4582d320bcf 100644 --- a/src/package.json +++ b/src/package.json @@ -19,9 +19,9 @@ "devDependencies": { "ejs": "^2.7.1", "fs-extra": "^8.1.0", - "jsdom": "^15.2.0", + "jsdom": "^15.2.1", "prettier": "^1.18.2", - "showdown": "^1.9.0", - "recursive-readdir": "^2.2.2" + "recursive-readdir": "^2.2.2", + "showdown": "^1.9.0" } } diff --git a/src/static/css/2019.css b/src/static/css/2019.css index ef99d936eab..2a5fb00d7ac 100644 --- a/src/static/css/2019.css +++ b/src/static/css/2019.css @@ -4,6 +4,9 @@ body { color: #1A2B49; margin: 0; font-weight: inherit; + -webkit-font-smoothing: antialiased; + font-size: 17px; + line-height: 30px; } * { @@ -27,9 +30,8 @@ a:focus, a:hover { } h1.title { - margin-top: 0; - font-size: 72px; - line-height: 80px; + margin-top: 20px; + font-size: 50px; } div.subtitle { @@ -46,6 +48,15 @@ div.subtitle::before { width: 70px; } +h2.header { + font-size: 25px; + margin: 14px; +} +.subtitle { + font-size: 28px; + line-height: 42px; +} + .btn { border: 1px solid #1A2B49; border-radius: 50px; @@ -116,8 +127,8 @@ header.alt-bg a:focus, footer.alt-bg a:focus { header, footer { padding: 40px 60px; } -.main { - margin: 0px 60px; +article.main { + max-width: 1324px; } header, footer .nav { display: flex; @@ -143,6 +154,8 @@ nav a { header .cta { display: flex; + min-width: 205px; + flex-direction: row-reverse; } header .btn + .language-switcher { @@ -192,6 +205,32 @@ header .btn + .language-switcher { display: none; } +.main { + margin: 0px auto; + font-size: 17px; +} +.content, section.main { + max-width: 1024px; +} + +.main a, +.main a:visited { + color: #0b1423; + word-break: break-all; +} + +h2, h3, h4 { + margin-top: 2em; +} + +p, td, th, code, li { + font-size: 17px; +} + +pre { + margin: 0; +} + hr { opacity: 0.2; } @@ -200,15 +239,15 @@ blockquote { position: relative; font-style: italic; font-size: 19px; - line-height: 26px; } + blockquote::before { content: '"'; position: absolute; z-index: -1; top: -4rem; left: -7rem; - opacity: .05; + opacity: .05; font-size: 20rem; font-family: 'Courier New', Courier, monospace; line-height: 1; @@ -347,6 +386,10 @@ p.copyright { /* Mobile View */ @media (max-width: 600px) { + body, p, td, th, code, li { + font-size: 16px; + } + .alt-bg.decorative-line, .alt-bg .decorative-line { margin: 0 40% !important; @@ -373,7 +416,9 @@ p.copyright { header nav > a:last-child { margin: 0; } - + h1.title { + font-size: 40px; + } .menu { position: absolute; display: none; @@ -384,15 +429,15 @@ p.copyright { width: 100%; padding: 60px 30px 30px; background-color: #677486; - box-shadow: 0px 12px 12px 3px rgba(0, 0, 0, 0.2); + box-shadow: 0 0 16px 0 rgba(78, 85, 100, 0.2); opacity: 0.95; z-index: 1; } .menu-btn { background: none; border: 0; - display: block; - cursor: pointer; + display: block; + cursor: pointer; } .menu-open .menu { diff --git a/src/static/css/index.css b/src/static/css/index.css index 710d10d1b4f..9902981c183 100644 --- a/src/static/css/index.css +++ b/src/static/css/index.css @@ -58,8 +58,6 @@ header.alt-bg { } p { - font-size: 16px; - line-height: 24px; margin-bottom: 40px; } diff --git a/src/static/css/methodology.css b/src/static/css/methodology.css index b68834b2798..ee7f063e7a9 100644 --- a/src/static/css/methodology.css +++ b/src/static/css/methodology.css @@ -23,7 +23,7 @@ } .floating-card { border-radius: 16px; - box-shadow: 0 0 5px 5px #f6f7f9; + box-shadow: 0 0 16px 0 rgba(78, 85, 100, 0.2); } .code-block { margin: 8px 0; diff --git a/src/static/css/page.css b/src/static/css/page.css index 64a6d4fe985..53b60328bc7 100644 --- a/src/static/css/page.css +++ b/src/static/css/page.css @@ -1,26 +1,30 @@ .main { - margin-top: 32px; - overflow: visible; + padding-top: 32px; display: grid; grid-template-areas: 'index content'; grid-template-columns: 300px auto; - font-size: 18px; - line-height: 30px; } -table, +.table-wrap, .floating-card { border-radius: 16px; - box-shadow: 0 0 5px 5px #f6f7f9; + box-shadow: 0 0 16px 0 rgba(78, 85, 100, 0.2); +} +.table-wrap { + display: inline-block; + margin: 10px 0; + max-width: 100%; + overflow: auto; } + .code-block { margin: 8px 0; - padding: 16px; + padding: 24px; } .code-block .divider { position: relative; border: 1px solid #1A2B490A; width: calc(100% + 32px); - left: -16px; + left: -24px; } .code-block pre { overflow-y: hidden; @@ -177,10 +181,13 @@ table, height: 60px; border-radius: 50%; } - +.authors .social { + display: inline-block; + vertical-align: top; +} .authors .social img{ - width: 24px; - height: 24px; + width: auto; + height: 18px; display: inline-block; margin-left: 16px; vertical-align: middle; @@ -235,11 +242,6 @@ table, right:-24px; } -.main a, -.main a:visited { - color: initial; -} - img, table, figure { @@ -272,11 +274,11 @@ figcaption { margin-top: 20px; text-align: center; } - table { margin: 0 auto; max-width: 100%; border-collapse: collapse; + display: block; } thead { font-family: 'Poppins', sans-serif; @@ -299,7 +301,6 @@ figure .big-number { @media (max-width: 900px) { .main { - padding: 0; grid-template-areas: 'index' 'content'; @@ -353,6 +354,10 @@ figure .big-number { max-height: 100%; transition: max-height 0.25s ease-in; } + + table { + font-size: .8em; + } } @media (max-width: 600px) { diff --git a/src/templates/en/2019/chapters/caching.html b/src/templates/en/2019/chapters/caching.html index 6313281fde9..7fa7b47d8c6 100644 --- a/src/templates/en/2019/chapters/caching.html +++ b/src/templates/en/2019/chapters/caching.html @@ -236,101 +236,104 @@

What Type of Content Are We Caching

The table below details the cache TTL values for desktop requests by type. Most content types are being cached, however CSS resources appear to be consistently cached at high TTLs.

While most of the median TTLs are high, the lower percentiles highlight some of the missed caching opportunities. For example, the median TTL for images is 28 hours, however the 25th percentile is just 1-2 hours and the 10th percentile indicates that 10% of cacheable image content is cached for less than 1 hour.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Desktop Cache TTL Percentiles (Hours)
typep10p25p50p75p90
audio

12

24

720

8760

8760

css

720

8760

8760

8760

8760

font

< 1

3

336

8760

87600

html

< 1

168

720

8760

8766

image

< 1

1

28

48

8760

other

< 1

2

336

8760

8760

script

< 1

< 1

1

6

720

text

21

336

7902

8357

8740

video

< 1

4

24

24

336

xml

< 1

< 1

< 1

< 1

< 1

- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Desktop Cache TTL Percentiles (Hours)
typep10p25p50p75p90
audio

12

24

720

8760

8760

css

720

8760

8760

8760

8760

font

< 1

3

336

8760

87600

html

< 1

168

720

8760

8766

image

< 1

1

28

48

8760

other

< 1

2

336

8760

8760

script

< 1

< 1

1

6

720

text

21

336

7902

8357

8740

video

< 1

4

24

24

336

xml

< 1

< 1

< 1

< 1

< 1

+

By exploring the cacheability by content type in more detail, we can see that approximately half of all HTML responses are considered non-cacheable. Additionally, 16% of images and scripts are non-cacheable.

The same data for mobile is shown below. The cacheability of content types is consistent between desktop and mobile.

@@ -349,61 +352,64 @@

Cache-Control vs Expires

Cache-Control Directives

The HTTP/1.1 specification includes multiple directives that can be used in the Cache-Control response header and are detailed below. Note that multiple can be used in a single response.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DirectiveDescription
max-ageIndicates the number of seconds that a resource can be cached for
publicAny cache may store the response.
no-cacheA cached entry must be revalidated prior to it's use
must-revalidateA stale cached entry must be revalidated prior to its use
no-storeIndicates that a response is not cacheable
privateThe response is intended for a specific user and should not be stored by shared caches.
no-transformNo transformations or conversions should be made to this resource
proxy-revalidateSame as must-revalidate, but applies to shared caches.
s-maxageSame as max age, but applies to shared caches only
immutableIndicates that the cached entry will never change, and that revalidation is not necessary.
stale-while-revalidateIndicates that the client is willing to accept a stale response while asynchronously checking in the background for a fresh one.
stale-if-errorIndicates that the client is willing to accept a stale response if the check for one fails.
- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DirectiveDescription
max-ageIndicates the number of seconds that a resource can be cached for
publicAny cache may store the response.
no-cacheA cached entry must be revalidated prior to it's use
must-revalidateA stale cached entry must be revalidated prior to its use
no-storeIndicates that a response is not cacheable
privateThe response is intended for a specific user and should not be stored by shared caches.
no-transformNo transformations or conversions should be made to this resource
proxy-revalidateSame as must-revalidate, but applies to shared caches.
s-maxageSame as max age, but applies to shared caches only
immutableIndicates that the cached entry will never change, and that revalidation is not necessary.
stale-while-revalidateIndicates that the client is willing to accept a stale response while asynchronously checking in the background for a fresh one.
stale-if-errorIndicates that the client is willing to accept a stale response if the check for one fails.
+

For example, the below header indicates that a cached entry should be stored for 43200 seconds and it can be stored by all caches.

cache-control: public, max-age=43200

The graph below illustrates the top 15 Cache-Control directives in use.

@@ -445,31 +451,34 @@

How Do Cache TTLs Compare to

< etag: "1566748830.0-3052-3932359948"

Overall, 59% of resources served on the web have a cache TTL that is too short compared to it’s content age. Furthermore, the median delta between the TTL and age is 25 days.

When we break this out by first vs third party, we can also see that 70% of first party resources can benefit from a longer TTL. This clearly highlights a need to spend extra attention focusing on what is cacheable, and then ensuring caching is configured correctly.

- - - - - - - - - - - - - - - - - - - - - - - -
% of Requests with Short TTLs
client1st Party3rd PartyOverall
desktop

70.7%

47.9%

59.2%

mobile

71.4%

46.8%

59.6%

- +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
% of Requests with Short TTLs
client1st Party3rd PartyOverall
desktop

70.7%

47.9%

59.2%

mobile

71.4%

46.8%

59.6%

+

Validating Freshness

The HTTP response headers used for validating the responses stored within a cache are Last-Modified and Etag. The Last-Modified header provides the time that the object was last modified, and the Etag header provides a unique identifier for the content.

For example, the response below was last modified on 25 Aug 2019 and it has an Etag value of "1566748830.0-3052-3932359948"

@@ -552,65 +561,71 @@

AppCache and Service Workers

In fact, one of the HTTP Archive trend reports shows the adoption of Service Workers. Adoption is still below 1% of websites, but it has been steadily increasing since January 2017.

In the table below, you can see a summary of AppCache vs ServiceWorker usage. 32,292 websites have implemented a Service Worker, while 1,867 sites are still utilizing the deprecated AppCache feature.

- - - - - - - - - - - - - - - - - - - - - - - - - -
Does Not Use Server WorkerUses Service WorkerTotal
Does Not Use AppCache

5,045,337

32,241

5,077,578

Uses AppCache

1,816

51

1,867

Total

5,047,153

32,292

5,079,445

- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Does Not Use Server WorkerUses Service WorkerTotal
Does Not Use AppCache

5,045,337

32,241

5,077,578

Uses AppCache

1,816

51

1,867

Total

5,047,153

32,292

5,079,445

+

If we break this out by HTTP vs HTTPS, then this gets even more interesting. 581 of the AppCache enabled sites are served over HTTP, which means that Chrome is likely disabling the feature. HTTPS is a requirement for using Service Workers, but 907 of the sites using them are served over HTTP.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does Not Use Service WorkerUses Service Worker
HTTPDoes Not Use AppCache

1,968,736

907

Uses AppCache

580

1

HTTPSDoes Not Use AppCache

3,076,601

31,334

Uses AppCache

1,236

50

- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Does Not Use Service WorkerUses Service Worker
HTTPDoes Not Use AppCache

1,968,736

907

Uses AppCache

580

1

HTTPSDoes Not Use AppCache

3,076,601

31,334

Uses AppCache

1,236

50

+

Identifying Caching Opportunities

Google’s Lighthouse tool enables users to run a series of audits against web pages, and one of them evaluates whether a site can benefit from additional caching. It does this by comparing the content age (via the Last-Modified header) to the Cache TTL and estimating the probability that the resource would be served from cache. Depending on the score, you may see a caching recommendation in the results, with a list of specific resources that could be cached.

diff --git a/src/templates/en/2019/chapters/compression.html b/src/templates/en/2019/chapters/compression.html index 97bca4f890f..b02b35ddcad 100644 --- a/src/templates/en/2019/chapters/compression.html +++ b/src/templates/en/2019/chapters/compression.html @@ -166,84 +166,87 @@

Compression Algorithms

  • Brotli compression is a newer compression algorithm that was invented by Google. It uses the combination of a modern variant of the LZ77 algorithm, Huffman coding and 2nd order context modeling. Compression via brotli is more computationally expensive compared to gzip, but the algorithm is able to reduce files by 15-25% more than gzip compression. Brotli was first used for compressing web content in 2015, and is supported by all modern web browsers.

    • Appoximately 38% of HTTP responses are delivered with text based compression. This may seem like a surprising statistic, but keep in mind that it is based on all HTTP requests in the archive. Some content, such as images, will not benefit from these compression algorithms. The table below summarizes the percentage of requests served with each content encoding.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    % of RequestsRequests
    Content Encodingdesktopmobiledesktopmobile
    none

    62.87%

    61.47%

    260245106

    285158644

    gzip

    29.66%

    30.95%

    122789094

    143549122

    br

    7.43%

    7.55%

    30750681

    35012368

    deflate

    0.02%

    0.02%

    68802

    70679

    Other / Invalid

    0.02%

    0.01%

    67527

    68352

    identity

    0.000709%

    0.000563%

    2935

    2611

    x-gzip

    0.000193%

    0.000179%

    800

    829

    compress

    0.000008%

    0.000007%

    33

    32

    x-compress

    0.000002%

    0.000006%

    8

    29

    - +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    % of RequestsRequests
    Content Encodingdesktopmobiledesktopmobile
    none

    62.87%

    61.47%

    260245106

    285158644

    gzip

    29.66%

    30.95%

    122789094

    143549122

    br

    7.43%

    7.55%

    30750681

    35012368

    deflate

    0.02%

    0.02%

    68802

    70679

    Other / Invalid

    0.02%

    0.01%

    67527

    68352

    identity

    0.000709%

    0.000563%

    2935

    2611

    x-gzip

    0.000193%

    0.000179%

    800

    829

    compress

    0.000008%

    0.000007%

    33

    32

    x-compress

    0.000002%

    0.000006%

    8

    29

    +

    Of the resources that are served compressed, the majority are using either either gzip (80%) or brotli (20%). The other compression algorithms are infrequently used.

    Additionally, there are 67K requests that return an invalid Content-Encoding, such as “none”, “UTF-8”, “base64”, “text”, etc. These resources are likely served uncompressed.

    @@ -262,57 +265,62 @@

    What Type of Content Are We Com

    The graphs below illustrates the breakdown of compression techniques used for each content type. Looking at the top 3 content types, we can see that across both Desktop and Mobile there are major gaps in compressing some of the most frequently requested content types. 56% of text/html as well as 18% of application/javascript and text/css resources are not being compressed. This presents a significant performance opportunity..

    +

    The content types with the lowest compression rates include application/json, text/xml and text/plain. These resources are commonly used for XHR requests to provide data that web applications can use to create rich experiences. Compressing them will likely improve user experience. Vector graphics such as image/svg+xml, and image/x-icon are not often thought of as text based, but they are and sites that use them would benefit from compression.

    +

    Across all content types, gzip is the most popular compression algorithm. Brotli compression is used less frequently, and the content types where it appears most are application/javascript, text/css and application/x-javascript. This is likely due to to CDNs that automatically apply brotli compression for traffic that passes through them.

    1st Party vs 3rd Party Compression

    In Chapter 5, we learned about third parties and their impact on performance. When we compare compression techniques between first and third parties, we can see that third party content tends to be compressed more than first party content.

    Additionally, the percentage of Brotli compression is higher for third party content. This is likely due to the number of resources served from third parties that support Brotli, such as Google and Facebook with Brotli.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Content EncodingFirstPartyThirdPartyFirstPartyThirdParty
    No Text Compression

    66.23%

    59.28%

    64.54%

    58.26%

    gzip

    29.33%

    30.20%

    30.87%

    31.22%

    br

    4.41%

    10.49%

    4.56%

    10.49%

    deflate

    0.02%

    0.01%

    0.02%

    0.01%

    other / invalid

    0.01%

    0.02%

    0.01%

    0.02%

    - +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Content EncodingFirstPartyThirdPartyFirstPartyThirdParty
    No Text Compression

    66.23%

    59.28%

    64.54%

    58.26%

    gzip

    29.33%

    30.20%

    30.87%

    31.22%

    br

    4.41%

    10.49%

    4.56%

    10.49%

    deflate

    0.02%

    0.01%

    0.02%

    0.01%

    other / invalid

    0.01%

    0.02%

    0.01%

    0.02%

    +

    Identifying Compression Opportunities

    Google’s Lighthouse tool enables users to run a series of audits against web pages, and one of them evaluates whether a site can benefit from additional text based compression. It does this by attempting to compress resources and evaluate whether an object’s size can be reduced by at least 10% and 1400 bytes. Depending on the score, you may see a compression recommendation in the results, with a list of specific resources that could be compressed.

    diff --git a/src/templates/en/2019/chapters/ecommerce.html b/src/templates/en/2019/chapters/ecommerce.html index 4b094fece56..3f0df08d24e 100644 --- a/src/templates/en/2019/chapters/ecommerce.html +++ b/src/templates/en/2019/chapters/ecommerce.html @@ -363,56 +363,59 @@

    Third party requests and bytes

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Number of requestsPayload (KB)
    PercentileMobileDesktopMobileDesktop
    104433.0541.51
    2589118.44129.39
    501719292.61320.17
    753234613.46651.19
    9050541016.451071.3
    - +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Number of requestsPayload (KB)
    PercentileMobileDesktopMobileDesktop
    104433.0541.51
    2589118.44129.39
    501719292.61320.17
    753234613.46651.19
    9050541016.451071.3
    +
    Figure 22. Total third party requests for home pages on ecommerce platforms.

    The median ('mid-range') home page on an ecommerce platform makes 17 requests for third party content on mobile and 19 on desktop. 10% of all home pages on ecommerce platforms make over 50 requests for third-party content, with a total payload of over 1 MB.

    @@ -451,7 +454,7 @@

    Third party requests and

    'Hosting' in these charts refers to files used by the platforms themselves, such as boilerplate JavaScript and CSS. Video libraries constitute the largest number of requests and by far the largest payload size of third party content for home pages on ecommerce platforms (apart from files used by the platforms themselves — the 'Hosting' category).

    Analytics, reviews and user behavior monitoring

    - // Charts • 13_10: Top analytics providers > 1%, https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1232567425 + // Charts • 13_10: Top analytics providers > 1%, https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1232567425
    Figure 29. Analytics, review and user behavior monitoring.
    @@ -461,7 +464,7 @@

    Analytics, reviews and u

    138 analytics providers were found, 131 of which get less than 1% of all requests. Of these, more than 100 get less than 0.1% of requests. Google Analytics gets around ten times as many requests (and pages) as the second most popular provider, Hotjar.

    Top ad providers

    - // Chart 13_11: Top ad providers >=1% // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1621252176 + // Chart 13_11: Top ad providers >=1% // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1621252176
    Figure 31. Top ad providers.
    diff --git a/src/templates/en/2019/chapters/fonts.html b/src/templates/en/2019/chapters/fonts.html index ed80b720be6..3aa52b1596e 100644 --- a/src/templates/en/2019/chapters/fonts.html +++ b/src/templates/en/2019/chapters/fonts.html @@ -141,7 +141,7 @@

    Introduction

    I was hoping to see SVG fonts on the decline. They’re buggy and implementations have been removed from every browser except Safari. Time to drop these, y’all.

    06.39–41: src formats combinations

      -
    • TODO Zach’s note: The order here is important, yeah.
      • +
    • TODO Zach’s note: The order here is important, yeah.

    06.04: font-display Usage

    @@ -156,7 +156,7 @@

    Introduction

    06.09b: Web font families

    • - TODO Zach’s note: Is this families per page? What is httparchive.almanac.parsed_css? + TODO Zach’s note: Is this families per page? What is httparchive.almanac.parsed_css?

    These results were a little surprising. I didn’t expect this to line up so well with the number of web font requests per page. Namely I didn’t expect so many unique font families! To me this suggests a few things might be happening here:

    @@ -183,11 +183,11 @@

    Introduction

    Through the lens of the this large data set, these are very low sample sizes—take these results with a grain of salt. However, opsz as the most common axis is notable, with wght and wdth trailing. In my experience, the introductory demos for variable fonts are usually font-weight based.

    06.29: Variable Font variation axes +/- 20pt

      -
    • TODO [CONTENT_NEEDED]
      • +
    • TODO [CONTENT_NEEDED]

    06.30: Variable Font variation axes combinations

      -
    • TODO [CONTENT_NEEDED]
      • +
    • TODO [CONTENT_NEEDED]

    06.26: font-stretch

    diff --git a/src/templates/en/2019/chapters/http2.html b/src/templates/en/2019/chapters/http2.html index a1da4d7a91c..d37b9db239a 100644 --- a/src/templates/en/2019/chapters/http2.html +++ b/src/templates/en/2019/chapters/http2.html @@ -171,322 +171,334 @@

    Adoption of HTTP/2

    Figure 1 - HTTP/2 usage by request

    Looking at the breakdown of all HTTP versions by request we see the following:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ProtocolDesktopMobileBoth
    5.60%0.57%2.97%
    HTTP/0.90.00%0.00%0.00%
    HTTP/1.00.08%0.05%0.06%
    HTTP/1.140.36%45.01%42.79%
    HTTP/253.96%54.37%54.18%
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ProtocolDesktopMobileBoth
    5.60%0.57%2.97%
    HTTP/0.90.00%0.00%0.00%
    HTTP/1.00.08%0.05%0.06%
    HTTP/1.140.36%45.01%42.79%
    HTTP/253.96%54.37%54.18%
    +

    Figure 2 - HTTP version usage by request

    This shows that HTTP/1.1 and HTTP/2 are the versions used by the vast majority of requests as expected. There are only a very small number of requests on the older HTTP/1.0 and HTTP/0.9 protocols. Annoyingly there is a larger percentage where the protocol was not correctly tracked by the HTTP Archive crawl, particularly on desktop. Digging into this has shown various reasons, some of which I can explain and some of which I can't. Based on spot checks they mostly appear to be HTTP/1.1 requests and, assuming they are, desktop and mobile usage is similar. Despite there being a little larger percentage of noise than I'd like, it doesn't alter the overall message being conveyed here. Other than that, the mobile/desktop similarity is not unexpected - the HTTP Archive crawls using Chrome which supports HTTP/2 for both desktop and mobile. Real world usage may have slightly different stats with some older usage of browsers on both but even then support is widespread so I would not expect a large variation between desktop and mobile.

    At present the HTTP Archive does not track HTTP over QUIC (soon to be standardized as HTTP/3) separately, so these are listed under HTTP/2 but we'll look at other ways of measuring that later in this chapter.

    -

    Looking at the number of requests will skew the results somewhat due to popular requests. For example, many sites load Google Analytics, which does support HTTP/2, and so would show as an HTTP/2 request even if the embedding site itself does not support HTTP/2. On the other hand, popular websites (that tend to support HTTP/2) are also underrepresented in the above stats as they are only measured once (e.g. google.com and obscuresite.com are given equal weighting). There are lies, damn lies and statistics. However, looking at other sources (for example the Mozilla telemetry which looks at real-world usage through the Firefox browser) shows similar statistics.

    +

    Looking at the number of requests will skew the results somewhat due to popular requests. For example, many sites load Google Analytics, which does support HTTP/2, and so would show as an HTTP/2 request even if the embedding site itself does not support HTTP/2. On the other hand, popular websites (that tend to support HTTP/2) are also underrepresented in the above stats as they are only measured once (e.g. google.com and obscuresite.com are given equal weighting). There are lies, damn lies and statistics. However, looking at other sources (for example the Mozilla telemetry which looks at real-world usage through the Firefox browser) shows similar statistics.

    It is still interesting to look at home pages only to get a rough figure on the number of sites that support HTTP/2 (at least on their home page). Figure 3 shows less support than overall requests, as expected, at around 36%:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ProtocolDesktopMobileBoth
    0.09%0.08%0.08%
    HTTP/1.00.09%0.08%0.09%
    HTTP/1.162.36%63.92%63.22%
    HTTP/237.46%35.92%36.61%
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ProtocolDesktopMobileBoth
    0.09%0.08%0.08%
    HTTP/1.00.09%0.08%0.09%
    HTTP/1.162.36%63.92%63.22%
    HTTP/237.46%35.92%36.61%
    +

    Figure 3 - HTTP version usage for home pages

    HTTP/2 is only supported by browsers over HTTPS, even though officially HTTP/2 can be used over HTTPS or over unencrypted non-HTTPS connections. As mentioned previously, hiding the new protocol in encrypted HTTPS connections prevents networking appliances which do not understand this new protocol from interfering with (or rejecting!) its usage. Additionally, the HTTPS handshake allows an easy method of the client and server agreeing to use HTTP/2. The web is moving to HTTPS and HTTP/2 turns the traditional argument of HTTPS being bad for performance almost completely on its head. Not every site has made the transition to HTTPS, so HTTP/2 will not even be available to those that have not. Looking at just those sites that use HTTPS, we do see a higher percentage support HTTP/2 at around 55% - similar to the first all requests statistic we started with:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ProtocolDesktopMobileBoth
    0.09%0.10%0.09%
    HTTP/1.00.06%0.06%0.06%
    HTTP/1.145.81%44.31%45.01%
    HTTP/254.04%55.53%54.83%
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ProtocolDesktopMobileBoth
    0.09%0.10%0.09%
    HTTP/1.00.06%0.06%0.06%
    HTTP/1.145.81%44.31%45.01%
    HTTP/254.04%55.53%54.83%
    +

    Figure 4 - HTTP version usage for HTTPS home pages

    We have shown that browser support is strong, and there is a safe road to adoption, so why does every site (or at least every HTTPS site) not support HTTP/2? Well here we come to the final item for support we have not measured yet: server support. This is more problematic than browser support as, unlike modern browsers, servers often do not automatically upgrade to the latest version. Even when the server is regularly maintained and patched that will often just apply security patches rather than new features like HTTP/2. Let us look first at the server HTTP header for those sites that do support HTTP/2:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ServerDesktopMobileBoth
    nginx34.04%32.48%33.19%
    cloudflare23.76%22.29%22.97%
    Apache17.31%19.11%18.28%
    4.56%5.13%4.87%
    LiteSpeed4.11%4.97%4.57%
    GSE2.16%3.73%3.01%
    Microsoft-IIS3.09%2.66%2.86%
    openresty2.15%2.01%2.07%
    …………
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ServerDesktopMobileBoth
    nginx34.04%32.48%33.19%
    cloudflare23.76%22.29%22.97%
    Apache17.31%19.11%18.28%
    4.56%5.13%4.87%
    LiteSpeed4.11%4.97%4.57%
    GSE2.16%3.73%3.01%
    Microsoft-IIS3.09%2.66%2.86%
    openresty2.15%2.01%2.07%
    …………
    +

    Figure 5 - Servers used for HTTP/2

    Nginx provides package repos that allow ease of installing or upgrading to the latest version, so it is no surprise to see it leading the way here. Cloudflare is the most popular CDNs and enables HTTP/2 by default so again it is also not surprising to see this as a large percentage of HTTP/2 sites. Incidently, Cloudflare uses a heavily customised version of nginx as their web server. After this we see Apache at around 20% of usage, followed by some servers who choose to hide what they are and then the smaller players (LiteSpeed, IIS, Google Servlet Engine and openresty - which is nginx based).

    What is more interesting is those sites that that do not support HTTP/2:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ServerDesktopMobileBoth
    Apache46.76%46.84%46.80%
    nginx21.12%21.33%21.24%
    Microsoft-IIS11.30%9.60%10.36%
    7.96%7.59%7.75%
    GSE1.90%3.84%2.98%
    cloudflare2.44%2.48%2.46%
    LiteSpeed1.02%1.63%1.36%
    openresty1.22%1.36%1.30%
    …………
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ServerDesktopMobileBoth
    Apache46.76%46.84%46.80%
    nginx21.12%21.33%21.24%
    Microsoft-IIS11.30%9.60%10.36%
    7.96%7.59%7.75%
    GSE1.90%3.84%2.98%
    cloudflare2.44%2.48%2.46%
    LiteSpeed1.02%1.63%1.36%
    openresty1.22%1.36%1.30%
    …………
    +

    Figure 6 - Servers used for HTTP/1.1 or lower

    Some of this will be non-HTTPS traffic that would use HTTP/1.1 even if the server supported HTTP/2, but a bigger issue is those that do not support HTTP/2. In these stats we see a much greater share for Apache and IIS which are likely running older versions. For Apache in particular it is often not easy to add HTTP/2 support to an existing installation as Apache does not provide an official repository to install this from. This often means resorting to compiling from source or trusting a third-party repo - neither of which is particularly appealing to many administrators. Only the latest versions of Linux distributions (RHEL and CentOS 8, Ubuntu 18 and Debian 9) come with a version of Apache which supports HTTP/2 and many servers are not running those yet. On the Microsoft side only Windows Server 2016 and above supports HTTP/2 so again those running older versions cannot support this in IIS. Merging these two stats together we can see the percentage of installs, of each server, that uses HTTP/2:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ServerDesktopMobile
    cloudflare85.40%83.46%
    LiteSpeed70.80%63.08%
    openresty51.41%45.24%
    nginx49.23%46.19%
    GSE40.54%35.25%
    25.57%27.49%
    Apache18.09%18.56%
    Microsoft-IIS14.10%13.47%
    ………
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ServerDesktopMobile
    cloudflare85.40%83.46%
    LiteSpeed70.80%63.08%
    openresty51.41%45.24%
    nginx49.23%46.19%
    GSE40.54%35.25%
    25.57%27.49%
    Apache18.09%18.56%
    Microsoft-IIS14.10%13.47%
    ………
    +

    Figure 7 - percentage installs of each server used to provide HTTP/2

    It's clear Apache and IIS fall way behind with 18% and 14% of their installed based supporting HTTP/2, and this has to be at least in part, a consequence of it being more difficult to upgrade them. A full operating system upgrade is often required for many to get this support easily. Hopefully this will get easier as new versions of operating systems become the norm. None of this is a comment on the HTTP/2 implementations here (I happen to think Apache has one of the best implementations), but more in the ease of enabling HTTP/2 in each of these servers - or lack thereof.

    Impact of HTTP/2

    @@ -507,50 +519,54 @@

    HTTP/2 Push

    The reality has been… well, a bit disappointing. HTTP/2 push has proved much harder than originally envisaged to use effectively. Some of this has been due to the complexity of how HTTP/2 push works, and the implementation issues due to that. A bigger concern is that push can quite easily cause, rather than solve, performance issues. Over-pushing is a real risk. Often the browser is in the best place to decide what to request, and just as crucially when to request it but HTTP/2 push puts that responsibility on the server. Pushing resources that a browser already has in its cache, is a waste of bandwidth (though in my opinion so is inlining CSS but that gets must less of a hard time about that than HTTP/2 push!). Proposals to inform the server about the status of the browser cache have stalled especially on privacy concerns. Even without that problem, there are other potential issues if push is not used correctly. For example, pushing large images and therefore holding up the sending of critical CSS and JavaScript will lead to slower websites than if you'd not pushed at all!

    There has also been very little evidence to date that push, even when implemented correctly, results in the performance increase it promised. This is an area that again the HTTP Archive is not best placed to answer, due to the nature of how it runs (a month crawl of popular sites using Chrome in one state) so we won't delve into it too much here, but suffice to say that the performance gains are far from clear cut and the potential problems are real.

    Putting that aside let's look at the usage of HTTP/2 push:

    - - - - - - - - - - - - - - - - - - - - -
    ClientSites Using HTTP/2 PushSites Using HTTP/2 Push (%)
    Desktop22,5810.52%
    Mobile31,4520.59%
    +
    + + + + + + + + + + + + + + + + + + + + +
    ClientSites Using HTTP/2 PushSites Using HTTP/2 Push (%)
    Desktop22,5810.52%
    Mobile31,4520.59%
    +

    Figure 10 - Sites using HTTP/2 push

    These status show that the uptick of HTTP/2 push is very low - most likely because of the issues described previously. However, when sites do use push, then tend to use it a lot rather than for one or two assets as shown in Figure 11:

    - - - - - - - - - - - - - - - - - - - - -
    ClientAvg Pushed RequestsAvg KB Pushed
    Desktop7.86162.38
    Mobile6.35122.78
    +
    + + + + + + + + + + + + + + + + + + + + +
    ClientAvg Pushed RequestsAvg KB Pushed
    Desktop7.86162.38
    Mobile6.35122.78
    +

    Figure 11 - How much is pushed when it is used

    This is a concern as previous advice has been to be conservative with push and to "push just enough resources to fill idle network time, and no more". The above statistics suggest many resources, of a significant combined size are pushed. Looking at what is pushed we see the data in Figure 12:

    What asset types is push used for?

    @@ -563,103 +579,105 @@

    HTTP/2 Push

    HTTP/2 Issues

    HTTP/2 is mostly a seamless upgrade that, once your server supports it, you can switch on with no need to change your website or application. Of course, you can optimize for HTTP/2 or stop using HTTP/1.1 workarounds as much, but in general a site will usually work without needing any changes - but just be faster. There are a couple of gotchas to be aware of however that can impact any upgrade and some sites have found these out the hard way.

    One cause of issues in HTTP/2 is the poor support of HTTP/2 prioritization. This feature allows multiple requests in progress to make the appropriate use of the connection. This is especially important since HTTP/2 has massively increased the number of requests that can be running on the same connection. 100 or 128 parallel requests limits are common in server implementations. Previously the browser had a max of 6 connections per domain and so used its skill and judgement to decide how best to use those connections. Now it rarely needs to queue and can send all requests as soon as it knows about them. This then can lead to the bandwidth being "wasted" on lower priority requests while critical requests are delayed (and incidentally can also lead to swamping your backend server with more requests than it is used to!). HTTP/2 has a complex prioritization model (too complex many say - hence why it is being reconsidered for HTTP/3!) but few servers honor that properly. This can be because their HTTP/2 implementations are not up to scratch or because of so called bufferbloat where the responses are already en route before the server realizes there is a higher priority request. Due to the varying nature of servers, TCP stacks and locations it is difficult to measure this for most sites, but with CDNs this should be more consistent. Patrick Meenan created an example test page which deliberately tries to download a load of low-priority, off-screen, images, before requesting some high priority on-screen images. A good HTTP/2 server should be able to recognize this and send the high priority images shortly after requested, at the expense of the lower priority images. A poor HTTP/2 server will just respond in the request order and ignore any priority signals. Andy Davies has a page tracking status of various CDNs for Patrick's test. The HTTP Archive identifies when a CDN is used as part of its crawl and merging these two datasets that gives us the results shown in Figure 13:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    CDNPrioritizes Correctly?DesktopMobileBoth
    Not using CDNUnknown57.81%60.41%59.21%
    CloudflarePass23.15%21.77%22.40%
    GoogleFail6.67%7.11%6.90%
    Amazon CloudFrontFail2.83%2.38%2.59%
    FastlyPass2.40%1.77%2.06%
    AkamaiPass1.79%1.50%1.64%
    Unknown1.32%1.58%1.46%
    WordPressPass1.12%0.99%1.05%
    Sucuri FirewallFail0.88%0.75%0.81%
    IncapsulaFail0.39%0.34%0.36%
    NetlifyFail0.23%0.15%0.19%
    OVH CDNUnknown0.19%0.18%0.18%
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    CDNPrioritizes Correctly?DesktopMobileBoth
    Not using CDNUnknown57.81%60.41%59.21%
    CloudflarePass23.15%21.77%22.40%
    GoogleFail6.67%7.11%6.90%
    Amazon CloudFrontFail2.83%2.38%2.59%
    FastlyPass2.40%1.77%2.06%
    AkamaiPass1.79%1.50%1.64%
    Unknown1.32%1.58%1.46%
    WordPressPass1.12%0.99%1.05%
    Sucuri FirewallFail0.88%0.75%0.81%
    IncapsulaFail0.39%0.34%0.36%
    NetlifyFail0.23%0.15%0.19%
    OVH CDNUnknown0.19%0.18%0.18%
    +

    Figure 13 - HTTP/2 prioritization support in common CDNs

    This shows that a not insignificant portion of traffic is subject to the identified issue. How much of a problem this is, depends on exactly how your page loads and whether high priority resources are discovered late or not for your site, but it does show another complexity to take into considerations.

    Another issue is with the upgrade HTTP header being used incorrectly. Web servers can respond to requests with an upgrade HTTP header suggesting that it supports a better protocol that the client might wish to use (e.g. advertise HTTP/2 to a client only using HTTP/1.1). You might think this would be useful as a way of informing the browser it supports HTTP/2 but since browsers only support HTTP/2 over HTTPS and since use of HTTP/2 can be negotiated through the HTTPS handshake, the use of this upgrade header for advertising HTTP/2 is pretty limited (to browsers at least). Worse than that, is when a server sends an upgrade header in error. This could be because an HTTP/2 supporting backend server is sending the header and then an HTTP/1.1-only edge server is blindly forwarding to the client. Apache emits the upgrade header when mod_http2 is enabled but HTTP/2 is not being used, and a nginx instance sitting in front of such an Apache happily forwards this header even when nginx does not support HTTP/2. This false advertising then leads to clients trying (and failing!) to use HTTP/2 as they are advised to. 108 site use HTTP/2 and yet suggest upgrading to HTTP/2 in this upgrade header. A further 12,767 sites on desktop (15,235 on mobile) suggest upgrading an HTTP/1.1 connection delivered over HTTPS to HTTP/2 when it's clear this was not available, or it would have been used already. These are a small minority of the 4.3 million sites crawled on desktop and 5.3 million sites crawled on mobile for these stats but it shows that this was still an issue affecting a number of sites out there. Browsers handle this inconsistently with Safari in particular attempting to upgrade and then getting itself in a mess and refusing to display the site at all. All this is before we get into sites recommending upgrading to http1.0, http://1.1 or even -all,+TLSv1.3,+TLSv1.2 (clearly some typos in web server configurations going on here!).

    diff --git a/src/templates/en/2019/chapters/markup.html b/src/templates/en/2019/chapters/markup.html index 6c41b41664b..a0caf83e354 100644 --- a/src/templates/en/2019/chapters/markup.html +++ b/src/templates/en/2019/chapters/markup.html @@ -169,59 +169,63 @@

    Methodology

    Top elements and general info

    In 2005, Hixie's survey listed the top few most commonly used elements on pages. The top 3 were html, head and body which he noted as interesting because they are optional and created by the parser if omitted. Given that we use the post-parsed DOM, they'll show up universally in our data. Thus, we'll begin with the 4th most used element. Below is a comparison of the data from then to now (I've included the frequency comparison here as well just for fun).

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    2005 (per site)2019 (per site)2019 (frequency)
    titletitlediv
    ametaa
    imgaspan
    metadivli
    brlinkimg
    tablescriptscript
    tdimgp
    trspanoption
    -

    Figure 1. Comparison of the top elements from 2005 to 2019.

    +
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    2005 (per site)2019 (per site)2019 (frequency)
    titletitlediv
    ametaa
    imgaspan
    metadivli
    brlinkimg
    tablescriptscript
    tdimgp
    trspanoption
    +
    +

    +
    Figure 1. Comparison of the top elements from 2005 to 2019.
    +

    Elements per page

    @@ -229,7 +233,7 @@

    Elements per page

    Figure 2. Distribution of Hixie's 2005 analysis of element frequencies.
    - +
    Figure 3. Element frequencies as of 2019.

    Comparing the latest data in Figure 3 to that of Hixie's report from 2005 in Figure 2, we can see that the average size of DOM trees has gotten bigger.

    @@ -238,7 +242,7 @@

    Elements per page

    Figure 4. Histogram of Hixie's 2005 analysis of element types per page.
    - +
    Figure 5. Histogram of element types per page as of 2019.

    We can see that both the average number of types of elements per page has increased, as well as the maximum numbers of unique elements that we encounter.

    @@ -270,14 +274,14 @@

    Custom elements

    Additionally, 15% of desktop pages and 16% of mobile pages contain deprecated elements.

    - +
    Figure 6. Most frequently used deprecated elements.

    Figure 6 above shows the top 10 most frequently used deprecated elements. Most of these can seem like very small numbers, but perspective matters.

    Perspective on value and usage

    In order to discuss numbers about the use of elements (standard, deprecated or custom), we first need to establish some perspective.

    - +
    Figure 7. Top 150 elements.

    In Figure 7 above, the top 150 element names, counting the number of pages where they appear, are shown. Note how quickly use drops off.

    @@ -375,7 +379,7 @@

    Products (and libraries)

    Let's compare these to a few of the native HTML elements that are below the 5% bar, for perspective.

    - +
    Figure 9. Popularity of product-specific and native elements under 5% adoption.

    You could discover interesting insights like these all day long.

    @@ -402,7 +406,7 @@

    Products (and libraries)

    Placing these into our same chart as above for perspective looks something like this (again, it varies slightly based on the dataset)

    - +
    Figure 10. Other popular elements in the context of product-specific and native elements with under 5% adoption.

    The interesting thing about these results is that they also introduce a few other ways that our tool can come in very handy. If we're interested in exploring the space of the data, a very specific tag name is just one possible measure. It's definitely the strongest indicator if we can find good "slang" developing. However, what if that's not all we're interested in?

    diff --git a/src/templates/en/2019/chapters/media.html b/src/templates/en/2019/chapters/media.html index 0071ede7e44..79ecc55dd6c 100644 --- a/src/templates/en/2019/chapters/media.html +++ b/src/templates/en/2019/chapters/media.html @@ -145,7 +145,7 @@

    Introduction

    For the median web page on desktop, only 46% of the display would have layout containing images and video. In contrast, on mobile, the volume of media pixels fills 3.5 times the actual viewport size. The layout has more content than can be filled in a single screen, requiring the user to scroll. At a minimum, there is 3.5 scrolling pages of content per site (assuming 100% saturation). At the 90th percentile for mobile, this grows substantially to 25x the viewport size!

    Media resources are critical for the user experience!

    Images

    -

    Much has already been written on the subject of managing and optimizing images to help reduce the bytes and optimize the user experience. <> It is an important and critical topic for many because it is the creative media that define a brand experience. Therefore optimizing image and video content is a balancing act between applying best practices that can help reduce the bytes transferred over the network while preserving the fidelity of the intended experience.

    +

    Much has already been written on the subject of managing and optimizing images to help reduce the bytes and optimize the user experience. <<TODO: link, link link>> It is an important and critical topic for many because it is the creative media that define a brand experience. Therefore optimizing image and video content is a balancing act between applying best practices that can help reduce the bytes transferred over the network while preserving the fidelity of the intended experience.

    While the strategies that are utilized for images, videos and animations are, in broad strokes similar, the specific approaches can be very different. In general, these strategies boil down to:

    • File Formats - utilizing the optimal file format

      • @@ -156,235 +156,243 @@

      Images

    It is rare to find a webpage that does not utilize images. Over the years, many different file formats have emerged to help present content on the web - each addressing a different problem. Predominantly there are 4 main universal image formats: JPEG, PNG, GIF, and SVG. In addition, Chrome has enhanced the media pipeline and added support for a fifth image format - WebP. Other browsers have likewise added support for JPEG2000 (Safari), JPEG-XL (IE and Edge) and HEIC (WebView only in Safari)

    Each format has its own merits and has ideal uses for the web. A very simplified summary would break down as:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    FormatHighlightsDrawbacks
    JPEG* ubiquitously supported
    * ideal for photographic content    		* there is always quality loss
    * most decoders cannot handle high bit depth photographs from modern cameras (> 8 bits per channel)
    * no support for transparency
    PNG - * like JPEG and GIF, shares wide support
    - *it is lossless
    - * supports transparency, animation, and high bit depth -     		- * much bigger files compared to JPEG
    - * not ideal for photographic content -
    GIF* the predecessor to PNG, is most known for animations
    * lossless    		* because of the limitation of 256 colors, there is always visual loss from conversion
    *very large files for animations
    SVG - * A vector based format that can be resized without increasing filesize
    - * It is based on math rather than pixels and creates smooth lines -     		* not useful for photographic or other raster content
    WebP - * a newer file format that can produce lossless images like PNG and lossy images like JPEG
    - * It boasts a 30% average file reduction compared to JPEG, while other data suggests that median file reduction is between 10-28% based on pixel volume. -     		- * Unlike JPEG, it is limited to chroma-subsampling which will make some images appear blurry.
    - *not universally supported. Only Chrome, Firefox and Android ecosystems.
    - * fragmented feature support depending on browser versions -
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FormatHighlightsDrawbacks
    JPEG* ubiquitously supported
    * ideal for photographic content    		* there is always quality loss
    * most decoders cannot handle high bit depth photographs from modern cameras (> 8 bits per channel)
    * no support for transparency
    PNG + * like JPEG and GIF, shares wide support
    + *it is lossless
    + * supports transparency, animation, and high bit depth +     		+ * much bigger files compared to JPEG
    + * not ideal for photographic content +
    GIF* the predecessor to PNG, is most known for animations
    * lossless    		* because of the limitation of 256 colors, there is always visual loss from conversion
    *very large files for animations
    SVG + * A vector based format that can be resized without increasing filesize
    + * It is based on math rather than pixels and creates smooth lines +     		* not useful for photographic or other raster content
    WebP + * a newer file format that can produce lossless images like PNG and lossy images like JPEG
    + * It boasts a 30% average file reduction compared to JPEG, while other data suggests that median file reduction is between 10-28% based on pixel volume. +     		+ * Unlike JPEG, it is limited to chroma-subsampling which will make some images appear blurry.
    + *not universally supported. Only Chrome, Firefox and Android ecosystems.
    + * fragmented feature support depending on browser versions +
    +

    Image Formats

    In aggregate, across all page, we indeed see the prevalence of these formats. JPEG, one of the oldest formats on the web, is by far the most commonly used image formats at 60% of the image requests and 65% of all image bytes. Interestingly, PNG is the second most commonly used image format 28% of image requests and bytes. The ubiquity of support along with the precision of color and creative content are likely explanations for its wide use. In contrast SVG, GIF and WebP share nearly the same usage at 4%. (figure image formats by % of totla requests) Of course, web pages are not uniform in their use of image content. Some depend on images more than others. Look no further than the home page of Google.com and you will see very little imagery compared to a typical news website. Indeed, the median website has 13 images and 61 at the 90th percentile and a whopping 229 at the 99th percentile. (figure image frequency per page)

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Formatp10p25p50p75p90p99
    jpg0392039119
    png044101849
    webp0000028
    svg0000219
    gif0001214
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Formatp10p25p50p75p90p99
    jpg0392039119
    png044101849
    webp0000028
    svg0000219
    gif0001214
    +

    While the median page has 9 jpegs and 4 pngs, and only in the top 25% pages where use gifs, this doesn’t report the adoption rate. The use and frequency of each format per page doesn’t provide insight into the adoption of the more modern formats. Specifically, what % of pages include at least one image in each format?

    (figure % of pages using at least 1 image)

    This helps explain why even at the 90th percentile of pages the frequency of webp is still zero - only 9% of web pages have even 1 resource. There are many reasons that webp might not be the right choice for an image, but adoption of media best practices like adoption of webp still remain naicent.

    Image File Sizes

    There are two ways to look at image file sizes: absolute bytes per resource and bytes per pixel. Looking at the absolute bytes per resource, and we can look at the frequency of file sizes. (figure image format file size)

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Formatp10p25p50p75p90
    jpg4 KB9 KB24 KB68 KB166 KB
    png2 KB4 KB11 KB43 KB152 KB
    webp4 KB7 KB17 KB41 KB90 KB
    gif2 KB3 KB6 KB17 KB87 KB
    svg0 KB0 KB1 KB2 KB8 KB
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Formatp10p25p50p75p90
    jpg4 KB9 KB24 KB68 KB166 KB
    png2 KB4 KB11 KB43 KB152 KB
    webp4 KB7 KB17 KB41 KB90 KB
    gif2 KB3 KB6 KB17 KB87 KB
    svg0 KB0 KB1 KB2 KB8 KB
    +

    From this we can start to get a sense of how large or small a typical resource is on the web. However, this doesn’t give us a sense of the volume of pixels represented on screen for these file distributions. To do this we can divide each resource bytes by the natural pixel volume of the image. A lower Bytes-Per-Pixel indicates a more efficient transmission of visual content. (figure Bytes per pixel)

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    imageTypeBytes Per Pixel: p10Bytes Per Pixel: p25Bytes Per Pixel: p50Bytes Per Pixel: p75Bytes Per Pixel: p90
    jpg0.11750.18480.29970.54560.9822
    png0.11970.28740.69181.45482.5026
    gif0.17020.36410.79672.5158.5151
    webp0.05860.10250.1830.32720.6474
    svg0.02930.1740.67661.92614.1075
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    imageTypeBytes Per Pixel: p10Bytes Per Pixel: p25Bytes Per Pixel: p50Bytes Per Pixel: p75Bytes Per Pixel: p90
    jpg0.11750.18480.29970.54560.9822
    png0.11970.28740.69181.45482.5026
    gif0.17020.36410.79672.5158.5151
    webp0.05860.10250.1830.32720.6474
    svg0.02930.1740.67661.92614.1075
    +

    While previously it appeared that GIF files were smaller than JPEG, we can now clearly see that the cause of the larger JPEG resources is due to the pixel volume. It is probably not a surprise that GIF shows a very low pixel density compared to the other formats. Additionally, PNG, while it can handle high bit depth and doesn’t suffer from chroma subsampling blurriness, is about twice the size of JPG or WebP for the same pixel volume.

    Of note, the pixel volume used for SVG is the size of the DOM element on screen (in CSS pixels). While considerably smaller for file sizes, this hints that SVGs are generally used in smaller portions of the layout. This is why the bytes per pixel appears worse than PNG.

    Again it is worth emphasizing, this comparison of pixel density is not comparing equivalent images. Rather it is reporting typical user experience. As we will discuss next, even in each of these formats there are techniques that can be used to further optimize and reduce the bytes per pixel.

    diff --git a/src/templates/en/2019/chapters/mobile-web.html b/src/templates/en/2019/chapters/mobile-web.html index 052cace36bc..07ccc0c580a 100644 --- a/src/templates/en/2019/chapters/mobile-web.html +++ b/src/templates/en/2019/chapters/mobile-web.html @@ -209,33 +209,36 @@

    The page loading experience

    The first part of the mobile web experience we analyzed is the one we're all most intimately familiar with: the page loading experience. But before we start diving into our findings, let's make sure we're all on the same page regarding what the typical mobile user really looks like. Because this will not only help you reproduce these results, but understand these users better.

    Let's start with what phone the typical mobile user has. The average Android phone is ~$250, and one of the most popular phones in that range is a Samsung Galaxy S6. So this is likely the kind of phone they use, which is actually 4x slower than an iPhone 8. This user doesn't have access to a fast 4G connection, but rather a 2G connection (29% of the time) or 3G connection (28% of the time). And this is what it all adds up to:

    - - - - - - - - - - - - - - - - - -
    Connection type2G or 3G
    Latency300 - 400ms
    Bandwidth0.4 - 1.6Mbps
    PhoneGalaxy S6 — 4x slower than iPhone 8 (Octane V2 score)
    - +
    + + + + + + + + + + + + + + + + + + + +
    Connection type2G or 3G
    Latency300 - 400ms
    Bandwidth0.4 - 1.6Mbps
    PhoneGalaxy S6 — 4x slower than iPhone 8 (Octane V2 score)
    +
    Figure 1. Technical profile of a typical mobile user.

    I imagine some of you are surprised by these results. They may be far worse conditions than you've ever tested your site with. But now that we're all on the same page with what a mobile user truly looks like, let's get started.

    Pages bloated with JavaScript

    -

    The state of JavaScript on the mobile web is terrifying. According to HTTP Archive's JavaScript report, the median mobile site requires phones to download 375 KB of JavaScript. Assuming a 70% compression ratio, this means that phones have to parse, compile, and execute 1.25 MB of JavaScript at the median.

    -

    Why is this a problem? Because sites loading this much JS take upwards of 10 seconds to become interactive. Or in other words, your page may appear fully loaded, but when a user clicks any of your buttons or menus, nothing happens because the JavaScript hasn't finished executing. Users are forced to keep clicking the button for upwards of 10 seconds, just waiting for that magical moment where something actually happens. Think about how confusing and frustrating that can be.

    +

    The state of JavaScript on the mobile web is terrifying. According to HTTP Archive's JavaScript report, the median mobile site requires phones to download 375 KB of JavaScript. Assuming a 70% compression ratio, this means that phones have to parse, compile, and execute 1.25 MB of JavaScript at the median.

    +

    Why is this a problem? Because sites loading this much JS take upwards of 10 seconds to become interactive. Or in other words, your page may appear fully loaded, but when a user clicks any of your buttons or menus, nothing happens because the JavaScript hasn't finished executing. Users are forced to keep clicking the button for upwards of 10 seconds, just waiting for that magical moment where something actually happens. Think about how confusing and frustrating that can be.

    - +
    Figure 2. Example of how painful of an experience waiting for JS to load can be.

    Let's delve deeper and look at another metric that focuses more on how well each page utilizes JavaScript. For example, does it really need as much JavaScript as it's loading? We call this metric the JavaScript Bloat Score, based on the web bloat score. The idea behind it is this:

    @@ -314,7 +317,7 @@

    Zooming and scaling

    - +
    Figure 5. Percent of desktop and mobile websites that enable or disable zooming/scaling.
    @@ -344,25 +347,28 @@

    New input types

    Many new input types have since been introduced, allowing developers to inform browsers what kind of data is expected, and enable browsers to provide customized keyboards specifically for these input types. For example, a type of email provides users with an alphanumeric keyboard including the "@" symbol, and a type of tel will display a numeric keypad.

    When analyzing sites containing an email input, 56.42% use type="email". Similarly, for phone inputs, type="tel" is used 36.7% of the time. Other new input types have an even lower adoption rate.

    - - - - - - - - - - - - - - - - - -
    TypeFrequency (pages)
    phone1,917
    name1,348
    textbox833
    - +
    + + + + + + + + + + + + + + + + + + + +
    TypeFrequency (pages)
    phone1,917
    name1,348
    textbox833
    +
    Figure 7. Most commonly used invalid input types

    Make sure to educate yourself and others on the large amount of input types available and double-check that you don't have any typos like the most common ones in Figure 7 above.

    @@ -388,7 +394,7 @@

    Conclusion

    A 1000 hour free-trial CD for America Online
    1000 hours of America Online for free, from archive.org.
    -