diff --git a/.github/workflows/calibreapp-image-action.yml b/.github/workflows/calibreapp-image-action.yml new file mode 100644 index 00000000000..3d95fd0c8c7 --- /dev/null +++ b/.github/workflows/calibreapp-image-action.yml @@ -0,0 +1,12 @@ +name: Compress images +on: pull_request +jobs: + build: + name: calibreapp/image-actions + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@master + - name: calibreapp/image-actions + uses: docker://calibreapp/github-image-actions + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/sql/2019/07_Performance/07_03.sql b/sql/2019/07_Performance/07_03.sql index 33c09e3215d..404c7a0e4bb 100644 --- a/sql/2019/07_Performance/07_03.sql +++ b/sql/2019/07_Performance/07_03.sql @@ -1,9 +1,9 @@ #standardSQL # 07_03: % fast FCP per PSI SELECT - ROUND(COUNTIF(fast_fcp >= .9) * 100 / COUNT(0), 2) AS pct_fast_fcp, - ROUND(COUNTIF(NOT(slow_fcp >= .1) AND NOT(fast_fcp >= .9)) * 100 / COUNT(0), 2) AS pct_avg_fcp, - ROUND(COUNTIF(slow_fcp >= .1) * 100 / COUNT(0), 2) AS pct_slow_fcp + ROUND(COUNTIF(fast_fcp >= .75) * 100 / COUNT(0), 2) AS pct_fast_fcp, + ROUND(COUNTIF(NOT(slow_fcp >= .25) AND NOT(fast_fcp >= .75)) * 100 / COUNT(0), 2) AS pct_avg_fcp, + ROUND(COUNTIF(slow_fcp >= .25) * 100 / COUNT(0), 2) AS pct_slow_fcp FROM `chrome-ux-report.materialized.metrics_summary` WHERE diff --git a/sql/2019/07_Performance/07_03b.sql b/sql/2019/07_Performance/07_03b.sql index 1f759b588b6..c142630463b 100644 --- a/sql/2019/07_Performance/07_03b.sql +++ b/sql/2019/07_Performance/07_03b.sql @@ -2,9 +2,9 @@ # 07_03b: % fast FCP per PSI by device SELECT device, - ROUND(COUNTIF(fast_fcp >= .9) * 100 / COUNT(0), 2) AS pct_fast_fcp, - ROUND(COUNTIF(NOT(slow_fcp >= .1) AND NOT(fast_fcp >= .9)) * 100 / COUNT(0), 2) AS pct_avg_fcp, - ROUND(COUNTIF(slow_fcp >= .1) * 100 / COUNT(0), 2) AS pct_slow_fcp + ROUND(COUNTIF(fast_fcp >= .75) * 100 / COUNT(0), 2) AS pct_fast_fcp, + ROUND(COUNTIF(NOT(slow_fcp >= .25) AND NOT(fast_fcp >= .75)) * 100 / COUNT(0), 2) AS pct_avg_fcp, + ROUND(COUNTIF(slow_fcp >= .25) * 100 / COUNT(0), 2) AS pct_slow_fcp FROM ( SELECT device, diff --git a/sql/2019/07_Performance/07_03c.sql b/sql/2019/07_Performance/07_03c.sql index 537f8ffcaa6..2fbf1650da6 100644 --- a/sql/2019/07_Performance/07_03c.sql +++ b/sql/2019/07_Performance/07_03c.sql @@ -2,15 +2,15 @@ # 07_03c: % fast FCP per PSI by ECT SELECT speed, - ROUND(COUNTIF(fast_fcp >= .9) * 100 / COUNT(0), 2) AS pct_fast_fcp, - ROUND(COUNTIF(NOT(slow_fcp >= .1) AND NOT(fast_fcp >= .9)) * 100 / COUNT(0), 2) AS pct_avg_fcp, - ROUND(COUNTIF(slow_fcp >= .1) * 100 / COUNT(0), 2) AS pct_slow_fcp + ROUND(COUNTIF(fast_fcp >= .75) * 100 / COUNT(0), 2) AS pct_fast_fcp, + ROUND(COUNTIF(NOT(slow_fcp >= .25) AND NOT(fast_fcp >= .75)) * 100 / COUNT(0), 2) AS pct_avg_fcp, + ROUND(COUNTIF(slow_fcp >= .25) * 100 / COUNT(0), 2) AS pct_slow_fcp FROM ( SELECT effective_connection_type.name AS speed, ROUND(SAFE_DIVIDE(SUM(IF(bin.start < 1000, bin.density, 0)), SUM(bin.density)), 4) AS fast_fcp, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 1000 AND bin.start < 2500, bin.density, 0)), SUM(bin.density)), 4) AS avg_fcp, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 2500, bin.density, 0)), SUM(bin.density)), 4) AS slow_fcp + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 1000 AND bin.start < 3000, bin.density, 0)), SUM(bin.density)), 4) AS avg_fcp, + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 3000, bin.density, 0)), SUM(bin.density)), 4) AS slow_fcp FROM `chrome-ux-report.all.201907`, UNNEST(first_contentful_paint.histogram.bin) AS bin diff --git a/sql/2019/07_Performance/07_03d.sql b/sql/2019/07_Performance/07_03d.sql index a60a337f54a..cf26543182c 100644 --- a/sql/2019/07_Performance/07_03d.sql +++ b/sql/2019/07_Performance/07_03d.sql @@ -244,15 +244,15 @@ WITH geos AS ( SELECT geo, COUNT(0) AS websites, - ROUND(COUNTIF(fast_fcp >= .9) * 100 / COUNT(0), 2) AS pct_fast_fcp, - ROUND(COUNTIF(NOT(slow_fcp >= .1) AND NOT(fast_fcp >= .9)) * 100 / COUNT(0), 2) AS pct_avg_fcp, - ROUND(COUNTIF(slow_fcp >= .1) * 100 / COUNT(0), 2) AS pct_slow_fcp + ROUND(COUNTIF(fast_fcp >= .75) * 100 / COUNT(0), 2) AS pct_fast_fcp, + ROUND(COUNTIF(NOT(slow_fcp >= .25) AND NOT(fast_fcp >= .75)) * 100 / COUNT(0), 2) AS pct_avg_fcp, + ROUND(COUNTIF(slow_fcp >= .25) * 100 / COUNT(0), 2) AS pct_slow_fcp FROM ( SELECT geo, ROUND(SAFE_DIVIDE(SUM(IF(bin.start < 1000, bin.density, 0)), SUM(bin.density)), 4) AS fast_fcp, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 1000 AND bin.start < 2500, bin.density, 0)), SUM(bin.density)), 4) AS avg_fcp, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 2500, bin.density, 0)), SUM(bin.density)), 4) AS slow_fcp + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 1000 AND bin.start < 3000, bin.density, 0)), SUM(bin.density)), 4) AS avg_fcp, + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 3000, bin.density, 0)), SUM(bin.density)), 4) AS slow_fcp FROM geos, UNNEST(first_contentful_paint.histogram.bin) AS bin diff --git a/sql/2019/07_Performance/07_04c.sql b/sql/2019/07_Performance/07_04c.sql index 867eebf4743..a8e32010c60 100644 --- a/sql/2019/07_Performance/07_04c.sql +++ b/sql/2019/07_Performance/07_04c.sql @@ -8,9 +8,9 @@ SELECT FROM ( SELECT effective_connection_type.name AS speed, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start < 50, bin.density, 0)), SUM(bin.density)), 4) AS fast_fid, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 50 AND bin.start < 250, bin.density, 0)), SUM(bin.density)), 4) AS avg_fid, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 250, bin.density, 0)), SUM(bin.density)), 4) AS slow_fid + ROUND(SAFE_DIVIDE(SUM(IF(bin.start < 100, bin.density, 0)), SUM(bin.density)), 4) AS fast_fid, + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 100 AND bin.start < 300, bin.density, 0)), SUM(bin.density)), 4) AS avg_fid, + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 300, bin.density, 0)), SUM(bin.density)), 4) AS slow_fid FROM `chrome-ux-report.all.201907`, UNNEST(experimental.first_input_delay.histogram.bin) AS bin diff --git a/sql/2019/07_Performance/07_04d.sql b/sql/2019/07_Performance/07_04d.sql index 8f68d6546df..81af78457e6 100644 --- a/sql/2019/07_Performance/07_04d.sql +++ b/sql/2019/07_Performance/07_04d.sql @@ -250,9 +250,9 @@ SELECT FROM ( SELECT geo, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start < 50, bin.density, 0)), SUM(bin.density)), 4) AS fast_fid, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 50 AND bin.start < 250, bin.density, 0)), SUM(bin.density)), 4) AS avg_fid, - ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 250, bin.density, 0)), SUM(bin.density)), 4) AS slow_fid + ROUND(SAFE_DIVIDE(SUM(IF(bin.start < 100, bin.density, 0)), SUM(bin.density)), 4) AS fast_fid, + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 100 AND bin.start < 300, bin.density, 0)), SUM(bin.density)), 4) AS avg_fid, + ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 300, bin.density, 0)), SUM(bin.density)), 4) AS slow_fid FROM geos, UNNEST(experimental.first_input_delay.histogram.bin) AS bin diff --git a/sql/2019/07_Performance/07_08.sql b/sql/2019/07_Performance/07_08.sql index c9bd4b06fea..3989c9f8ab0 100644 --- a/sql/2019/07_Performance/07_08.sql +++ b/sql/2019/07_Performance/07_08.sql @@ -1,9 +1,9 @@ #standardSQL # 07_08: % fast TTFB using FCP-like thresholds SELECT - ROUND(COUNTIF(fast_ttfb >= .9) * 100 / COUNT(0), 2) AS pct_fast_ttfb, - ROUND(COUNTIF(NOT(slow_ttfb >= .1) AND NOT(fast_ttfb >= .9)) * 100 / COUNT(0), 2) AS pct_avg_ttfb, - ROUND(COUNTIF(slow_ttfb >= .1) * 100 / COUNT(0), 2) AS pct_slow_ttfb + ROUND(COUNTIF(fast_ttfb >= .75) * 100 / COUNT(0), 2) AS pct_fast_ttfb, + ROUND(COUNTIF(NOT(slow_ttfb >= .25) AND NOT(fast_ttfb >= .75)) * 100 / COUNT(0), 2) AS pct_avg_ttfb, + ROUND(COUNTIF(slow_ttfb >= .25) * 100 / COUNT(0), 2) AS pct_slow_ttfb FROM `chrome-ux-report.materialized.metrics_summary` WHERE diff --git a/sql/2019/07_Performance/07_08d.sql b/sql/2019/07_Performance/07_08d.sql index 15b998a7877..302dd643024 100644 --- a/sql/2019/07_Performance/07_08d.sql +++ b/sql/2019/07_Performance/07_08d.sql @@ -244,9 +244,9 @@ WITH geos AS ( SELECT geo, COUNT(0) AS websites, - ROUND(COUNTIF(fast_ttfb >= .9) * 100 / COUNT(0), 2) AS pct_fast_ttfb, - ROUND(COUNTIF(NOT(slow_ttfb >= .1) AND NOT(fast_ttfb >= .9)) * 100 / COUNT(0), 2) AS pct_avg_ttfb, - ROUND(COUNTIF(slow_ttfb >= .1) * 100 / COUNT(0), 2) AS pct_slow_ttfb + ROUND(COUNTIF(fast_ttfb >= .75) * 100 / COUNT(0), 2) AS pct_fast_ttfb, + ROUND(COUNTIF(NOT(slow_ttfb >= .25) AND NOT(fast_ttfb >= .75)) * 100 / COUNT(0), 2) AS pct_avg_ttfb, + ROUND(COUNTIF(slow_ttfb >= .25) * 100 / COUNT(0), 2) AS pct_slow_ttfb FROM ( SELECT geo, @@ -255,7 +255,7 @@ FROM ( ROUND(SAFE_DIVIDE(SUM(IF(bin.start >= 1000, bin.density, 0)), SUM(bin.density)), 4) AS slow_ttfb FROM geos, - UNNEST(experimental.first_input_delay.histogram.bin) AS bin + UNNEST(experimental.time_to_first_byte.histogram.bin) AS bin GROUP BY origin, geo) diff --git a/src/config/2019.json b/src/config/2019.json index ba5cf9889f1..120545e3518 100644 --- a/src/config/2019.json +++ b/src/config/2019.json @@ -194,7 +194,8 @@ "name": "Ahmad Awais", "teams": [ "brainstormers", - "reviewers" + "reviewers", + "developers" ], "avatar_url": "https:\/\/avatars1.githubusercontent.com\/u\/960133?v=4&s=200", "website": "https:\/\/ahmadawais.com\/", @@ -325,7 +326,8 @@ "catalinred": { "name": "Catalin Rosu", "teams": [ - "reviewers" + "reviewers", + "developers" ], "avatar_url": "https:\/\/avatars3.githubusercontent.com\/u\/1867900?v=4&s=200", "website": "https:\/\/catalin.red\/", @@ -396,7 +398,7 @@ "analysts" ], "avatar_url": "https:\/\/avatars3.githubusercontent.com\/u\/1514288?v=4&s=200", - "website": "dougsillars.com", + "website": "https:\/\/dougsillars.com", "github": "dougsillars", "twitter": "dougsillars" }, @@ -414,7 +416,8 @@ "name": "Gabriel De Gennaro", "teams": [ "designers" - ] + ], + "website": "https:\/\/gabrieldegennaro.com" }, "GiacomoPignoni": { "name": "Giacomo Pignoni", @@ -506,6 +509,16 @@ "github": "hyperpress", "twitter": "jtteag" }, + "sirjonathan": { + "name": "Jonathan Wold", + "teams": [ + "reviewers" + ], + "avatar_url": "https:\/\/avatars3.githubusercontent.com\/u\/104149?v=4&s=200", + "website": "https:\/\/jonathanwold.com", + "github": "sirjonathan", + "twitter": "sirjonathan" + }, "JMPerez": { "name": "Jos\u00e9 M. P\u00e9rez", "teams": [ diff --git a/src/content/en/2019/ecommerce.md b/src/content/en/2019/ecommerce.md index a36793586fa..e53cf819bbb 100644 --- a/src/content/en/2019/ecommerce.md +++ b/src/content/en/2019/ecommerce.md @@ -6,37 +6,23 @@ authors: [samdutton, alankent] reviewers: [voltek62] --- -![](https://github.com/HTTPArchive/almanac.httparchive.org/raw/master/src/static/images//2019/13_Ecommerce/hero_xl.jpg) - ## Introduction -Nearly 10% of the home pages in this study were found to be on an ecommerce platform. - -This chapter summarises data for those pages. - -An 'ecommerce platform' is a set of software or services that enables you to create and operate an online store. There are several types of ecommerce platform. For example: +Nearly 10% of the home pages in this study were found to be on an ecommerce platform. An 'ecommerce platform' is a set of software or services that enables you to create and operate an online store. There are several types of ecommerce platform. For example: - Paid-for services such as [Shopify](https://www.shopify.com/) that host your store and help you get started. They provide website hosting, site and page templates, product-data management, shopping carts and payments. - Software platforms such as [Magento Open Source](https://magento.com/products/magento-open-source) which you set up, host and manage yourself. These platforms can be powerful and flexible but may be more complex to set up and run than services such as Shopify. - Hosted platforms such as [Magento Commerce](https://magento.com/products/magento-commerce) that offer the same features as their self-hosted counterparts, except that hosting is managed as a service by a third party. - +This analysis could only detect sites built on an ecommerce platform. This means that most large online stores and marketplaces — such as Amazon, JD, and eBay — are not included here. Also note that the data here is for home pages only: not category, product or other pages. ## Platform detection How do we check if a page is on an ecommerce platform? -- Detection is done through Wappalyzer: -Wappalyzer is a cross-platform utility that uncovers the technologies used on websites. It detects content management systems, eCommerce platforms, web servers, JavaScript frameworks, analytics tools and many more.[wappalyzer.com/categories/ecommerce](https://www.wappalyzer.com/categories/ecommerce). -- Wappalayzer signals are available at [github.com/AliasIO/Wappalyzer/blob/master/src/apps.json](https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json). +Detection is done through Wappalyzer. Wappalyzer is a cross-platform utility that uncovers the technologies used on websites. It detects content management systems, eCommerce platforms, web servers, JavaScript frameworks, analytics tools and many more.[wappalyzer.com/categories/ecommerce](https://www.wappalyzer.com/categories/ecommerce). Wappalayzer signals are available at [github.com/AliasIO/Wappalyzer/blob/master/src/apps.json](https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json). - +Page detection is not always reliable, and some sites explicitly block detection to protect against automated attacks. We might not be able to catch all websites that use a particular ecommerce platform, but we're confident that the ones we do detect are actually on that platform.
@@ -49,19 +35,11 @@ We might not be able to catch all websites that use a particular ecommerce platf
Figure 1. Total home pages requested in this study
---- - ## Ecommerce platforms found in this study -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=0) - -The Web Almanac study detected home pages on a total of 116 ecommerce platforms. - -Of these platforms, six got more than 0.1% each of all web page requests in this study, on either desktop or mobile. +The Web Almanac study detected home pages on a total of 116 ecommerce platforms. Of these platforms, six got more than 0.1% each of all web page requests in this study, on either desktop or mobile. In addition, these results do not show variation by country, by size of site, or other similar metrics. -**Please note: as stated above, platform detection is not always reliable. Notably, OpenCart often appears in top platform lists but had a lower rate of page detection in this study. ([BuiltWith](https://trends.builtwith.com/shop), for example, lists OpenCart as the fourth most popular ecommerce platform.)** - -In addition, these results do not show variation by country, by size of site, or other similar metrics. +**Please note, as stated above, platform detection is not always reliable. Notably, OpenCart often appears in top platform lists but had a lower rate of page detection in this study. [BuiltWith](https://trends.builtwith.com/shop), for example, lists OpenCart as the fourth most popular ecommerce platform. This may be a result of the data in this study being limited to home pages.**
// Chart 13_02: Top shops @@ -94,10 +72,7 @@ According to Web Almanac data there are 110 ecommerce platforms that each get le
Figure 4. Number of pages on each e-commerce platform: from the most popular to the least popular.
- -7.87% of all requests on mobile and 8.06% on desktop are for home pages on one of the top six ecommerce platforms. - -1.52% of requests on mobile and 1.59% on desktop are for home pages on the 110 other ecommerce platforms. +7.87% of all requests on mobile and 8.06% on desktop are for home pages on one of the top six ecommerce platforms. A further 1.52% of requests on mobile and 1.59% on desktop are for home pages on the 110 other ecommerce platforms.
// Chart 13_02: Percentage of home pages: top six versus long tail @@ -105,12 +80,8 @@ According to Web Almanac data there are 110 ecommerce platforms that each get le
Figure 5. Percentage of home pages: top six versus long tail.
---- - ## Ecommerce (all platforms) -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1381271632) - ### Mobile v desktop In total, 9.39% of all requests on mobile and 9.65% on desktop in this study were for home pages on ecommerce platforms. @@ -121,14 +92,10 @@ In total, 9.39% of all requests on mobile and 9.65% on desktop in this study wer
Figure 6. Percentage of home pages on an e-commerce platform.
-- Although the desktop proportion of requests was slightly higher overall, some popular platforms (including WooCommerce, PrestaShop and Shopware) actually got more mobile than desktop requests. - ---- +Although the desktop proportion of requests was slightly higher overall, some popular platforms (including WooCommerce, PrestaShop and Shopware) actually got more mobile than desktop requests. ## Total payload and requests -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1412602250) - 'Payload' means all the bytes to load a page, including HTML, CSS, JavaScript, JSON, XML, images, audio and video.
@@ -143,36 +110,17 @@ In total, 9.39% of all requests on mobile and 9.65% on desktop in this study wer
Figure 8. Total requests for pages on ecommerce platforms.
-### Note that… - -- As explained above: this study only covers requests for home pages. -- Many successful ecommerce sites such as Amazon and eBay are designed so requests don't block content rendering — even though their pages make a large number of requests and have a heavy total payload. In other words, good performance is not just about smaller payloads and less requests! - - -### What it means - -- The median desktop home page on an ecommerce platform loads 108 requests and 2.65 MB. -- The median for _all_ pages on desktop is [74 requests and 1.95 MB](https://httparchive.org/reports/page-weight#bytesTotal). In other words, median desktop home pages on ecommerce platforms from this study make nearly 50% more requests than other web pages, with payloads around 35% larger. -- By comparison, the [amazon.com](amazon.com) home page makes around 300 requests on first load, for a total payload of around 5 MB, and [ebay.com](ebay.com) makes around 150 requests for a total payload of approximately 3 MB. -- Total payload and number of requests for home pages on ecommerce platforms is slightly less on mobile at every percentile. -- Around 10% of all home pages on ecommerce platforms load more than 7MB and make over 200 requests. - -### Commentary +Note that, as explained above, this study only covers requests for home pages. Additionally many successful ecommerce sites such as Amazon and eBay are designed so requests don't block content rendering — even though their pages make a large number of requests and have a heavy total payload. In other words, good performance is not just about smaller payloads and less requests! -- See also: [Third party requests and bytes](https://docs.google.com/document/d/1Q1zJtNN-JAgFLt7DwJadNWlzpLri2Roskx05yvGckuQ/edit#heading=h.br1vwrxh7ciu). -- This data accounts for home page payload and requests without scrolling. Clearly there are a significant proportion of sites that appear to be retrieving more files (the median is over 100), with a larger total payload, than should be necessary for first load. +The median desktop home page on an ecommerce platform loads 108 requests and 2.65 MB. The median for _all_ pages on desktop is [74 requests and 1.95 MB](https://httparchive.org/reports/page-weight#bytesTotal). In other words, median desktop home pages on ecommerce platforms from this study make nearly 50% more requests than other web pages, with payloads around 35% larger. By comparison, the [amazon.com](amazon.com) home page makes around 300 requests on first load, for a total payload of around 5 MB, and [ebay.com](ebay.com) makes around 150 requests for a total payload of approximately 3 MB. The total payload and number of requests for home pages on ecommerce platforms is slightly less on mobile at every percentile but around 10% of all home pages on ecommerce platforms load more than 7MB and make over 200 requests. -### Suggested actions +This data accounts for home page payload and requests without scrolling. Clearly there are a significant proportion of sites that appear to be retrieving more files (the median is over 100), with a larger total payload, than should be necessary for first load. See also: [Third party requests and bytes](#third-party-requests-and-bytes) below. -- We need to do further research to better understand why so many home pages on ecommerce platforms make so many requests, and have such large payloads. (The authors regularly see home pages on ecommerce platforms that make hundreds of requests on first load, with multi-megabyte payloads.) If the number of requests and payload are a problem for performance, then how can they be reduced? - ---- +We need to do further research to better understand why so many home pages on ecommerce platforms make so many requests and have such large payloads. The authors regularly see home pages on ecommerce platforms that make hundreds of requests on first load, with multi-megabyte payloads. If the number of requests and payload are a problem for performance, then how can they be reduced? ## Requests and payload by type -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1722785114) - -The charts below are for desktop requests: see the spreadsheet for mobile stats. +The charts below are for desktop requests:
// Chart 13_09d: Ecommerce platforms: requests by type @@ -185,26 +133,12 @@ The charts below are for desktop requests: see the spreadsheet for mobile stats.
Figure 10. Ecommerce platforms: requests by type.
-### What it means - -- Images constitute the largest number of requests and the highest proportion of payload for home pages on ecommerce platforms. -- The median desktop ecommerce home page includes 39 images weighing 1,513.67 KB. +Images constitute the largest number of requests and the highest proportion of payload for home pages on ecommerce platforms. The median desktop ecommerce home page includes 39 images weighing 1,513.67 KB. -### Commentary - -- The number of JavaScript requests indicates that better bundling (and/or HTTP/2) could improve performance. JavaScript files are not significantly large in terms of total payload, but many separate requests are made. ([More than 40% of requests](https://httparchive.org/reports/state-of-the-web#h2) for all sites on the web are not via HTTP/2.) -- CSS files similarly have the third highest number of requests, but are generally small. Merging CSS files (and/or HTTP/2) could improve performance of such sites. -- In the authors' experience, many pages on ecommerce platforms have a high proportion of unused CSS and JavaScript. -- Videos may require a small number of requests, but (not surprisingly) consume a high proportion of the total bytes, particularly on sites with heavy payloads. - ---- +The number of JavaScript requests indicates that better bundling (and/or [HTTP/2](./http2)) could improve performance. JavaScript files are not significantly large in terms of total payload, but many separate requests are made. [More than 40% of requests](./http2#user-content-adoption-of-http2) for all sites in this study are not via HTTP/2. CSS files similarly have the third highest number of requests but are generally small. Merging CSS files (and/or HTTP/2) could improve performance of such sites. In the authors' experience, many pages on ecommerce platforms have a high proportion of unused CSS and JavaScript. Videos may require a small number of requests, but (not surprisingly) consume a high proportion of the total bytes, particularly on sites with heavy payloads. ## HTML payload size -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1709620354) - - -
// Chart 13_09d: Ecommerce platforms: distribution of HTML payload size // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=81509282 @@ -222,28 +156,12 @@ The charts below are for desktop requests: see the spreadsheet for mobile stats.
Figure 12. HTML payload size (KB)
-### Note that… - -- To reiterate: this study was only able to request home pages. -- HTML payload may include other code such as JSON, JavaScript or CSS in an HTML page request. - -### What it means - -- The median HTML payload size for home pages on ecommerce platforms is 33.8 KB on mobile and 35.56 KB on desktop. -- 10% of home pages on ecommerce platforms have an HTML payload of over 115 KB. - -### Commentary +Note that HTML payload may include other code such as JSON, JavaScript or CSS embedded directly in an HTML page itself, rather than referenced as external links. The median HTML payload size for home pages on ecommerce platforms is 33.8 KB on mobile and 35.56 KB on desktop. However 10% of home pages on ecommerce platforms have an HTML payload of over 115 KB. -- Mobile HTML payload sizes are not very different from desktop. In other words, it appears that sites are not delivering significantly different HTML files for different devices or viewport sizes. -- On many ecommerce sites, home page HTML payloads are large. It's not known from this study whether this is because of bloated HTML, or from other code (such as JSON) within HTML files. - ---- +Mobile HTML payload sizes are not very different from desktop. In other words, it appears that sites are not delivering significantly different HTML files for different devices or viewport sizes. On many ecommerce sites, home page HTML payloads are large. It's not known from this study whether this is because of bloated HTML, or from other code (such as JSON) within HTML files. ## Image stats -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=98135455) -![image](insert_image_url_here) -
// Chart 13_06: Image payload by percentile (KB) // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=916461214 @@ -276,71 +194,40 @@ The charts below are for desktop requests: see the spreadsheet for mobile stats.
Figure 16. 90th percentile image usage for home pages on ecommerce platforms
+Note that the data here is for page load without scrolling. -### Note that… - -- The data here is for page load without scrolling. - -### What it means - -- The median page on an ecommerce platform (for home pages from the Web Almanac data) has 37 images and an image payload of 1,517.16 KB on mobile, 40 images and 1,524.56 KB on desktop. -- 10% of home pages have 90 or more images and an image payload of nearly 6 MB. - -### Commentary +This shows that the median page on an ecommerce platform (for home pages from the Web Almanac data) has 37 images and an image payload of 1,517.16 KB on mobile, 40 images and 1,524.56 KB on desktop. 10% of home pages have 90 or more images and an image payload of nearly 6 MB. -- A significant proportion of home pages on ecommerce platforms have sizeable image payloads and make a large number of image requests on first load. See [httparchive.org/reports/state-of-images](https://httparchive.org/reports/state-of-images) for context on the state of images globally. -- Website owners want their sites to look good on modern devices. As a result, many sites deliver the same high resolution product images to every user without regard for screen resolution or size. Developers may not be aware of (or not want to use) responsive techniques that enable efficient delivery of the best possible image to different users. -- It's worth remembering that high-resolution images may not necessarily increase conversion rates. Conversely, overuse of heavy images is likely to impact page speed, and can thereby _reduce_ conversion rates. -- In the authors' experience from site reviews and events, some developers and other stakeholders have SEO or other concerns about using lazy loading for images. +A significant proportion of home pages on ecommerce platforms have sizeable image payloads and make a large number of image requests on first load. See [httparchive.org/reports/state-of-images](https://httparchive.org/reports/state-of-images) for context on the state of images globally, and also the [media](./media) and [page weight](./page-weight) chapters. Website owners want their sites to look good on modern devices. As a result, many sites deliver the same high resolution product images to every user without regard for screen resolution or size. Developers may not be aware of (or not want to use) responsive techniques that enable efficient delivery of the best possible image to different users. It's worth remembering that high-resolution images may not necessarily increase conversion rates. Conversely, overuse of heavy images is likely to impact page speed and can thereby _reduce_ conversion rates. In the authors' experience from site reviews and events, some developers and other stakeholders have SEO or other concerns about using lazy loading for images. -### Suggested actions - -- We need to do more analysis to better understand why some sites are not using responsive image techniques or lazy loading. -- We need to provide guidance that helps ecommerce platforms to reliably deliver beautiful images to those with high end devices and good connectivity — while providing a best-possible experience to lower-end devices and those with poor connectivity. - ---- +We need to do more analysis to better understand why some sites are not using responsive image techniques or lazy loading. We also need to provide guidance that helps ecommerce platforms to reliably deliver beautiful images to those with high end devices and good connectivity — while providing a best-possible experience to lower-end devices and those with poor connectivity. ## Popular image formats -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1049425091) -
// Chart 13_06b: Popular image formats // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1240367519
Figure 17. Popular image formats.
-### Note that… +Note that some image services or CDNs will automatically deliver WebP (rather than JPEG or PNG) to platforms that support WebP, even for a URL with a .jpg or .png suffix. For example, this URL will return a WebP image in Chrome: [res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg](https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg). However, HTTP Archive image format detection is done by checking for keywords in the MIME type first, then falling back to the file extension. The code for format detection is [here](https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994). This means that the format for images with URLs such as the above will be given as WebP, since WebP is supported by HTTP Archive as a user agent. -- Some image services or CDNs will automatically deliver WebP (rather than JPEG or PNG) to platforms that support WebP, even for a URL with a .jpg or .png suffix. For example, this URL will return a WebP image in Chrome: [res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg](https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg). -- However — HTTP Archive image format detection is done by checking for keywords in the MIME type first, then falling back to the file extension. (The code for format detection is [here](https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994).) This means that the format for images with URLs such as the above will be given as WebP, since WebP is supported by HTTP Archive as a user agent. - -### Commentary - -#### PNG +### PNG The high number of PNG requests from pages on ecommerce platforms is probably for product images. Many commerce sites use PNG with photographic images to enable transparency. Using WebP with a PNG fallback can be a far more efficient alternative, either via a picture element (see [simpl.info/picturetype](http://simpl.info/picturetype)) or by using user agent capability detection via an image service such as Cloudinary (see [res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg](https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg)). -#### WebP - -The data shows very few sites on ecommerce platforms using WebP, which tallies with the authors' experience of site reviews and partner work. +### WebP -WebP is [supported by all modern browsers other than Safari](https://caniuse.com/#feat=webp) and has good fallback mechanisms available. WebP supports transparency and is a far more efficient format than PNG for photographic images. (See PNG section above.) +The data shows very few sites on ecommerce platforms using WebP, which tallies with the authors' experience of site reviews and partner work. WebP is [supported by all modern browsers other than Safari](https://caniuse.com/#feat=webp) and has good fallback mechanisms available. WebP supports transparency and is a far more efficient format than PNG for photographic images (see PNG section above). -### Suggested actions +### Pushing to use WebP more -- Guidance/advocacy for enabling transparency using WebP with a PNG fallback and/or using WebP/JPEG with a solid colour background. - -- WebP appears to be rarely used on ecommerce platforms even though several guides to WebP usage are available (such as [web.dev/serve-images-webp](https://web.dev/serve-images-webp)) as well as apps and tools including [Squoosh](https://squoosh.app/) and [cwebp](https://developers.google.com/speed/webp/docs/cwebp). We need to do further research into why there hasn't been more takeup of WebP, which is now [nearly 10 years old](https://blog.chromium.org/2010/09/webp-new-image-format-for-web.html). - ---- +We as a web community can provide better guidance/advocacy for enabling transparency using WebP with a PNG fallback and/or using WebP/JPEG with a solid color background. WebP appears to be rarely used on ecommerce platforms even though several guides to WebP usage are available (such as [web.dev/serve-images-webp](https://web.dev/serve-images-webp)) as well as apps and tools including [Squoosh](https://squoosh.app/) and [cwebp](https://developers.google.com/speed/webp/docs/cwebp). We need to do further research into why there hasn't been more takeup of WebP, which is now [nearly 10 years old](https://blog.chromium.org/2010/09/webp-new-image-format-for-web.html). ## Image dimensions -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1866746948) -
// Chart 13_06c: Image dimensions // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1050583521 @@ -360,33 +247,17 @@ WebP is [supported by all modern browsers other than Safari](https://caniuse.com
Figure 19. Image dimensions for home pages on ecommerce platforms.
-### What it means - -- The median ('mid range') dimensions for images requested by home pages on ecommerce platforms is 247x196 px on mobile and 240x192 px on desktop. -- 10% of images requested by home pages on ecommerce platforms are at least 693x512 px on mobile and 800x546 px on desktop. - -### Note that... +The median ('mid-range') dimensions for images requested by home pages on ecommerce platforms is 247x196 px on mobile and 240x192 px on desktop. 10% of images requested by home pages on ecommerce platforms are at least 693x512 px on mobile and 800x546 px on desktop. -- These dimensions are the intrinsic sizes of images, not their display size. -- The median dimensions for images on ecommerce platforms are 247x196 px on mobile, 240x192 px on desktop. -- 10% of images for pages on ecommerce platforms are at least 693x512 px on mobile and 800x546 px on desktop. +Note that these dimensions are the intrinsic sizes of images, not their display size. The median dimensions for images on ecommerce platforms are 247x196 px on mobile, 240x192 px on desktop though 10% of images for pages on ecommerce platforms are at least 693x512 px on mobile and 800x546 px on desktop. -### Commentary +Given that image dimensions at each percentile up to the median are similar on mobile and desktop, or even slightly _larger_ on mobile in some cases, it would seem that many sites are not delivering different image dimensions for different viewports — in other words, not using responsive image techniques. The delivery of _larger_ images to mobile in some cases may (or may not!) be explained by sites using device or screen detection. -- Given that image dimensions at each percentile up to the median are similar on mobile and desktop, or even slightly _larger_ on mobile in some cases, it would seem that many sites are not delivering different image dimensions for different viewports — in other words, not using responsive image techniques. -- The delivery of _larger_ images to mobile in some cases may (or may not!) be explained by sites using device or screen detection. - -### Suggested actions - -- We need to do more research into why many sites are (apparently) not delivering different image sizes to different viewports. - ---- +We need to do more research into why many sites are (apparently) not delivering different image sizes to different viewports. ## Third party requests and bytes -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=159114105) - -Many websites — especially online stores — load a significant amount of code and content from third parties: for analytics, A/B testing, customer behaviour tracking, advertising and social media support. Third party content can have a [significant impact on performance](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript). +Many websites — especially online stores — load a significant amount of code and content from third parties: for analytics, A/B testing, customer behavior tracking, advertising and social media support. Third party content can have a [significant impact on performance](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript). [Patrick Hulce](https://twitter.com/patrickhulce)'s [third-party-web tool](https://github.com/patrickhulce/third-party-web) is used to determine third party requests for this report, and this is discussed more in the [./third-party](Third Party chapter) written by Patrick.
// Chart 13_09: Third party requests and bytes @@ -454,28 +325,13 @@ Many websites — especially online stores — load a significant amount of code
Figure 22. Total third party requests for home pages on ecommerce platforms.
-### Note that… - -- Patrick Hulce 's [third-party-web tool](https://github.com/patrickhulce/third-party-web) is used to determine third party requests, as defined in the [Web Almanac Third Parties document](https://docs.google.com/document/d/1q52f7pRSO0g6J1zbiVq-iVCYdGs6UdYQTCLOAFglz94/edit#heading=h.z3uzjvnolr4v). - -### What it means +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. -- 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. - -### Commentary - -- [Other studies](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/) icated that third party content can be a major performance bottleneck. This study shows that 17 or more requests (50 or more for the top 10%) is the norm for home pages on ecommerce platforms. - ---- +[Other studies](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/) indicated that third party content can be a major performance bottleneck. This study shows that 17 or more requests (50 or more for the top 10%) is the norm for home pages on ecommerce platforms. ## Third party requests and payload per platform -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1914856197) - -**The charts and tables below show data for mobile only.** - -See the Web Almanac [spreadsheet](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1914856197) for desktop data. +Note the charts and tables below show data for mobile only.
// Chart 13_09b: 3P requests/bytes per platform @@ -517,25 +373,12 @@ See the Web Almanac [spreadsheet](https://docs.google.com/spreadsheets/d/1FUMHeO
Figure 26. Payload size (KB) at each percentile.
-### Note that… - -- Patrick Hulce 's [third-party-web tool](https://github.com/patrickhulce/third-party-web) is used to determine third party requests, as defined in the [Web Almanac Third Parties document](https://docs.google.com/document/d/1q52f7pRSO0g6J1zbiVq-iVCYdGs6UdYQTCLOAFglz94/edit#heading=h.z3uzjvnolr4v). -- Platforms such as Shopify may extend their services using client-side JavaScript, whereas other platforms such as Magento use more server side extensions. This difference in architecture affects the figures seen here. +Platforms such as Shopify may extend their services using client-side JavaScript, whereas other platforms such as Magento use more server side extensions. This difference in architecture affects the figures seen here. -### Commentary - -- Clearly, home pages on some platforms make more requests for third party content and incur a larger total third party payload. - -### Suggested actions - -- Further analysis: why do home pages from some platforms make more requests and have larger third party payloads than others? - ---- +Clearly, home pages on some platforms make more requests for third party content and incur a larger total third party payload. Further analysis could be completed on why home pages from some platforms make more requests and have larger third party payloads than others. ## Third party requests and payload per category -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=758228558) -
// Chart 13_09c: 3P requests/bytes per category // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=842081746 @@ -548,45 +391,24 @@ See the Web Almanac [spreadsheet](https://docs.google.com/spreadsheets/d/1FUMHeO
Figure 28. Median total third party payload.
-### What it means - -- 'Hosting' in these charts refers to files used by the platforms themselves, such as boilerplate JavaScript and CSS. - -### Note that… - -- Patrick Hulce 's [third-party-web tool](https://github.com/patrickhulce/third-party-web) is used to determine third party requests, as defined in the [Web Almanac Third Parties document](https://docs.google.com/document/d/1q52f7pRSO0g6J1zbiVq-iVCYdGs6UdYQTCLOAFglz94/edit#heading=h.z3uzjvnolr4v). - -### Commentary - -- 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 behaviour monitoring +'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). -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=440889700) +## 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 -
Figure 29. Analytics, review and user behaviour monitoring.
+
Figure 29. Analytics, review and user behavior monitoring.
// Charts • 13_10: Top analytics providers non-Google, https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1585341764 -
Figure 30. Analytics, review and user behaviour monitoring — other than Google.
+
Figure 30. Analytics, review and user behavior monitoring — other than Google.
-### Commentary - -- 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. - ---- +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 -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1279520266) -
// Chart 13_11: Top ad providers >=1% // https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1621252176 @@ -594,19 +416,11 @@ See the Web Almanac [spreadsheet](https://docs.google.com/spreadsheets/d/1FUMHeO
Figure 31. Top ad providers.
-### Commentary - -- 246 ad providers were detected on home pages on ecommerce platforms. -- Of these, 12 get more than 1% of all requests on either mobile or desktop. -- 127 providers get less than 0.01% of ad requests from home pages on ecommerce platforms. - ---- +246 ad providers were detected on home pages on ecommerce platforms. Of these, 12 get more than 1% of all requests on either mobile or desktop. 127 providers get less than 0.01% of ad requests from home pages on ecommerce platforms. ## First Contentful Paint (FCP) -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1829146121) - -**See the Performance chapter for comparative data.** +See the [performance chapter](./performance) for comparative data.
@@ -634,82 +448,41 @@ See the Web Almanac [spreadsheet](https://docs.google.com/spreadsheets/d/1FUMHeO
Figure 33. Top six ecommerce platforms: First Contentful Paint.
-### What it means - -- 'Total pages' is the total number of home pages retrieved while data was being gathered for this study. For example, 135,290 desktop requests were for home pages on sites built using the WooCommerce platform. -- [First Contentful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint) measures the time it takes from navigation until content such as text or an image is first displayed. -- In this context, 'fast' means FCP in under one second, 'slow' means FCP in 2.5 seconds or more, 'average' is everything in between. -- Note that third party content and code may have a significant impact on FCP. - -### Commentary +'Total pages' is the total number of home pages retrieved while data was being gathered for this study. For example, 135,290 desktop requests were for home pages on sites built using the WooCommerce platform. [First Contentful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint) measures the time it takes from navigation until content such as text or an image is first displayed. In this context, 'fast' means FCP in under one second, 'slow' means FCP in 2.5 seconds or more, 'average' is everything in between. Note that third party content and code may have a significant impact on FCP. -- All top-six ecommerce platforms have worse FCP on mobile than desktop: less 'fast', more 'slow'. Note that FCP is affected by device capability (processing power, memory, etc.) as well as connectivity. +All top-six ecommerce platforms have worse FCP on mobile than desktop: less 'fast', more 'slow'. Note that FCP is affected by device capability (processing power, memory, etc.) as well as connectivity. -### Suggested actions - -- We need to establish why FCP is worse on mobile than desktop. What are the causes: connectivity and/or device capability — or something else? - ---- +We need to establish why FCP is worse on mobile than desktop. What are the causes: connectivity and/or device capability — or something else? ## SEO Indexability -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=624286853) +See also the [SEO chapter](./seo) for more information on this topic beyond just ecommerce sites.
// Charts 13_12: SEO Indexability, _pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1788076260
Figure 34. Search engine indexability of home pages on commerce platforms.
-### What it means +97.35% of mobile home pages on ecommerce platforms pass the [Lighthouse SEO audit](https://developers.google.com/web/tools/lighthouse/audits/indexing): they do not have HTTP headers or meta tags that block indexing. Note that Lighthouse API SEO audit results are only available for mobile. 0.57% of home pages on ecommerce platforms block indexing. Lighthouse was unable to the SEO audit for 2.08% of home pages. -- 97.35% of mobile home pages on ecommerce platforms pass the [Lighthouse SEO audit](https://developers.google.com/web/tools/lighthouse/audits/indexing): they do not have HTTP headers or meta tags that block indexing. - -### Note that… - -- Lighthouse API SEO audit results are only available for mobile. - -### Commentary - -- 0.57% of home pages on ecommerce platforms block indexing. -- Lighthouse was unable to the SEO audit for 2.08% of home pages. - ---- ## Progressive Web App (PWA) scores -[Data](https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit#gid=1181092280) +See also the [PWA chapter](./pwa) for more information on this topic beyond just ecommerce sites.
// Chart 13_13: PWA scores, https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/edit?ts=5d768aec#gid=1548616265
Figure 35. Lighthouse PWA scores.
-### What it means - -- More than 60% of home pages on ecommerce platforms get a [Lighthouse PWA score](https://developers.google.com/web/ilt/pwa/lighthouse-pwa-analysis-tool) between 25 and 35. -- Less than 20% of home pages on ecommerce platforms get a score of more than 50. -- Less than 1% of home pages score more than 60. +More than 60% of home pages on ecommerce platforms get a [Lighthouse PWA score](https://developers.google.com/web/ilt/pwa/lighthouse-pwa-analysis-tool) between 25 and 35. Less than 20% of home pages on ecommerce platforms get a score of more than 50 and less than 1% of home pages score more than 60. - +Lighthouse returns a Progressive Web App (PWA) score between zero and 100. Zero is the worst possible score, and 100 is the best. The PWA audits are based on the [Baseline PWA Checklist](https://developers.google.com/web/progressive-web-apps/checklist), which lists 14 requirements. Lighthouse has automated audits for 11 of the 14 requirements. The remaining 3 can only be tested manually. Each of the 11 automated PWA audits are weighted equally, so each one contributes approximately 9 points to your PWA score. -### Note that… +If at least one of the PWA audits got a null score, Lighthouse nulls out the score for the entire PWA category. This was the case for 2.32% of home pages. -- If at least one of the PWA audits got a null score, Lighthouse nulls out the score for the entire PWA category. This was the case for 2.32% of home pages. - -### Commentary - -- Clearly, most home pages on ecommerce platforms are failing most [PWA checklist audits](https://developers.google.com/web/progressive-web-apps/checklist). - -### Suggested actions - -- We need to do further analysis to better understand which audits are failing and why. - ---- +Clearly, most home pages on ecommerce platforms are failing most [PWA checklist audits](https://developers.google.com/web/progressive-web-apps/checklist). We need to do further analysis to better understand which audits are failing and why. -## Actions for next year's ecommerce chapter +## Conclusion -- We didn't get accessibility scores this year. Next year, we will. -- Likewise for geographical data. -- This study detected 246 ad providers on home pages on ecommerce platforms. Next year, we'll calculate what proportion of sites on ecommerce platforms shows ads. -- WooCommerce got very high numbers in this study. Next year it would be good to confirm if some hosting providers are installing WooCommerce but not enabling it, thereby causing inflated figures. +This comprehensive study of ecommerce usage for the sites crawled by HTTP Archive shows some interesting data and also the wide variations in ecommerce sites - even those built on the same ecommerce platform. Even though we have gone into a lot of detail here, there is much more analysis we could do in this space. For example, we didn't get accessibility scores this year (checkout the [accessibility chapter](./accessibility) for more on that). Next year, we should look at this and likewise, for geographical data. This study detected 246 ad providers on home pages on ecommerce platforms. Further studies (perhaps in next years Web Almanac?) could calculate what proportion of sites on ecommerce platforms shows ads. WooCommerce got very high numbers in this study so another interesting statistic we could look at next year is if some hosting providers are installing WooCommerce but not enabling it, thereby causing inflated figures. diff --git a/src/content/en/2019/performance.md b/src/content/en/2019/performance.md index f037b4b9383..846fc97dcfd 100644 --- a/src/content/en/2019/performance.md +++ b/src/content/en/2019/performance.md @@ -3,14 +3,14 @@ part_number: II chapter_number: 7 title: Performance authors: [rviscomi] -reviewers: [JMPerez, obto, sergeychernyshev, zeman] +reviewers: [JMPerez,obto,sergeychernyshev,zeman] --- ## Introduction Performance is a visceral part of the user experience. For [many websites](https://wpostats.com/), an improvement to the user experience by speeding up the page load time aligns with an improvement to conversion rates. Conversely, when performance is poor, users don't convert as often and have even been observed [rage clicking](https://blog.fullstory.com/rage-clicks-turn-analytics-into-actionable-insights/) on the page in frustration. -There are many ways to quantify web performance. The most important thing is to measure what actually matters to users. Events like `onload` or `DOM content loaded` may not necessarily reflect what users experience visually. For example, an email client might have a very fast onload event but the only thing loaded is the interstitial progress bar, meanwhile the inbox contents are loading asynchronously. The loading metric that matters for this web app is the "time to inbox", and focusing on the `onload` event may be misleading. For that reason this chapter will look at more modern and universally applicable paint, load, and interactivity metrics to try to capture how users are actually experiencing the page. +There are many ways to quantify web performance. The most important thing is to measure what actually matters to users. However, events like `onload` or `DOMContentLoaded` may not necessarily reflect what users experience visually. For example, when loading an email client, it might show an interstitial progress bar while the inbox contents load asynchronously. The problem is that the `onload` event doesn't wait for the inbox to asynchronously load. In this example, the loading metric that matters most to users is the "time to inbox", and focusing on the `onload` event may be misleading. For that reason this chapter will look at more modern and universally applicable paint, load, and interactivity metrics to try to capture how users are actually experiencing the page. There are two kinds of performance data: lab and field. You may have heard these referred to as synthetic and real-user measurement (or RUM). Measuring performance in the lab ensures that each website is tested under common conditions like browser, connection speed, physical location, cache state, etc. This guarantee of consistency makes each website comparable with one another. On the other hand, measuring performance in the field represents how users actually experience the web in all of the infinite combinations of conditions that we could never capture in the lab. For the purposes of this chapter and understanding real-world user experiences, we'll look at field data. @@ -30,232 +30,177 @@ Almost all of the other chapters in the Web Almanac are based on data from the [ - 4G - users' geographic location -Experiences are measured monthly including paint, load, and interactivity metrics. The first metric we'll look at is [First Contentful Paint](https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#first_paint_and_first_contentful_paint) (FCP). This is the time users spend waiting for the page to display something useful to the screen, like an image or text. Next, we'll look at look at a loading metric, [Time to First Byte](https://csswizardry.com/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/) (TTFB). This is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response. And finally, the last field metric we'll look at is [First Input Delay](https://developers.google.com/web/updates/2018/05/first-input-delay) (FID). This is a relatively new metric and one that represents parts of the UX other than loading performance. It measures the time from a user's first interaction with a page's UI until the time the browser's main thread is ready to process the event. +Experiences are measured monthly including paint, load, and interactivity metrics. The first metric we'll look at is [First Contentful Paint](https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#first_paint_and_first_contentful_paint) (FCP). This is the time users spend waiting for the page to display something useful to the screen, like an image or text. Next, we'll look at look at a loading metric, [Time to First Byte](https://developer.mozilla.org/en-US/docs/Glossary/time_to_first_byte) (TTFB). This is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response. And finally, the last field metric we'll look at is [First Input Delay](https://developers.google.com/web/updates/2018/05/first-input-delay) (FID). This is a relatively new metric and one that represents parts of the UX other than loading performance. It measures the time from a user's first interaction with a page's UI until the time the browser's main thread is ready to process the event. -So let's dive in and see what kind of insights we can find. +So let's dive in and see what insights we can find. ### FCP -
-// Chart: flame distribution of 07_01 -
Figure 1. Distribution of websites' fast, average, and slow FCP performance.
+
+ +
Figure 1. Distribution of websites' fast, moderate, and slow FCP performance.
-In Figure 1 above you can see how FCP experiences are distributed across the web. Out of the millions of websites in the CrUX dataset, this chart compresses the distribution down to 1,000 websites where each vertical slice represents a single website. The chart is sorted by the percent of fast FCP experiences, which are those occurring in less than 1 second. Slow experiences occur in 2.5 seconds or more, and average experiences are everything in between. At the extremes of the chart, there are some websites with almost 100% fast experiences and some websites with almost 100% slow experiences. In between, websites have a combination of fast, average, and slow performance that seems to lean more towards fast or average than slow, which is good. +In Figure 1 above you can see how FCP experiences are distributed across the web. Out of the millions of websites in the CrUX dataset, this chart compresses the distribution down to 1,000 websites where each vertical slice represents a single website. The chart is sorted by the percent of fast FCP experiences, which are those occurring in less than 1 second. Slow experiences occur in 3 seconds or more, and moderate (formerly known as "average") experiences are everything in between. At the extremes of the chart, there are some websites with almost 100% fast experiences and some websites with almost 100% slow experiences. In between, websites have a combination of fast, moderate, and slow performance that seems to lean more towards fast or moderate than slow, which is good. - + -In order to categorize whether a website is sufficiently **fast** we will use the [PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about#categories) (PSI) methodology where at least 90% of the website's FCP experiences must be faster than 1 second. Similarly a sufficiently **slow** website has 10% or more FCP experiences slower than 2.5 seconds. We say a website has **average** performance when it doesn't meet either of these conditions. +In order to categorize whether a website is sufficiently **fast** we will use the new [PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about#categories) (PSI) methodology where at least 75% of the website's FCP experiences must be faster than 1 second. Similarly a sufficiently **slow** website has 25% or more FCP experiences slower than 3 seconds. We say a website has **moderate** performance when it doesn't meet either of these conditions. -
-// Chart: Bar distribution of 07_03 -
Figure 2. Distribution of websites labelled as having fast, average, or slow FCP.
+
+ +
Figure 2. Distribution of websites labelled as having fast, moderate, or slow FCP.
-
+The results in Figure 2 show that only 13% of websites are considered fast. This is a sign that there is still a lot of room for improvement but many websites are painting meaningful content quickly and consistently. Two thirds of websites have moderate FCP experiences. -Fast FCP | Average FCP | Slow FCP --- | -- | -- -2.17% | 37.55% | 60.28% - -
Figure 3. Table of the percent of websites labelled as having fast, average, or slow FCP.
-
- -In Figures 2 and 3, the results show that only 2.17% of websites are considered fast while 60.28% of websites are considered slow. To help us understand how users experience FCP across different devices, let's segment by form factor. +To help us understand how users experience FCP across different devices, let's segment by form factor. #### FCP by device -
-// Chart: Flame distribution of 07_01b -
Figure 4. Distribution of _desktop_ websites' fast, average, and slow FCP performance.
+
+ +
Figure 3. Distribution of desktop websites' fast, moderate, and slow FCP performance.
-
-// Chart: Flame distribution of 07_01c -
Figure 5. Distribution of _phone_ websites' fast, average, and slow FCP performance.
+
+ +
Figure 4. Distribution of phone websites' fast, moderate, and slow FCP performance.
-In Figures 4 and 5 above, the FCP distributions of 1,000 sample websites are broken down by desktop and phone. It's subtle, but the torso of the desktop fast FCP distribution appears to be more convex than the distribution for phone users. This visual approximation suggests that desktop users experience a higher overall proportion of fast FCP. To verify this we can apply the PSI methodology to each distribution. +In Figures 3 and 4 above, the FCP distributions are broken down by desktop and phone. It's subtle, but the torso of the desktop fast FCP distribution appears to be more convex than the distribution for phone users. This visual approximation suggests that desktop users experience a higher overall proportion of fast FCP. To verify this we can apply the PSI methodology to each distribution. -
-// Chart: Bar distributions of 07_03b -
Figure 6. Distribution of websites labelled as having fast, average, or slow FCP, broken down by device type.
+
+ +
Figure 5. Distribution of websites labelled as having fast, moderate, or slow FCP, broken down by device type.
-
- -Device | Fast FCP | Average FCP | Slow FCP --- | -- | -- | -- -desktop | 2.80% | 39.40% | 57.80% -phone | 1.76% | 35.62% | 62.62% - -
Figure 7. Table of websites labelled as having fast, average, or slow FCP, broken down by device type.
-
+According to PSI's classification, 17% of websites have fast FCP experiences overall for desktop users, compared to 11% for mobile users. The entire distribution is skewed slightly faster for desktop experiences, with fewer slow websites and more in the fast and moderate category. -According to PSI's classification, 2.80% of websites have fast FCP experiences overall for desktop users, compared to 1.76% for mobile users. The entire distribution is skewed slightly faster for desktop experiences, with fewer slow websites and more in the fast and average category. +Why might desktop users experience fast FCP on a higher proportion of websites than phone users? We can only speculate, after all this dataset is meant to answer how is the web performing and not necessarily _why_ it's performing that way. But one guess could be that desktop users are connected to the internet on faster, more reliable networks like WiFi rather than cell towers. To help answer this question we can also explore how user experiences vary by ECT. #### FCP by ECT -
-// Chart: Bar distribution of 07_03c -
Figure 8. Distribution of websites labelled as having fast, average, or slow FCP, broken down by ECT.
+
+ +
Figure 6. Distribution of websites labelled as having fast, moderate, or slow FCP, broken down by ECT.
-
- -Speed | Fast FCP | Average FCP | Slow FCP --- | -- | -- | -- -4G | 2.31 | 40.10 | 57.59 -3G | 0.04 | 3.48 | 96.49 -2G | 0.03 | 0.30 | 99.68 -slow-2G | 0.03 | 0.08 | 99.89 - -
Figure 9. Table of the percent of websites labelled as having fast, average, or slow FCP, broken down by ECT.
-
- -In Figures 8 and 9 above, FCP experiences are grouped by the ECT of the user experience. Interestingly, there is a correlation between ECT speed and the percent of websites serving fast FCP. As the ECT speeds decrease, the proportion of fast experiences approaches zero. 8.44% of websites serve fast FCP to users with 4G ECT while 57.59% of those websites serve slow FCP. 96.49% of websites serve slow FCP to users with 3G ECT, 99.68% to 2G ECT, and 99.89% to slow-2G ECT. These results suggest that websites almost never serve fast FCP consistently to users on slow connections. +In Figure 6 above, FCP experiences are grouped by the ECT of the user experience. Interestingly, there is a correlation between ECT speed and the percent of websites serving fast FCP. As the ECT speeds decrease, the proportion of fast experiences approaches zero. 14% of websites that serve users with 4G ECT have fast FCP experiences, while 19% of those websites have slow experiences. 61% of websites serve slow FCP to users with 3G ECT, 90% to 2G ECT, and 99% to slow-2G ECT. These results suggest that websites seldom serve fast FCP consistently to users on connections effectively slower than 4G. #### FCP by geo -
-// Chart: Bar distribution of 07_03d -
Figure 10. Distribution of websites labelled as having fast, average, or slow FCP, broken down by geo.
+
+ +
Figure 7. Distribution of websites labelled as having fast, moderate, or slow FCP, broken down by geo.
-Finally, we can slice FCP by users' geography (geo). The chart above shows the top 23 geos having the highest number of distinct websites, an indicator of overall popularity of the open web. The geos are sorted by their percent of websites having sufficiently fast FCP experiences. At the top of the list are three [Asia-Pacific](https://en.wikipedia.org/wiki/Asia-Pacific) (APAC) geos: Korea, Taiwan, and Japan. This could be explained by the availability of extremely [fast network connection speeds in these regions](https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds). Korea has 11.10% of websites meeting the fast FCP bar and only 28.00% rated as slow FCP. Recall that the global distribution of fast/average/slow websites is approximately 2/38/60, making Korea a significantly positive outlier. +Finally, we can slice FCP by users' geography (geo). The chart above shows the top 23 geos having the highest number of distinct websites, an indicator of overall popularity of the open web. Web users in the United States visit the most distinct websites at 1,211,002. The geos are sorted by the percent of websites having sufficiently fast FCP experiences. At the top of the list are three [Asia-Pacific](https://en.wikipedia.org/wiki/Asia-Pacific) (APAC) geos: Korea, Taiwan, and Japan. This could be explained by the availability of extremely [fast network connection speeds in these regions](https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds). Korea has 36% of websites meeting the fast FCP bar and only 7% rated as slow FCP. Recall that the global distribution of fast/moderate/slow websites is approximately 13/66/20, making Korea a significantly positive outlier. -Other APAC geos tell a different story. Thailand, Vietnam, Indonesia, and India all have fewer than 1% of fast websites. These geos also have more than double the proportion of slow websites than Korea. +Other APAC geos tell a different story. Thailand, Vietnam, Indonesia, and India all have fewer than 10% of fast websites. These geos also have more than triple the proportion of slow websites than Korea. ### TTFB [Time to First Byte](https://web.dev/time-to-first-byte) (TTFB) is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response. -
+
![Navigation Timing API diagram of the events in a page navigation](/static/images/2019/07_Performance/nav-timing.png) -
Figure 11. Navigation Timing API diagram of the events in a page navigation.
+
Figure 8. Navigation Timing API diagram of the events in a page navigation.
-To help explain TTFB and the many factors that affect it, let's borrow a diagram from the Navigation Timing API spec. In Figure 11 above, TTFB is the duration from `startTime` to `responseStart`, including everything in between: `unload`, `redirects`, `AppCache`, `DNS`, `SSL`, `TCP`, and the time the server spends handling the request. Given that context, let's see how users are experiencing this metric. +To help explain TTFB and the many factors that affect it, let's borrow a diagram from the Navigation Timing API spec. In Figure 8 above, TTFB is the duration from `startTime` to `responseStart`, including everything in between: `unload`, `redirects`, `AppCache`, `DNS`, `SSL`, `TCP`, and the time the server spends handling the request. Given that context, let's see how users are experiencing this metric. -
-// Chart: Flame distribution of 07_07 -
Figure 12. Distribution of websites' fast, average, and slow TTFB performance.
+
+ +
Figure 9. Distribution of websites' fast, moderate, and slow TTFB performance.
-Similar to the previous FCP chart, this is a view of 1,000 representative samples ordered by fast TTFB. A [fast TTFB](https://developers.google.com/speed/docs/insights/Server#recommendations) is one that happens in under 0.2 seconds (200 ms), a slow TTFB happens in 1 second or more, and everything in between is average. +Similar to the FCP chart in Figure 1, this is a view of 1,000 representative samples ordered by fast TTFB. A [fast TTFB](https://developers.google.com/speed/docs/insights/Server#recommendations) is one that happens in under 0.2 seconds (200 ms), a slow TTFB happens in 1 second or more, and everything in between is moderate. Looking at the curve of the fast proportions, the shape is quite different from that of FCP. There are very few websites that have a fast TTFB greater than 75%, while more than half are below 25%. -Let's apply a TTFB speed label to each website, similar to the PSI methodology used above for FCP. If a website serves fast TTFB to 90% or more user experiences, it's labelled as **fast**. Otherwise if it serves **slow** TTFB to 10% or more user experiences, it's slow. If neither of those conditions apply, it's **average**. - -
-// Chart: Bar distribution of 07_08 -
Figure 13. Distribution of websites labelled as having fast, average, or slow TTFB.
-
- -
- -Fast TTFB | Average TTFB | Slow TTFB --- | -- | -- -0.13% | 30.67% | 69.20% +Let's apply a TTFB speed label to each website, taking inspiration from the PSI methodology used above for FCP. If a website serves fast TTFB to 75% or more user experiences, it's labelled as **fast**. Otherwise if it serves **slow** TTFB to 25% or more user experiences, it's slow. If neither of those conditions apply, it's **moderate**. -
Figure 14. Table of the percent of websites labelled as having fast, average, or slow TTFB.
+
+ +
Figure 10. Distribution of websites labelled as having fast, moderate, or slow TTFB.
-69.20% of websites have slow TTFB. This is significant because TTFB is a blocker for all other performance metrics to follow. A user cannot possibly experience a fast FCP if the TTFB takes more than 1 second. Recall from the previous FCP section that about 98% of websites do not have fast FCP. Therefore the ~70% of websites that have slow TTFB are completely ineligible to be considered as having fast FCP. +42% of websites have slow TTFB experiences. This is significant because TTFB is a blocker for all other performance metrics to follow. _By definition, a user cannot possibly experience a fast FCP if the TTFB takes more than 1 second_. #### TTFB by geo -
-// Chart: Bar distribution of 07_08d -
Figure 15. Distribution of websites labelled as having fast, average, or slow TTFB, broken down by geo.
+
+ +
Figure 11. Distribution of websites labelled as having fast, moderate, or slow TTFB, broken down by geo.
-Now let's look at the percent of websites serving fast TTFB to users in different geos. APAC geos like Korea, Taiwan, and Japan are still outperforming users from the rest of the world. But no geo has more than 3% of websites with fast TTFB. +Now let's look at the percent of websites serving fast TTFB to users in different geos. APAC geos like Korea, Taiwan, and Japan are still outperforming users from the rest of the world. But no geo has more than 15% of websites with fast TTFB. India, for example, has fewer than 1% of websites with fast TTFB and 79% with slow TTFB. ### FID The last field metric we'll look at is [First Input Delay](https://developers.google.com/web/updates/2018/05/first-input-delay) (FID). This metric represents the time from a user's first interaction with a page's UI until the time the browser's main thread is ready to process the event. Note that this doesn't include the time applications spend actually handling the input. At worst, slow FID results in a page that appears unresponsive and a frustrating user experience. -Let's start by defining some thresholds. According to the [PSI methodology](https://developers.google.com/speed/docs/insights/v5/about#categories), a **fast** FID is one that happens in less than 50 ms. This gives the application enough time to handle the input event and provide feedback to the user in a time that feels instantaneous. A **slow** FID is one that happens in 250 ms or more. Everything in between is **average**. +Let's start by defining some thresholds. According to the new PSI methodology, a **fast** FID is one that happens in less than 100 ms. This gives the application enough time to handle the input event and provide feedback to the user in a time that feels instantaneous. A **slow** FID is one that happens in 300 ms or more. Everything in between is **moderate**. -
-// Chart: Flame distribution of 07_02 -
Figure 16. Distribution of websites' fast, average, and slow FID performance.
+
+ +
Figure 12. Distribution of websites' fast, moderate, and slow FID performance.
-You know the drill by now. This chart shows the distribution of 1,000 websites' fast, average, and slow FID. This is a dramatically different chart from the ones for FCP and TTFB. The curve of fast FID very slowly descends from 100% to 75% then takes a nosedive. The overwhelming majority of FID experiences are fast for most websites. +You know the drill by now. This chart shows the distribution of websites' fast, moderate, and slow FID experiences. This is a dramatically different chart from the previous charts for FCP and TTFB. (See [Figure 1](#fig1) and [Figure 9](#fig9), respectively). The curve of fast FID very slowly descends from 100% to 75% then takes a nosedive. The overwhelming majority of FID experiences are fast for most websites. -
-// Chart: Bar distribution of 07_04 -
Figure 17. Distribution of websites labelled as having fast, average, or slow TTFB.
+
+ +
Figure 13. Distribution of websites labelled as having fast, moderate, or slow TTFB.
-
- -Fast FID | Average FID | Slow FID --- | -- | -- -26.61% | 42.03% | 31.35% - -
Figure 18. Table of the percent of websites labelled as having fast, average, or slow FID.
-
+The PSI methodology for labelling a website as having sufficiently fast or slow FID is slightly different than that of FCP. For a site to be **fast**, 95% of its FID experiences must be fast. A site is **slow** if 5% of its FID experiences are slow. All other experiences are **moderate**. -The PSI methodology for labelling a website as having sufficiently fast or slow FID is slightly different than that of FCP. For a site to be fast, 95% of its FID experiences must be fast. A site is slow if 5% of its FID experiences are slow. - -The distribution of fast, average, and slow websites appears to be more balanced, with 26.61% of websites qualifying as fast and 31.35% as slow. +Compared to the previous metrics, the distribution of aggregate FID performance is much more skewed towards fast and moderate experiences than slow. 40% of websites have fast FID and only 15% have slow FID. The nature of FID being an interactivity metric -- as opposed to a loading metric bound by network speeds -- makes for an entirely different way to characterize performance. #### FID by device -
-// Chart: Flame distribution of 07_02b -
Figure 19. Distribution of _desktop_ websites' fast, average, and slow FID performance.
+
+ +
Figure 14. Distribution of desktop websites' fast, moderate, and slow FID performance.
-
-// Chart: Flame distribution of 07_02c -
Figure 20. Distribution of _phone_ websites' fast, average, and slow FID performance.
+
+ +
Figure 15. Distribution of phone websites' fast, moderate, and slow FID performance.
Breaking FID down by device, it becomes clear that there are two very different stories. Desktop users enjoy fast FID almost all the time. Sure there are some websites that throw out a slow experience now and then, but the results are predominantly fast. Mobile users, on the other hand, have what seem to be one of two experiences: pretty fast (but not quite as often as desktop) and almost never fast. The latter is experienced by users on only the tail ~10% of websites, but this is still a substantial difference. -
-// Chart: Bar distributions of 07_04b -
Figure 21. Distribution of websites labelled as having fast, average, or slow FID, broken down by device type.
-
- -
- -Device | Fast FID | Average FID | Slow FID --- | -- | -- | -- -desktop | 70.32% | 23.20% | 6.48% -phone | 13.76% | 43.21% | 43.03% - -
Figure 22. Table of websites labelled as having fast, average, or slow FID, broken down by device type.
+
+ +
Figure 16. Distribution of websites labelled as having fast, moderate, or slow FID, broken down by device type.
-When we apply the PSI labelling to desktop and phone experiences, the distinction becomes crystal clear. 70.32% of websites' FID experienced by desktop users are fast compared to 6.48% slow. For mobile experiences, 13.76% of websites are fast while 43.03% are slow. +When we apply the PSI labelling to desktop and phone experiences, the distinction becomes crystal clear. 82% of websites' FID experienced by desktop users are fast compared to 5% slow. For mobile experiences, 26% of websites are fast while 22% are slow. Form factor plays a major role in the performance of interactivity metrics like FID. #### FID by ECT -
-// Chart: Bar distribution of 07_04c -
Figure 23. Distribution of websites labelled as having fast, average, or slow FID, broken down by ECT.
+
+ +
Figure 17. Distribution of websites labelled as having fast, moderate, or slow FID, broken down by ECT.
On its face, FID seems like it would be driven primarily by CPU speed. It'd be reasonable to assume that the slower the device itself is, the higher the likelihood that it will be busy when the user attempts to interact with a web page, right? -The ECT results above seem to suggest a correlation between connection speed and FID performance. As users' effective connection speed decreases, the percent of websites on which they experience fast FID also decreases and slow FID increases. Interestingly, the percent of websites with average FID is about the same across ECTs. +The ECT results above seem to suggest that there is a correlation between connection speed and FID performance. As users' effective connection speed decreases, the percent of websites on which they experience fast FID also decreases: 41% of websites visited by users with a 4G ECT have fast FID, 22% with 3G, 19% with 2G, and 15% with slow 2G. #### FID by geo -
-// Chart: Bar distribution of 07_04d -
Figure 24. Distribution of websites labelled as having fast, average, or slow FID, broken down by geo.
+
+ +
Figure 18. Distribution of websites labelled as having fast, moderate, or slow FID, broken down by geo.
-In this breakdown of FID by geographic location, Korea is out in front of everyone else again. But the top geos have some new faces: the US, Australia, and Canada are next with 35-40% of websites having fast FID. +In this breakdown of FID by geographic location, Korea is out in front of everyone else again. But the top geos have some new faces: Australia, the United States, and Canada are next with more than 50% of websites having fast FID. -As with the other geo-specific results, there are so many possible factors that could be contributing to the user experience. For example, perhaps wealthier geos are more privileged to be able to spend more money on better network infrastructure and its residents have more money to spend on desktops and/or high-end mobile phones. +As with the other geo-specific results, there are so many possible factors that could be contributing to the user experience. For example, perhaps wealthier geos that are more privileged can afford faster network infrastructure also have residents with more money to spend on desktops and/or high-end mobile phones. ## Conclusion diff --git a/src/static/css/2019.css b/src/static/css/2019.css index 1656b015d80..8a819221a00 100644 --- a/src/static/css/2019.css +++ b/src/static/css/2019.css @@ -44,7 +44,6 @@ h1.title::before { } .btn { - outline: none; border: 1px solid #1A2B49; border-radius: 50px; padding: 15px 30px; @@ -71,7 +70,6 @@ h1.title::before { } a.navigation-logo { - outline: none; color: white; } a.navigation-logo img:hover, @@ -82,7 +80,6 @@ a.navigation-logo:focus img { header.alt-bg a:hover, footer.alt-bg a:hover, header.alt-bg a:focus, footer.alt-bg a:focus { color: #F7F779; - outline: none; } .decorative-line-center { @@ -164,7 +161,6 @@ header .btn + .language-switcher { .language-switcher select, .year-switcher select { - outline: none; border: 1px solid transparent; border-radius: 50px; padding: 20px; @@ -188,8 +184,7 @@ header .btn + .language-switcher { filter: invert(100%) sepia(0%) saturate(953%) hue-rotate(229deg) brightness(116%) contrast(100%); } -.menu-icon, -.menu-close-icon, +.menu-btn, .menu { display: none; } @@ -201,17 +196,19 @@ hr { blockquote { position: relative; font-style: italic; + font-size: 19px; + line-height: 26px; } blockquote::before { + content: '"'; position: absolute; - top: -15px; - left: -50px; - opacity: 0.05; - background: url('/static/images/quote.png') top left no-repeat; - background-size: contain; - content: ''; - height: 100px; - width: 100px; + z-index: -1; + top: -4rem; + left: -7rem; + opacity: .05; + font-size: 20rem; + font-family: 'Courier New', Courier, monospace; + line-height: 1; } /* Footer */ @@ -294,9 +291,6 @@ p.copyright { .social-media a:focus img { filter: brightness(0) saturate(100%) invert(86%) sepia(4%) saturate(4357%) hue-rotate(16deg) brightness(136%) contrast(94%); } -.social-media a:focus { - outline: none; -} @media (max-width: 900px) and (min-width: 601px) { .alt-bg.decorative-line, @@ -306,9 +300,6 @@ p.copyright { header .cta { display: none; } - blockquote::before { - left: calc(50% - 50px); - } footer { display: grid; @@ -384,29 +375,24 @@ p.copyright { opacity: 0.95; z-index: 1; } - .menu-icon { - display: block; - margin: 0; - + .menu-btn { + background: none; + border: 0; + display: block; + cursor: pointer; } + .menu-open .menu { display: flex; } - .menu-open .menu-close-icon { - display: block; - } - .menu-open .menu-icon { - display: none; - } .menu-open header { background-color: #667384; } .menu .misc { width: 100%; - } - - blockquote::before { - left: calc(50% - 50px); + display: flex; + align-items: center; + justify-content: space-evenly; } /* Footer */ diff --git a/src/static/css/index.css b/src/static/css/index.css index 8733aa5b33d..710d10d1b4f 100644 --- a/src/static/css/index.css +++ b/src/static/css/index.css @@ -139,11 +139,6 @@ p { align-items: center; } -blockquote { - font-size: 19px; - line-height: 26px -} - .featured-chapter-content > div, .featured-chapter-content button { margin-bottom: 40px; diff --git a/src/static/images/2019/01_JavaScript/hero_xl.jpg b/src/static/images/2019/01_JavaScript/hero_xl.jpg old mode 100755 new mode 100644 index dc272a7185b..3683e1a754e Binary files a/src/static/images/2019/01_JavaScript/hero_xl.jpg and b/src/static/images/2019/01_JavaScript/hero_xl.jpg differ diff --git a/src/static/images/2019/02_CSS/hero_lg.jpg b/src/static/images/2019/02_CSS/hero_lg.jpg index 9cc4614df78..e5b60cffe0c 100644 Binary files a/src/static/images/2019/02_CSS/hero_lg.jpg and b/src/static/images/2019/02_CSS/hero_lg.jpg differ diff --git a/src/static/images/2019/02_CSS/hero_sm.jpg b/src/static/images/2019/02_CSS/hero_sm.jpg index 953f71579ff..8094b4c54fb 100644 Binary files a/src/static/images/2019/02_CSS/hero_sm.jpg and b/src/static/images/2019/02_CSS/hero_sm.jpg differ diff --git a/src/static/images/2019/02_CSS/hero_xl.jpg b/src/static/images/2019/02_CSS/hero_xl.jpg old mode 100755 new mode 100644 index 0adcb5317a1..c68c8ab548e Binary files a/src/static/images/2019/02_CSS/hero_xl.jpg and b/src/static/images/2019/02_CSS/hero_xl.jpg differ diff --git a/src/static/images/2019/03_Markup/element_categories.png b/src/static/images/2019/03_Markup/element_categories.png index 10631c37052..bf05b9ad86f 100644 Binary files a/src/static/images/2019/03_Markup/element_categories.png and b/src/static/images/2019/03_Markup/element_categories.png differ diff --git a/src/static/images/2019/03_Markup/hero_lg.jpg b/src/static/images/2019/03_Markup/hero_lg.jpg index 8bc4e50684c..e08dc01dc9c 100644 Binary files a/src/static/images/2019/03_Markup/hero_lg.jpg and b/src/static/images/2019/03_Markup/hero_lg.jpg differ diff --git a/src/static/images/2019/03_Markup/hero_sm.jpg b/src/static/images/2019/03_Markup/hero_sm.jpg index 49f7633e9b8..bae96ce8257 100644 Binary files a/src/static/images/2019/03_Markup/hero_sm.jpg and b/src/static/images/2019/03_Markup/hero_sm.jpg differ diff --git a/src/static/images/2019/03_Markup/hero_xl.jpg b/src/static/images/2019/03_Markup/hero_xl.jpg old mode 100755 new mode 100644 index 051ee893428..99757608e3b Binary files a/src/static/images/2019/03_Markup/hero_xl.jpg and b/src/static/images/2019/03_Markup/hero_xl.jpg differ diff --git a/src/static/images/2019/03_Markup/hixie_element_types_per_page.png b/src/static/images/2019/03_Markup/hixie_element_types_per_page.png index 2f8bdad73ba..18165be3c35 100644 Binary files a/src/static/images/2019/03_Markup/hixie_element_types_per_page.png and b/src/static/images/2019/03_Markup/hixie_element_types_per_page.png differ diff --git a/src/static/images/2019/03_Markup/hixie_elements_per_page.png b/src/static/images/2019/03_Markup/hixie_elements_per_page.png index aa3f3c19523..169b09df4ad 100644 Binary files a/src/static/images/2019/03_Markup/hixie_elements_per_page.png and b/src/static/images/2019/03_Markup/hixie_elements_per_page.png differ diff --git a/src/static/images/2019/04_Media/hero_xl.jpg b/src/static/images/2019/04_Media/hero_xl.jpg old mode 100755 new mode 100644 index 15abb8d2926..74bc8750f2c Binary files a/src/static/images/2019/04_Media/hero_xl.jpg and b/src/static/images/2019/04_Media/hero_xl.jpg differ diff --git a/src/static/images/2019/05_Third_Parties/hero_xl.jpg b/src/static/images/2019/05_Third_Parties/hero_xl.jpg old mode 100755 new mode 100644 index 8874ba408e4..e49ae38cf4c Binary files a/src/static/images/2019/05_Third_Parties/hero_xl.jpg and b/src/static/images/2019/05_Third_Parties/hero_xl.jpg differ diff --git a/src/static/images/2019/06_Fonts/hero_xl.jpg b/src/static/images/2019/06_Fonts/hero_xl.jpg old mode 100755 new mode 100644 index a064efda148..0d07d2c7a70 Binary files a/src/static/images/2019/06_Fonts/hero_xl.jpg and b/src/static/images/2019/06_Fonts/hero_xl.jpg differ diff --git a/src/static/images/2019/07_Performance/hero_xl.jpg b/src/static/images/2019/07_Performance/hero_xl.jpg old mode 100755 new mode 100644 index 76875acb4b4..b0fcd0f8406 Binary files a/src/static/images/2019/07_Performance/hero_xl.jpg and b/src/static/images/2019/07_Performance/hero_xl.jpg differ diff --git a/src/static/images/2019/07_Performance/nav-timing.png b/src/static/images/2019/07_Performance/nav-timing.png index 4aa3f51123c..ff7aafc3722 100644 Binary files a/src/static/images/2019/07_Performance/nav-timing.png and b/src/static/images/2019/07_Performance/nav-timing.png differ diff --git a/src/static/images/2019/08_Security/hero_xl.jpg b/src/static/images/2019/08_Security/hero_xl.jpg old mode 100755 new mode 100644 index 719d419dca0..3948178533a Binary files a/src/static/images/2019/08_Security/hero_xl.jpg and b/src/static/images/2019/08_Security/hero_xl.jpg differ diff --git a/src/static/images/2019/09_Accessibility/example-of-a-skip-link-on-google.com.png b/src/static/images/2019/09_Accessibility/example-of-a-skip-link-on-google.com.png old mode 100755 new mode 100644 index 3c4d17335ea..a669572f173 Binary files a/src/static/images/2019/09_Accessibility/example-of-a-skip-link-on-google.com.png and b/src/static/images/2019/09_Accessibility/example-of-a-skip-link-on-google.com.png differ diff --git a/src/static/images/2019/09_Accessibility/hero_xl.jpg b/src/static/images/2019/09_Accessibility/hero_xl.jpg old mode 100755 new mode 100644 index 1d707ef4ca5..ff572c40eec Binary files a/src/static/images/2019/09_Accessibility/hero_xl.jpg and b/src/static/images/2019/09_Accessibility/hero_xl.jpg differ diff --git a/src/static/images/2019/10_SEO/hero_xl.jpg b/src/static/images/2019/10_SEO/hero_xl.jpg old mode 100755 new mode 100644 index 7a147b0bffe..7cc07dacec7 Binary files a/src/static/images/2019/10_SEO/hero_xl.jpg and b/src/static/images/2019/10_SEO/hero_xl.jpg differ diff --git a/src/static/images/2019/11_PWA/hero_xl.jpg b/src/static/images/2019/11_PWA/hero_xl.jpg old mode 100755 new mode 100644 index e785608e142..c33b227d306 Binary files a/src/static/images/2019/11_PWA/hero_xl.jpg and b/src/static/images/2019/11_PWA/hero_xl.jpg differ diff --git a/src/static/images/2019/12_Mobile_Web/hero_xl.jpg b/src/static/images/2019/12_Mobile_Web/hero_xl.jpg old mode 100755 new mode 100644 index cfe3f589d33..3d953b9d199 Binary files a/src/static/images/2019/12_Mobile_Web/hero_xl.jpg and b/src/static/images/2019/12_Mobile_Web/hero_xl.jpg differ diff --git a/src/static/images/2019/13_Ecommerce/hero_xl.jpg b/src/static/images/2019/13_Ecommerce/hero_xl.jpg old mode 100755 new mode 100644 index b9f64224020..038d10d8015 Binary files a/src/static/images/2019/13_Ecommerce/hero_xl.jpg and b/src/static/images/2019/13_Ecommerce/hero_xl.jpg differ diff --git a/src/static/images/2019/14_CMS/hero_xl.jpg b/src/static/images/2019/14_CMS/hero_xl.jpg old mode 100755 new mode 100644 index e7bcc1f00db..e82af6eb00e Binary files a/src/static/images/2019/14_CMS/hero_xl.jpg and b/src/static/images/2019/14_CMS/hero_xl.jpg differ diff --git a/src/static/images/2019/15_Compression/hero_xl.jpg b/src/static/images/2019/15_Compression/hero_xl.jpg old mode 100755 new mode 100644 index a22536eefb5..d12a4700438 Binary files a/src/static/images/2019/15_Compression/hero_xl.jpg and b/src/static/images/2019/15_Compression/hero_xl.jpg differ diff --git a/src/static/images/2019/16_Caching/hero_xl.jpg b/src/static/images/2019/16_Caching/hero_xl.jpg old mode 100755 new mode 100644 index a6c0e13d6e8..a78eba6f7f6 Binary files a/src/static/images/2019/16_Caching/hero_xl.jpg and b/src/static/images/2019/16_Caching/hero_xl.jpg differ diff --git a/src/static/images/2019/17_CDN/hero_xl.jpg b/src/static/images/2019/17_CDN/hero_xl.jpg old mode 100755 new mode 100644 index 8194e047f83..7d7a781c147 Binary files a/src/static/images/2019/17_CDN/hero_xl.jpg and b/src/static/images/2019/17_CDN/hero_xl.jpg differ diff --git a/src/static/images/2019/18_Page_Weight/hero_lg.jpg b/src/static/images/2019/18_Page_Weight/hero_lg.jpg index 201a50fc1ee..6dc346688ee 100644 Binary files a/src/static/images/2019/18_Page_Weight/hero_lg.jpg and b/src/static/images/2019/18_Page_Weight/hero_lg.jpg differ diff --git a/src/static/images/2019/18_Page_Weight/hero_sm.jpg b/src/static/images/2019/18_Page_Weight/hero_sm.jpg index d1226f39941..5985fcff7be 100644 Binary files a/src/static/images/2019/18_Page_Weight/hero_sm.jpg and b/src/static/images/2019/18_Page_Weight/hero_sm.jpg differ diff --git a/src/static/images/2019/18_Page_Weight/hero_xl.jpg b/src/static/images/2019/18_Page_Weight/hero_xl.jpg old mode 100755 new mode 100644 index c401d3dc1c1..b626f5302d2 Binary files a/src/static/images/2019/18_Page_Weight/hero_xl.jpg and b/src/static/images/2019/18_Page_Weight/hero_xl.jpg differ diff --git a/src/static/images/2019/19_Resource_Hints/hero_xl.jpg b/src/static/images/2019/19_Resource_Hints/hero_xl.jpg old mode 100755 new mode 100644 index a0479900aa1..4b1cc0ac1b3 Binary files a/src/static/images/2019/19_Resource_Hints/hero_xl.jpg and b/src/static/images/2019/19_Resource_Hints/hero_xl.jpg differ diff --git a/src/static/images/2019/20_HTTP_2/hero_xl.jpg b/src/static/images/2019/20_HTTP_2/hero_xl.jpg old mode 100755 new mode 100644 index 6288119a819..d287716c313 Binary files a/src/static/images/2019/20_HTTP_2/hero_xl.jpg and b/src/static/images/2019/20_HTTP_2/hero_xl.jpg differ diff --git a/src/static/images/English.png b/src/static/images/English.png index f4c292ae317..03883e8c29a 100644 Binary files a/src/static/images/English.png and b/src/static/images/English.png differ diff --git a/src/static/images/avatars/0.jpg b/src/static/images/avatars/0.jpg index 61f0f43834a..e69b895203e 100644 Binary files a/src/static/images/avatars/0.jpg and b/src/static/images/avatars/0.jpg differ diff --git a/src/static/images/avatars/1.jpg b/src/static/images/avatars/1.jpg index e321efa5aed..159d6a4dbbf 100644 Binary files a/src/static/images/avatars/1.jpg and b/src/static/images/avatars/1.jpg differ diff --git a/src/static/images/avatars/10.jpg b/src/static/images/avatars/10.jpg index 28eb0571520..bbd05856b3d 100644 Binary files a/src/static/images/avatars/10.jpg and b/src/static/images/avatars/10.jpg differ diff --git a/src/static/images/avatars/11.jpg b/src/static/images/avatars/11.jpg index ceb8ca35fb1..2151b3d162d 100644 Binary files a/src/static/images/avatars/11.jpg and b/src/static/images/avatars/11.jpg differ diff --git a/src/static/images/avatars/12.jpg b/src/static/images/avatars/12.jpg index 5774cc88a7b..63efac9ca66 100644 Binary files a/src/static/images/avatars/12.jpg and b/src/static/images/avatars/12.jpg differ diff --git a/src/static/images/avatars/13.jpg b/src/static/images/avatars/13.jpg index 49c59066335..773dc0fefe9 100644 Binary files a/src/static/images/avatars/13.jpg and b/src/static/images/avatars/13.jpg differ diff --git a/src/static/images/avatars/14.jpg b/src/static/images/avatars/14.jpg index 4edc967d915..939130b0d1c 100644 Binary files a/src/static/images/avatars/14.jpg and b/src/static/images/avatars/14.jpg differ diff --git a/src/static/images/avatars/2.jpg b/src/static/images/avatars/2.jpg index df8ef0a0e32..ebc7f2b5f3b 100644 Binary files a/src/static/images/avatars/2.jpg and b/src/static/images/avatars/2.jpg differ diff --git a/src/static/images/avatars/3.jpg b/src/static/images/avatars/3.jpg index 3e8e00ed884..718e7b8bf36 100644 Binary files a/src/static/images/avatars/3.jpg and b/src/static/images/avatars/3.jpg differ diff --git a/src/static/images/avatars/4.jpg b/src/static/images/avatars/4.jpg index 84413320159..06fd3887882 100644 Binary files a/src/static/images/avatars/4.jpg and b/src/static/images/avatars/4.jpg differ diff --git a/src/static/images/avatars/5.jpg b/src/static/images/avatars/5.jpg index acd10c984a8..f70f8165aad 100644 Binary files a/src/static/images/avatars/5.jpg and b/src/static/images/avatars/5.jpg differ diff --git a/src/static/images/avatars/6.jpg b/src/static/images/avatars/6.jpg index 89aa6f4a3d5..98c209a0a4b 100644 Binary files a/src/static/images/avatars/6.jpg and b/src/static/images/avatars/6.jpg differ diff --git a/src/static/images/avatars/7.jpg b/src/static/images/avatars/7.jpg index 54ffcba5019..f55598b6a26 100644 Binary files a/src/static/images/avatars/7.jpg and b/src/static/images/avatars/7.jpg differ diff --git a/src/static/images/avatars/8.jpg b/src/static/images/avatars/8.jpg index 738c9e65a9a..418f8efb32a 100644 Binary files a/src/static/images/avatars/8.jpg and b/src/static/images/avatars/8.jpg differ diff --git a/src/static/images/avatars/9.jpg b/src/static/images/avatars/9.jpg index b657c8d69fb..29954d53fa8 100644 Binary files a/src/static/images/avatars/9.jpg and b/src/static/images/avatars/9.jpg differ diff --git a/src/static/images/character-file.png b/src/static/images/character-file.png index b79caf9b2cd..0e85e59076d 100644 Binary files a/src/static/images/character-file.png and b/src/static/images/character-file.png differ diff --git a/src/static/images/character-hat.png b/src/static/images/character-hat.png index 2fe6172f0e5..1917f175714 100644 Binary files a/src/static/images/character-hat.png and b/src/static/images/character-hat.png differ diff --git a/src/static/images/character-markup.png b/src/static/images/character-markup.png index a2b40aab73a..9045fabbe75 100644 Binary files a/src/static/images/character-markup.png and b/src/static/images/character-markup.png differ diff --git a/src/static/images/character-measure.png b/src/static/images/character-measure.png index 5e5f546ec6f..3fcc04feafe 100644 Binary files a/src/static/images/character-measure.png and b/src/static/images/character-measure.png differ diff --git a/src/static/images/character-painter.png b/src/static/images/character-painter.png index 73372db5daf..60b9bf4826d 100644 Binary files a/src/static/images/character-painter.png and b/src/static/images/character-painter.png differ diff --git a/src/static/images/character-star.png b/src/static/images/character-star.png index dfad84c7ce3..7270e08a3a4 100644 Binary files a/src/static/images/character-star.png and b/src/static/images/character-star.png differ diff --git a/src/static/images/close.png b/src/static/images/close.png index 6d1ff4d0109..2b17d9e5fcb 100644 Binary files a/src/static/images/close.png and b/src/static/images/close.png differ diff --git a/src/static/images/dropdown-arrow.png b/src/static/images/dropdown-arrow.png index b49ed1e7cd5..c31f5b64703 100644 Binary files a/src/static/images/dropdown-arrow.png and b/src/static/images/dropdown-arrow.png differ diff --git a/src/static/images/github.png b/src/static/images/github.png index 2e578211efa..c02911e2386 100644 Binary files a/src/static/images/github.png and b/src/static/images/github.png differ diff --git a/src/static/images/ha-home.png b/src/static/images/ha-home.png index 8e0a37c3524..9d4d4d72047 100644 Binary files a/src/static/images/ha-home.png and b/src/static/images/ha-home.png differ diff --git a/src/static/images/ha.png b/src/static/images/ha.png index 13c8404029a..c282fabb7f4 100644 Binary files a/src/static/images/ha.png and b/src/static/images/ha.png differ diff --git a/src/static/images/home-hero-2019.png b/src/static/images/home-hero-2019.png index 9317d874f97..d89d94acc4c 100644 Binary files a/src/static/images/home-hero-2019.png and b/src/static/images/home-hero-2019.png differ diff --git a/src/static/images/home-hero.png b/src/static/images/home-hero.png index d160015865f..7318b14dc54 100644 Binary files a/src/static/images/home-hero.png and b/src/static/images/home-hero.png differ diff --git a/src/static/images/intro-background-fit.png b/src/static/images/intro-background-fit.png index 2b71d8f1272..f03279b20b6 100644 Binary files a/src/static/images/intro-background-fit.png and b/src/static/images/intro-background-fit.png differ diff --git a/src/static/images/intro-background.png b/src/static/images/intro-background.png index 10e8f7b86ae..970b72eb6a7 100644 Binary files a/src/static/images/intro-background.png and b/src/static/images/intro-background.png differ diff --git a/src/static/images/logo.png b/src/static/images/logo.png index e3ef13253de..b033bcca762 100644 Binary files a/src/static/images/logo.png and b/src/static/images/logo.png differ diff --git a/src/static/images/logo@2x.png b/src/static/images/logo@2x.png index 64f9ddde4c9..4541715878a 100644 Binary files a/src/static/images/logo@2x.png and b/src/static/images/logo@2x.png differ diff --git a/src/static/images/menu.png b/src/static/images/menu.png index 390b01eeb09..187009b0981 100644 Binary files a/src/static/images/menu.png and b/src/static/images/menu.png differ diff --git a/src/static/images/methodology-banner.png b/src/static/images/methodology-banner.png index 61814e859b0..5594793367a 100644 Binary files a/src/static/images/methodology-banner.png and b/src/static/images/methodology-banner.png differ diff --git a/src/static/images/methodology-characters.png b/src/static/images/methodology-characters.png index 361023a92f8..d281b2d27c0 100644 Binary files a/src/static/images/methodology-characters.png and b/src/static/images/methodology-characters.png differ diff --git a/src/static/images/quote.png b/src/static/images/quote.png deleted file mode 100644 index 2e68de368b5..00000000000 Binary files a/src/static/images/quote.png and /dev/null differ diff --git a/src/static/images/twitter.png b/src/static/images/twitter.png old mode 100755 new mode 100644 index 4bd65409382..f58bc9a0c6f Binary files a/src/static/images/twitter.png and b/src/static/images/twitter.png differ diff --git a/src/templates/en/2019/base.html b/src/templates/en/2019/base.html index e9c2617e0e8..34195398860 100644 --- a/src/templates/en/2019/base.html +++ b/src/templates/en/2019/base.html @@ -26,8 +26,9 @@ {% endif %} {{ language_switcher() }} - - +