diff --git a/src/README.md b/src/README.md index f2579c1e33a..e2116e623ef 100644 --- a/src/README.md +++ b/src/README.md @@ -58,13 +58,7 @@ npm install npm run generate ``` -3. For generating PDFs of the ebook, WeasyPrint will need some additional libraries: - -``` -brew install cairo -brew install pango -brew install gdk-pixbuf -``` +3. For generating PDFs of the ebook, you need to install Prince. Follow the instructions on [the Prince Website](https://www.princexml.com/). 4. To actually generate the ebooks, start your local server, then run the following: @@ -75,6 +69,22 @@ npm run ebook_2019_ja (TODO: make this a script to handle all languages and years at some point) +It is also possible to generate the ebook from the website, with some optional params (e.g. to print it!) + +``` +prince "https://almanac.httparchive.org/en/2019/ebook?print&inside-margin=4cm" -o web_almanac_2019_en.pdf --pdf-profile='PDF/UA-1' +``` + +Note `--pdf-profile='PDF/UA-1'` may not be needed if just intend to print. + +Params accepted are: + +- print - this ads left, right pages, footnotes, and sets roman numerals for front matter page numbers and adds footnotes. It is used by default when running `npm run ebook_2019_en` but we could change that if prefer a less print-like ebook. +- page-size - this allows you to override the default page size of A4 +- inside-margin - this allows you to set an inside margin for binding (e.g. on right for left hand pages and vice versa) + +You can also download the HTML and override the inline styles there if you want to customise this for something we haven;t exposed as a param. + ## Deploying changes If you've been added to the "App Engine Deployers" role in the GCP project, you're able to push code changes to the production website. diff --git a/src/main.py b/src/main.py index 024912d9139..ccd30436d60 100644 --- a/src/main.py +++ b/src/main.py @@ -130,21 +130,39 @@ def get_ebook_methodology(lang, year): return False methodology_maincontent = methodology_maincontent.group(1) + # Replace methodology links to full anchor link (e.g. #introduction -> #methodology-introduction) methodology_maincontent = re.sub('href="#', 'href="#methodology-', methodology_maincontent) + # Replace header ids to full id (e.g.

->

) methodology_maincontent = re.sub(' #) methodology_maincontent = re.sub('href="\/%s\/%s\/' % (lang, year), 'href="#', methodology_maincontent) + # For external links add footnote span + methodology_maincontent = re.sub('href="http(.*?)"(.*?)>(.*?)<\/a>', 'href="http\\1"\\2>\\3http\\1', methodology_maincontent) + # Replace figure image links to full site, to avoid 127.0.0.1:8080 links methodology_maincontent = re.sub('href="\/', 'href="https://almanac.httparchive.org/', methodology_maincontent) + # Replace other chapter references with hash to anchor link (e.g. ./javascript#fig-1 -> #javascript-fig-1) + methodology_maincontent = re.sub('href="./([a-z0-9-]*)#', 'href="#\\1-', methodology_maincontent) + # Replace other chapter references to anchor link (e.g. ./javascript -> #javascript) methodology_maincontent = re.sub('href="\.\/', 'href="#', methodology_maincontent) + # Replace double-hashed URLs (e.g. #contributors#patrickhulce -> #contributors-patrickhulce) methodology_maincontent = re.sub('href="#([a-z0-9-]*)#', 'href="#\\1-', methodology_maincontent) + # Remove lazy-loading attributes + methodology_maincontent = re.sub(' loading="lazy"', '', methodology_maincontent) return methodology_maincontent +# This function takes a string and adds the footnote links for printing +def add_footnote_links(html): + return re.sub('href="http(.*?)"(.*?)>(.*?)<\/a>', 'href="http\\1"\\2>\\3http\\1', html) + + # Make these functions available in templates. app.jinja_env.globals['get_view_args'] = get_view_args app.jinja_env.globals['chapter_lang_exists'] = chapter_lang_exists app.jinja_env.globals['ebook_exists'] = ebook_exists app.jinja_env.globals['HTTP_STATUS_CODES'] = HTTP_STATUS_CODES app.jinja_env.globals['get_ebook_methodology'] = get_ebook_methodology +app.jinja_env.globals['add_footnote_links'] = add_footnote_links @app.route('///') diff --git a/src/package.json b/src/package.json index bfe611f538f..c9318c61ebb 100644 --- a/src/package.json +++ b/src/package.json @@ -15,8 +15,8 @@ "homepage": "https://github.com/HTTPArchive/almanac.httparchive.org#readme", "scripts": { "generate": "node ./tools/generate", - "ebook_2019_en": "weasyprint http://127.0.0.1:8080/en/2019/ebook static/pdfs/web_almanac_2019_en.pdf", - "ebook_2019_ja": "weasyprint http://127.0.0.1:8080/ja/2019/ebook static/pdfs/web_almanac_2019_ja.pdf", + "ebook_2019_en": "prince http://127.0.0.1:8080/en/2019/ebook?print -o static/pdfs/web_almanac_2019_en.pdf --pdf-profile='PDF/UA-1'", + "ebook_2019_ja": "prince http://127.0.0.1:8080/ja/2019/ebook?print -o static/pdfs/web_almanac_2019_ja.pdf --pdf-profile='PDF/UA-1'", "deploy": "echo \"Y\" | gcloud app deploy --project webalmanac --stop-previous-version" }, "devDependencies": { diff --git a/src/static/css/ebook.css b/src/static/css/ebook.css index fdbe8055764..4ffc443fc1d 100644 --- a/src/static/css/ebook.css +++ b/src/static/css/ebook.css @@ -1,3 +1,52 @@ +#title .title { + color: white; +} + +#title { + background: #5C687D; + background: transparent linear-gradient(#5C687D 70%, transparent 30%); + /* background: transparent url(/static/images/intro-background-fit.svg) bottom left / 100% 100% no-repeat; */ + background: transparent url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxOTIwIiBoZWlnaHQ9IjEyNTAiIHZpZXdCb3g9IjAgMCAxOTIwIDEyNTAiIHByZXNlcnZlQXNwZWN0UmF0aW89Im5vbmUiPg0KICA8ZGVmcz4NCiAgICA8c3R5bGU+DQogICAgICBzdmd7YmFja2dyb3VuZDojZmZmfQ0KICAgICAgLmNscy0xe2ZpbGw6I2E4Y2FiYTtmaWxsLXJ1bGU6ZXZlbm9kZDtvcGFjaXR5Oi4wNX0NCiAgICA8L3N0eWxlPg0KICA8L2RlZnM+DQogIDxwYXRoIGNsYXNzPSJjbHMtMSIgZD0iTS0yMzEgODloMjA4OHY2NTFsLTIwODggMzYwVjg5eiIvPg0KICA8cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0tNDcwIDIzOWgyMDg4djY1MWwtMjA4OCAzNjBWMjM5eiIvPg0KICA8cGF0aCBkPSJNLTE0NC0xOWgyMDg4djY1MUwtMTQ0IDk5MlYtMTl6IiBmaWxsPSIjMWEyYjQ5IiBvcGFjaXR5PSIuNzUiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPg0KICA8cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0tNDcwLTgzaDIwODh2NjUxTC00NzAgOTI4Vi04M3oiLz4NCiAgPHBhdGggZD0iTS0yMzItNDhoMjA4OHY2NTFMLTIzMiA5NjNWLTQ4eiIgZmlsbD0iI2YyZjJmMiIgb3BhY2l0eT0iLjA1IiBmaWxsLXJ1bGU9ImV2ZW5vZGQiLz4NCjwvc3ZnPg0K); + background-position: bottom left; + background-repeat: no-repeat; + background-size: 100% 100%; +} + +.intro-year { + margin: 0; + width: auto; + color: #F7F779; + font-size: 160px; + font-size: 10rem; + line-height: 100%; + font-weight: bold; +} + +#title h1.title::before { + border-bottom: none; +} + +#title h1.title { + font-size: 80px; + font-size: 5rem; + font-weight: 700; +} + +#title h2.title { + font-size: 32px; + font-size: 2rem; + font-weight: 300; +} + +.intro-image { + border-radius: 10px; + display: block; + margin: 20px 0; + padding-left: 10.5%; + width: 80%; + height: auto; +} + #title img { margin: 0 auto; } @@ -15,14 +64,16 @@ margin: 0; } -.table-wrap { - display: block; - max-width: 100%; +th, td { + padding: 5px; +} + +th { text-align: center; } -th, td { - padding: 5px; +td { + text-align: left; } tbody tr:nth-child(even) { @@ -42,17 +93,12 @@ tbody tr:nth-child(even) { color: #0b1423; } -.intro-image { - background-color: grey; - border-radius: 10px; - display: block; - margin: 20px 0; -} - .team { + display: flex; + flex-direction: row; + flex-wrap: wrap; overflow: hidden; - height: 100px; - margin: 0 0 24px 0; + justify-content: space-between; } .team img { @@ -63,21 +109,18 @@ tbody tr:nth-child(even) { .contributors { padding: 0; -} - -.contributor-grid { - margin: 0 -15px; - justify-content: center; - width: 10000px; - max-width: 100%; + columns: 2; + column-gap: 30px; + margin: 50px 0 0 0; } .contributor { - margin-top: 20px; + margin-bottom: 20px; width: 600px; max-width: 100%; vertical-align: top; overflow: auto; + min-height: 70px; } .contributor-avatar { @@ -91,10 +134,6 @@ tbody tr:nth-child(even) { float: left; } -ul li.contributor::before { - content: ""; -} - .contributor-social a { display: inline-block; margin: 0 5px; @@ -115,20 +154,37 @@ ul li.contributor::before { .contributor-team:last-child::after { content: ''; } +.social-icon { + height: 15px; + width: 15px; +} -.contributors button { - background: #f7f779; - color: #333; +.content ul li::before { + content: none; } -/* Join the team card */ -.contributor-join { +.content ul li { + list-style: disc; +} + +.content ul li.contributor { + list-style: none; + page-break-inside: avoid; +} + +.code-block pre { + overflow: visible; + white-space: pre-wrap; +} + +section.chapter {prince-pdf-tag-type: Art;} + +.fn { display: none; } -.social-icon { - height: 20px; - width: 20px; +@prince-pdf { + prince-pdf-display-doc-title: true; } @page { @@ -136,30 +192,64 @@ ul li.contributor::before { padding: 0; font-family: 'Lato', sans-serif; font-size: 10pt; + size: A4; + + @top-left { + width: 100%; + margin: 30pt 0 10pt 0; + border-bottom: .50pt solid #666; + color: #333; + font-family: 'Poppins', sans-serif; + } + + @top-right { + width: 100%; + margin: 30pt 0 10pt 0; + color: #333; + font-family: 'Poppins', sans-serif; + } @bottom-left { width: 100%; margin: 10pt 0 30pt 0; - border-top: .25pt solid #666; + border-top: .50pt solid #666; color: #333; + font-family: 'Poppins', sans-serif; } @bottom-right { - width: 100px; + width: 100%; margin: 10pt 0 30pt 0; border-top: .25pt solid #666; - content: counter(page); + color: #333; + font-family: 'Poppins', sans-serif; } +} + +@page :blank { + + @top-left { + content: ''; + } @top-right { - content: string(chapter_subtitle) string(chapter_title); - margin: 30pt 0 10pt 0; - color: #333; + content: ''; } + } -@page :first { +.no-header-or-footer { + page: no-header-or-footer; +} +@page no-header-or-footer { + + @top-left { + content: ''; + } + @top-right { + content: ''; + } @bottom-left { content: ''; border: none; @@ -168,13 +258,47 @@ ul li.contributor::before { content: ''; border: none; } + +} + +#toc, #foreword { + page: front-matter; +} + +@page :first { + + background: #5C687D; + background: transparent linear-gradient(#5C687D 70%, transparent 30%); + /* background: transparent url(/static/images/intro-background-fit.svg) bottom left / 100% 100% no-repeat; */ + background: transparent url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxOTIwIiBoZWlnaHQ9IjEyNTAiIHZpZXdCb3g9IjAgMCAxOTIwIDEyNTAiIHByZXNlcnZlQXNwZWN0UmF0aW89Im5vbmUiPg0KICA8ZGVmcz4NCiAgICA8c3R5bGU+DQogICAgICBzdmd7YmFja2dyb3VuZDojZmZmfQ0KICAgICAgLmNscy0xe2ZpbGw6I2E4Y2FiYTtmaWxsLXJ1bGU6ZXZlbm9kZDtvcGFjaXR5Oi4wNX0NCiAgICA8L3N0eWxlPg0KICA8L2RlZnM+DQogIDxwYXRoIGNsYXNzPSJjbHMtMSIgZD0iTS0yMzEgODloMjA4OHY2NTFsLTIwODggMzYwVjg5eiIvPg0KICA8cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0tNDcwIDIzOWgyMDg4djY1MWwtMjA4OCAzNjBWMjM5eiIvPg0KICA8cGF0aCBkPSJNLTE0NC0xOWgyMDg4djY1MUwtMTQ0IDk5MlYtMTl6IiBmaWxsPSIjMWEyYjQ5IiBvcGFjaXR5PSIuNzUiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPg0KICA8cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0tNDcwLTgzaDIwODh2NjUxTC00NzAgOTI4Vi04M3oiLz4NCiAgPHBhdGggZD0iTS0yMzItNDhoMjA4OHY2NTFMLTIzMiA5NjNWLTQ4eiIgZmlsbD0iI2YyZjJmMiIgb3BhY2l0eT0iLjA1IiBmaWxsLXJ1bGU9ImV2ZW5vZGQiLz4NCjwvc3ZnPg0K); + background-position: bottom left; + background-repeat: no-repeat; + background-size: 100% 100%; + + @top-left { + content: ''; + border-bottom: none; + } @top-right { content: ''; } + @bottom-left { + content: ''; + border: none; + } + @bottom-right { + content: ''; + border: none; + } + } @media print { - + + #title { + background: none; + } + :root { font-size: 14px; } @@ -193,24 +317,27 @@ ul li.contributor::before { .content > section { page-break-after: always; - } - - #toc a { - display: table; - min-width: 500px; } #toc a::after { - float: right; - content: target-counter(attr(href), page); + content: leader('.') target-counter(attr(href), page); + } +} + + section h1 { + string-set: chapter-title content(); } - section.chapter h1.title { - string-set: chapter_title content(); + section div.subtitle { + string-set: chapter-subtitle ""; } section.chapter div.subtitle { - string-set: chapter_subtitle content() " - "; + string-set: chapter-subtitle content() " : "; + } + + figure { + margin: 0; } figure, @@ -220,6 +347,7 @@ ul li.contributor::before { figcaption { max-width: 100%; text-align: center; + page-break-inside: avoid; } figure .anchor-link { @@ -234,13 +362,63 @@ ul li.contributor::before { width: 1000px; } + figure iframe.video-embed { + display: none; + } + + figure .video-fallback-image { + display: block; + } + table { display: table; border-spacing: 2px; border-color: grey; + page-break-inside: avoid; + } + + h1, h2, h3, h4, h5 { + font-weight: bold; + page-break-after: avoid; + page-break-inside:avoid; + } + + h1+p, h2+p, h3+p { + page-break-before: avoid; + } + + .authors li { + page-break-inside: avoid; + } + + .fn { + display: inline; + float: footnote; + counter-increment: footnote; + font-size: 10px; + font-size: 0.625rem; + font-style: italic; + text-align: left; + margin: 0 0 0 18px; + line-height: normal; } -} + .fn::footnote-call { + content: counter(footnote); + font-size: 6px; + font-size: 0.375rem; + vertical-align: super; + line-height: none; + } + + .fn::footnote-marker { + text-align: left; + font-size: 10px; + font-size: 0.625rem; + font-weight: normal; + min-width: 18px; + } +} .content section.authors li { display: flex; diff --git a/src/static/pdfs/web_almanac_2019_en.pdf b/src/static/pdfs/web_almanac_2019_en.pdf index 2f01c236995..547126a7b7d 100644 Binary files a/src/static/pdfs/web_almanac_2019_en.pdf and b/src/static/pdfs/web_almanac_2019_en.pdf differ diff --git a/src/static/pdfs/web_almanac_2019_ja.pdf b/src/static/pdfs/web_almanac_2019_ja.pdf index d8885a63fd5..31035c14466 100644 Binary files a/src/static/pdfs/web_almanac_2019_ja.pdf and b/src/static/pdfs/web_almanac_2019_ja.pdf differ diff --git a/src/templates/ar/2019/base.html b/src/templates/ar/2019/base.html index 8a13590be34..2a31624a682 100644 --- a/src/templates/ar/2019/base.html +++ b/src/templates/ar/2019/base.html @@ -112,9 +112,11 @@

{{ self.foreword_title() }}

— Rick Viscomi, creator of the Web Almanac

{% endblock %} -{% block appendix %}Appendices{% endblock %} +{% block appendix %}Appendix{% endblock %} +{% block appendices %}Appendices{% endblock %} -{% block ebook_download %}Download the entire {{ year }} Web Almanac in PDF format{% endblock %} +{% block ebook_download %}Download the entire {{ year }} Web Almanac in PDF format (generated with www.princexml.com){% endblock %} +{% block ebook_download_note %}(generated with www.princexml.com){% endblock %} {% set localizedPartTitles = { diff --git a/src/templates/base/2019/base_chapter.html b/src/templates/base/2019/base_chapter.html index 9e8a2b7677b..42b157236ed 100644 --- a/src/templates/base/2019/base_chapter.html +++ b/src/templates/base/2019/base_chapter.html @@ -110,7 +110,7 @@ {% macro render_authors() %} {% for author in metadata.get('authors') %} - {% if loop.index == 1 %} + {% if loop.index == 1 %}

{% if loop.length == 1 %}{{ self.author() }}{% endif -%} @@ -120,7 +120,7 @@

+ - + {% endblock %} diff --git a/src/templates/base/2019/ebook.ejs.html b/src/templates/base/2019/ebook.ejs.html index 20d86bf4d84..4cad8c01727 100644 --- a/src/templates/base/2019/ebook.ejs.html +++ b/src/templates/base/2019/ebook.ejs.html @@ -6,108 +6,115 @@ <% for (let part of ebook.parts) { %> <% for (let chapter of part.chapters) { %> -
-
-
- {{ self.part() }} <%= chapter.metadata.part_number %> {{ self.chapter() }} <%= chapter.metadata.chapter_number %> -
-

- <%= chapter.metadata.title %> -

- {% set metadata = <%- JSON.stringify(chapter.metadata) %> %} - {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - - - - - - - - - - - - - <% const byline = (prefix, suffix, contributor_type) => { - if (!chapter.metadata[contributor_type] || !chapter.metadata[contributor_type].length || chapter.metadata[contributor_type][0] == '') return; + {% set metadata = <%- JSON.stringify(chapter.metadata) %> %} + {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
+
- let contributors = chapter.metadata[contributor_type].map(function(x) { return '' + ebook.config.contributors[x].name + '' }); - let contributors_sentence = contributors.join(', ').replace(/,(?=[^,]*$)/, ', {{ self.and() }}'); +
+ {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }} +
+

+ {{ metadata.get('title') }} + {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %} +

- return `
${prefix} ${contributors_sentence}${suffix}
`; - } %> + + + + + + + + + + - <%- byline('{{ self.written_by_before() }}', '{{ self.written_by_after() }}', 'authors') %> - <%- byline('{{ self.reviewed_by_before() }}', '{{ self.reviewed_by_after() }}', 'reviewers') %> - <%- byline('{{ self.translated_by_before() }}', '{{ self.translated_by_after() }}', 'translators') %> - - <%- chapter.body %> -
+
{{ self.written_by_before() }} + {% for author in metadata.get('authors') %} + {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} + {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} + {% endfor %}{{ self.written_by_after() }} +
+ +
{{ self.reviewed_by_before() }} + {% for reviewer in metadata.get('reviewers') %} + {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} + {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} + {% endfor %}{{ self.reviewed_by_after() }} +
+ + {% if metadata.get('translators') | length >= 1 %} +
{{ self.translated_by_before() }} + {% for translator in metadata.get('translators') %} + {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} + {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} + {% endfor %}{{ self.translated_by_after() }} +
+ {% endif %} + <%- chapter.body %> + -
- <% let authors = chapter.metadata['authors'].map(x => { - var authordata = ebook.config.contributors[x]; - authordata.id=x; - return authordata; - }); - %> -

<%= (authors.length > 1) ? 'Authors' : 'Author' %>

-
+ {% endfor %} + +
<% } %> <% } %> diff --git a/src/templates/base/2019/table_of_contents.html b/src/templates/base/2019/table_of_contents.html index 1e705e6ece5..00874f3a995 100644 --- a/src/templates/base/2019/table_of_contents.html +++ b/src/templates/base/2019/table_of_contents.html @@ -110,7 +110,7 @@

{{ self.part() }} {{ localizedPartTitles[part_config.part]

{% endfor %}
-

{{ self.appendix() }}

+

{{ self.appendices() }}

{{ self.methodology_title() }} @@ -124,7 +124,10 @@

{{ self.appendix() }}

{% if ebook_exists(lang, year) %} -

{{ self.ebook_download() }}

+

+ {{ self.ebook_download() }}
+ {{ self.ebook_download_note() }} +

{% endif %}
diff --git a/src/templates/en/2019/accessibility_statement.html b/src/templates/en/2019/accessibility_statement.html index 9bda4433141..66c8b8f0a14 100644 --- a/src/templates/en/2019/accessibility_statement.html +++ b/src/templates/en/2019/accessibility_statement.html @@ -70,7 +70,11 @@

Co

In some chapters, we also include other content on the site, not created by ourselves, including YouTube videos, PDF links or links to other articles, which do not meet the strict criteria required of WCAG 2.1 level AAA. See note below on external content.

- + +

+ The PDF version of the Web Almanac follows PDF accessibility best practices and meets the PDF/UA-1 standard. +

+

External content

@@ -94,15 +98,19 @@

WAI-ARIA where appropriate), enhanced with CSS for styling and limited JavaScript for some interactive components. The website makes use of modern development practices such as CSS Grid, Fetch, and WOFF2 Fonts, which are not supported in older browsers such as IE 11. The website is still fully functional in those browsers but may not be as visually appealing. No extra plugins or libraries should be required to view the website.

+

+ The Web Almanac PDF follows the same accessibility standards as the website and additionally, is a structurally tagged to aid accessibility. +

Assessment Approach

- Self-evaluation: the content was evaluated by the Web Almanac team using their own expertise and a number of tools including the WAVE Accessibility Tool, the Firefox Accessibility Inspector and the AXE Chrome plugin. + Self-evaluation: the content was evaluated by the Web Almanac team using their own expertise and a number of tools including the WAVE Accessibility Tool, the Firefox Accessibility Inspector and the AXE Chrome plugin The Web Almanac PDF was tested with an Accessibility Scan in Acrobat Reader Pro DC.

-
+ +

Feedback

diff --git a/src/templates/en/2019/base.html b/src/templates/en/2019/base.html index 646fc955497..414d56f053f 100644 --- a/src/templates/en/2019/base.html +++ b/src/templates/en/2019/base.html @@ -108,9 +108,11 @@

— Rick Viscomi, creator of the Web Almanac

{% endblock %} -{% block appendix %}Appendices{% endblock %} +{% block appendix %}Appendix{% endblock %} +{% block appendices %}Appendices{% endblock %} {% block ebook_download %}Download the entire {{ year }} Web Almanac in PDF format{% endblock %} +{% block ebook_download_note %}(generated with www.princexml.com){% endblock %} {% set localizedPartTitles = { diff --git a/src/templates/en/2019/base_ebook.html b/src/templates/en/2019/base_ebook.html index c1f88422619..9cb4b1d15c0 100644 --- a/src/templates/en/2019/base_ebook.html +++ b/src/templates/en/2019/base_ebook.html @@ -5,8 +5,8 @@ {% block date_published %}2020-05-10T12:00:00.000Z{% endblock %} {% block date_modified %}2020-05-14T00:00:00.000Z{% endblock %} -{% block intro_title %}The Web Almanac {{ year }}{% endblock %} -{% block intro_sub_title %}HTTP Archive's annual state of the web report{% endblock %} +{% block intro_title %}{{ year }}
Web Almanac{% endblock %} +{% block intro_sub_title %}HTTP Archive's annual
state of the web report{% endblock %} {% block about_title %}About The Web Almanac{% endblock %} diff --git a/src/templates/en/2019/ebook.html b/src/templates/en/2019/ebook.html index a29b1bb36bc..b8c6f8b2800 100644 --- a/src/templates/en/2019/ebook.html +++ b/src/templates/en/2019/ebook.html @@ -1,16 +1,15 @@ -{% extends "%s/2019/base_ebook.html" % lang %} {% set metadata = {} %} {% block chapters %} - -
-
+{% extends "%s/2019/base_ebook.html" % lang %} {% set metadata = {} %} {% block chapters %} {% set metadata = {"part_number":"I","chapter_number":1,"title":"JavaScript","description":"JavaScript chapter of the 2019 Web Almanac covering how much JavaScript we use on the web, compression, libraries and frameworks, loading, and source maps.","authors":["housseindjirdeh"],"reviewers":["obto","paulcalvano","mathiasbynens"],"translators":null,"discuss":"1756","results":"https://docs.google.com/spreadsheets/d/1kBTglETN_V9UjKqK_EFmFjRexJnQOmLLr-I2Tkotvic/","queries":"01_JavaScript","published":"2019-11-11","last_updated":"2020-05-20","chapter":"javascript"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
+
- {{ self.part() }} I {{ self.chapter() }} 1 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
-

- JavaScript +

+ {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

- {% set metadata = {"part_number":"I","chapter_number":1,"title":"JavaScript","description":"JavaScript chapter of the 2019 Web Almanac covering how much JavaScript we use on the web, compression, libraries and frameworks, loading, and source maps.","authors":["housseindjirdeh"],"reviewers":["obto","paulcalvano","mathiasbynens"],"translators":null,"discuss":"1756","results":"https://docs.google.com/spreadsheets/d/1kBTglETN_V9UjKqK_EFmFjRexJnQOmLLr-I2Tkotvic/","queries":"01_JavaScript","published":"2019-11-11","last_updated":"2020-05-20","chapter":"javascript"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -19,22 +18,30 @@

- + -
{{ self.written_by_before() }} Houssein Djirdeh{{ self.written_by_after() }}
-
{{ self.reviewed_by_before() }} David Fox, Paul Calvano, {{ self.and() }} Mathias Bynens{{ self.reviewed_by_after() }}
+
{{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
+
{{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
+ + {% if metadata.get('translators') | length >= 1 %} +
{{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
+ {% endif %}

Introduction

JavaScript is a scripting language that makes it possible to build interactive and complex experiences on the web. This includes responding to user interactions, updating dynamic content on a page, and so forth. Anything involving how a web page should behave when an event occurs is what JavaScript is used for.

The language specification itself, along with many community-built libraries and frameworks used by developers around the world, has changed and evolved ever since the language was created in 1995. JavaScript implementations and interpreters have also continued to progress, making the language usable in many environments, not only web browsers.

-

The HTTP Archive crawls millions of pages every month and runs them through a private instance of WebPageTest to store key information of every page. (You can learn more about this in our methodology). In the context of JavaScript, HTTP Archive provides extensive information on the usage of the language for the entire web. This chapter consolidates and analyzes many of these trends.

+

+ The HTTP Archivehttps://httparchive.org/ crawls millions of pageshttps://httparchive.org/reports/state-of-the-web#numUrls every month and runs them through a private instance of WebPageTesthttps://webpagetest.org/ to store key information of every page. (You can learn more about this in our methodology). In the context of JavaScript, HTTP Archive provides extensive information on the usage of the language for the entire web. This chapter consolidates and analyzes many of these trends. +

How much JavaScript do we use?

-

JavaScript is the most costly resource we send to browsers; having to be downloaded, parsed, compiled, and finally executed. Although browsers have significantly decreased the time it takes to parse and compile scripts, download and execution have become the most expensive stages when JavaScript is processed by a web page.

+

+ JavaScript is the most costly resource we send to browsers; having to be downloaded, parsed, compiled, and finally executed. Although browsers have significantly decreased the time it takes to parse and compile scripts, download and execution have become the most expensive stageshttps://v8.dev/blog/cost-of-javascript-2019 when JavaScript is processed by a web page. +

Sending smaller JavaScript bundles to the browser is the best way to reduce download times, and in turn improve page performance. But how much JavaScript do we really use?

- Figure 1. Distribution of JavaScript bytes per page. + Figure 1. Distribution of JavaScript bytes per page.
Figure 1. Distribution of JavaScript bytes per page.
@@ -43,7 +50,7 @@

- Figure 2. Distribution of JavaScript per page by device. + Figure 2. Distribution of JavaScript per page by device.
Figure 2. Distribution of JavaScript per page by device.
@@ -54,7 +61,7 @@

We can get an idea by analyzing main thread processing times for V8 at different percentiles:

- Figure 3. V8 Main thread processing times by device. + Figure 3. V8 Main thread processing times by device.
Figure 3. V8 Main thread processing times by device.
@@ -63,16 +70,19 @@

Although this data shows how much longer it can take for a mobile device to process JavaScript compared to a more powerful desktop machine, mobile devices also vary in terms of computing power. The following chart shows how processing times on a single web page can vary significantly depending on the mobile device class.

- JavaScript processing times for Reddit.com + JavaScript processing times for Reddit.com -
Figure 4. JavaScript processing times for reddit.com. From The cost of JavaScript in 2019.
+
+ Figure 4. JavaScript processing times for reddit.com. From The cost of JavaScript in 2019https://v8.dev/blog/cost-of-javascript-2019. +

Number of requests

One avenue worth exploring when trying to analyze the amount of JavaScript used by web pages is the number of requests shipped. With HTTP/2, sending multiple smaller chunks can improve page load over sending a larger, monolithic bundle. If we also break it down by device client, how many requests are being fetched?

- Figure 5. Distribution of total JavaScript requests. + Figure 5. Distribution of total JavaScript requests.
Figure 5. Distribution of total JavaScript requests.
@@ -83,14 +93,14 @@

- Figure 6. Distribution of first and third-party scripts on desktop. + Figure 6. Distribution of first and third-party scripts on desktop.
Figure 6. Distribution of first and third-party scripts on desktop.

- Figure 7. Distribution of first and third party scripts on mobile. + Figure 7. Distribution of first and third party scripts on mobile.
Figure 7. Distribution of first and third party scripts on mobile.
@@ -98,14 +108,14 @@

- Figure 8. Distribution of total JavaScript downloaded on desktop. + Figure 8. Distribution of total JavaScript downloaded on desktop.
Figure 8. Distribution of total JavaScript downloaded on desktop.

- Figure 9. Distribution of total JavaScript downloaded on mobile. + Figure 9. Distribution of total JavaScript downloaded on mobile.
Figure 9. Distribution of total JavaScript downloaded on mobile.
@@ -115,14 +125,18 @@

Gzip (gzip): The most widely used compression format for server and client interactions -
  • Brotli (br): A newer compression algorithm aiming to further improve compression ratios. 90% of browsers support Brotli encoding.
    • +
  • + Gziphttps://www.gzip.org/ (gzip): The most widely used compression format for server and client interactions +
    • +
  • + Brotlihttps://github.com/google/brotli (br): A newer compression algorithm aiming to further improve compression ratios. 90% of browsershttps://caniuse.com/#feat=brotli support Brotli encoding. +

    • Compressed scripts will always need to be uncompressed by the browser once transferred. This means its content remains the same and execution times are not optimized whatsoever. Resource compression, however, will always improve download times which also is one of the most expensive stages of JavaScript processing. Ensuring JavaScript files are compressed correctly can be one of the most significant factors in improving site performance.

    How many sites are compressing their JavaScript resources?

    - Figure 10. Percentage of sites compressing JavaScript resources with gzip or brotli. + Figure 10. Percentage of sites compressing JavaScript resources with gzip or brotli.
    Figure 10. Percentage of sites compressing JavaScript resources with gzip or brotli.
    @@ -130,7 +144,10 @@

    "Compression" chapter.

    Open source libraries and frameworks

    -

    Open source code, or code with a permissive license that can be accessed, viewed and modified by anyone. From tiny libraries to entire browsers, such as Chromium and Firefox, open source code plays a crucial role in the world of web development. In the context of JavaScript, developers rely on open source tooling to include all types of functionality into their web page. Regardless of whether a developer decides to use a small utility library or a massive framework that dictates the architecture of their entire application, relying on open-source packages can make feature development easier and faster. So which JavaScript open-source libraries are used the most?

    +

    + Open source code, or code with a permissive license that can be accessed, viewed and modified by anyone. From tiny libraries to entire browsers, such as Chromiumhttps://www.chromium.org/Home and Firefoxhttps://www.openhub.net/p/firefox, open source code plays a crucial role in the world of web development. In the context of JavaScript, developers rely on open source tooling to include all types of functionality into their web page. Regardless of whether a developer decides to use a small utility library or a massive framework that dictates the architecture of their entire application, relying on open-source packages can make feature development easier and faster. So which JavaScript open-source libraries are used the most? +

    @@ -254,55 +271,88 @@

    Figure 11. Top JavaScript libraries on desktop and mobile.

    -

    jQuery, the most popular JavaScript library ever created, is used in 85.03% of desktop pages and 83.46% of mobile pages. The advent of many Browser APIs and methods, such as Fetch and querySelector, standardized much of the functionality provided by the library into a native form. Although the popularity of jQuery may seem to be declining, why is it still used in the vast majority of the web?

    +

    + jQueryhttps://jquery.com/, the most popular JavaScript library ever created, is used in 85.03% of desktop pages and 83.46% of mobile pages. The advent of many Browser APIs and methods, such as Fetchhttps://developer.mozilla.org/en-US/docs/Web/API/Fetch_API and querySelectorhttps://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector, standardized much of the functionality provided by the library into a native form. Although the popularity of jQuery may seem to be declining, why is it still used in the vast majority of the web? +

    There are a number of possible reasons:

      -
    • WordPress, which is used in more than 30% of sites, includes jQuery by default.
      • +
    • + WordPresshttps://wordpress.org/, which is used in more than 30% of sites, includes jQuery by default. +
    • Switching from jQuery to a newer client-side library can take time depending on how large an application is, and many sites may consist of jQuery in addition to newer client-side libraries.
    -

    Other top used JavaScript libraries include jQuery variants (jQuery migrate, jQuery UI), Modernizr, Moment.js, Underscore.js and so on.

    +

    + Other top used JavaScript libraries include jQuery variants (jQuery migrate, jQuery UI), Modernizrhttps://modernizr.com/, Moment.jshttps://momentjs.com/, Underscore.jshttps://underscorejs.org/ and so on. +

    Frameworks and UI libraries

    -

    As mentioned in our methodology, the third-party detection library used in HTTP Archive (Wappalyzer) has a number of limitations with regards to how it detects certain tools. There is an open issue to improve detection of JavaScript libraries and frameworks, which will have impacted the results presented here.

    +

    + As mentioned in our methodology, the third-party detection library used in HTTP Archive (Wappalyzer) has a number of limitations with regards to how it detects certain tools. There is an open issue to improve detection of JavaScript libraries and frameworkshttps://github.com/AliasIO/wappalyzer/issues/2450, which will have impacted the results presented here. +

    In the past number of years, the JavaScript ecosystem has seen a rise in open-source libraries and frameworks to make building single-page applications (SPAs) easier. A single-page application is characterized as a web page that loads a single HTML page and uses JavaScript to modify the page on user interaction instead of fetching new pages from the server. Although this remains to be the main premise of single-page applications, different server-rendering approaches can still be used to improve the experience of such sites. How many sites use these types of frameworks?

    - Figure 12. Most frequently used frameworks on desktop. + Figure 12. Most frequently used frameworks on desktop.
    Figure 12. Most frequently used frameworks on desktop.

    Only a subset of popular frameworks are being analyzed here, but it's important to note that all of them either follow one of these two approaches:

    -

    Although there has been a shift towards a component-based model, many older frameworks that follow the MVC paradigm (AngularJS, Backbone.js, Ember) are still being used in thousands of pages. However, React, Vue and Angular are the most popular component-based frameworks (Zone.js is a package that is now part of Angular core).

    +

    + Although there has been a shift towards a component-based model, many older frameworks that follow the MVC paradigm (AngularJShttps://angularjs.org/, Backbone.jshttps://backbonejs.org/, Emberhttps://emberjs.com/) are still being used in thousands of pages. However, Reacthttps://reactjs.org/, Vuehttps://vuejs.org/ and Angularhttps://angular.io/ are the most popular component-based frameworks (Zone.jshttps://github.com/angular/zone.js is a package that is now part of Angular core). +

    Differential loading

    -

    JavaScript modules, or ES modules, are supported in all major browsers. Modules provide the capability to create scripts that can import and export from other modules. This allows anyone to build their applications architected in a module pattern, importing and exporting wherever necessary, without relying on third-party module loaders.

    +

    + JavaScript moduleshttps://v8.dev/features/modules, or ES modules, are supported in all major browsershttps://caniuse.com/#feat=es6-module. Modules provide the capability to create scripts that can import and export from other modules. This allows anyone to build their applications architected in a module pattern, importing and exporting wherever necessary, without relying on third-party module loaders. +

    To declare a script as a module, the script tag must get the type="module" attribute:

    <script type="module" src="main.mjs"></script>

    How many sites use type="module" for scripts on their page?

    - Figure 13. Percentage of sites utilizing type=module. + Figure 13. Percentage of sites utilizing type=module.
    Figure 13. Percentage of sites utilizing type=module.
    -

    Browser-level support for modules is still relatively new, and the numbers here show that very few sites currently use type="module" for their scripts. Many sites are still relying on module loaders (2.37% of all desktop sites use RequireJS for example) and bundlers (webpack for example) to define modules within their codebase.

    +

    + Browser-level support for modules is still relatively new, and the numbers here show that very few sites currently use type="module" for their scripts. Many sites are still relying on module loaders (2.37% of all desktop sites use RequireJShttps://github.com/requirejs/requirejs for example) and bundlers (webpackhttps://webpack.js.org/ for example) to define modules within their codebase. +

    If native modules are used, it's important to ensure that an appropriate fallback script is used for browsers that do not yet support modules. This can be done by including an additional script with a nomodule attribute.

    <script nomodule src="fallback.js"></script>
    -

    When used together, browsers that support modules will completely ignore any scripts containing the nomodule attribute. On the other hand, browsers that do not yet support modules will not download any scripts with type="module". Since they do not recognize nomodule either, they will download scripts with the attribute normally. Using this approach can allow developers to send modern code to modern browsers for faster page loads. So, how many sites use nomodule for scripts on their page?

    +

    + When used together, browsers that support modules will completely ignore any scripts containing the nomodule attribute. On the other hand, browsers that do not yet support modules will not download any scripts with type="module". Since they do not recognize nomodule either, they will download scripts with the attribute normally. Using this approach can allow developers to send modern code to modern browsers for faster page loadshttps://web.dev/serve-modern-code-to-modern-browsers/. So, how many sites use nomodule for scripts on their page? +

    - Figure 14. Percentage of sites using nomodule. + Figure 14. Percentage of sites using nomodule.
    Figure 14. Percentage of sites using nomodule.

    Similarly, very few sites (0.50%-0.80%) use the nomodule attribute for any scripts.

    Preload and prefetch

    -

    Preload and prefetch are resource hints which enable you to aid the browser in determining what resources need to be downloaded.

    +

    + Preloadhttps://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content and prefetchhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ are resource hints which enable you to aid the browser in determining what resources need to be downloaded. +

    - Figure 17. Usage of new JavaScript APIs. + Figure 17. Usage of new JavaScript APIs.
    Figure 17. Usage of new JavaScript APIs.

    Atomics (0.38%) and SharedArrayBuffer (0.20%) are barely visible on this chart since they are used on such few pages.

    -

    It is important to note that the numbers here are approximations and they do not leverage UseCounter to measure feature usage.

    +

    + It is important to note that the numbers here are approximations and they do not leverage UseCounterhttps://chromium.googlesource.com/chromium/src.git/+/master/docs/use_counter_wiki.md to measure feature usage. +

    Source maps

    -

    In many build systems, JavaScript files undergo minification to minimize its size and transpilation for newer language features that are not yet supported in many browsers. Moreover, language supersets like TypeScript compile to an output that can look noticeably different from the original source code. For all these reasons, the final code served to the browser can be unreadable and hard to decipher.

    +

    + In many build systems, JavaScript files undergo minification to minimize its size and transpilation for newer language features that are not yet supported in many browsers. Moreover, language supersets like TypeScripthttps://www.typescriptlang.org/ compile to an output that can look noticeably different from the original source code. For all these reasons, the final code served to the browser can be unreadable and hard to decipher. +

    A source map is an additional file accompanying a JavaScript file that allows a browser to map the final output to its original source. This can make debugging and analyzing production bundles much simpler.

    Although useful, there are a number of reasons why many sites may not want to include source maps in their final production site, such as choosing not to expose complete source code to the public. So how many sites actually include sourcemaps?

    - Figure 18. Percentage of sites using source maps. + Figure 18. Percentage of sites using source maps.
    Figure 18. Percentage of sites using source maps.
    @@ -361,54 +427,73 @@

    Conclusion

    The JavaScript ecosystem continues to change and evolve every year. Newer APIs, improved browser engines, and fresh libraries and frameworks are all things we can expect to happen indefinitely. HTTP Archive provides us with valuable insight on how sites in the wild use the language.

    Without JavaScript, the web would not be where it is today, and all the data gathered for this article only proves this.

    -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":2,"title":"CSS","description":"CSS chapter of the 2019 Web Almanac covering color, units, selectors, layout, typography and fonts, spacing, decoration, animation, and media queries.","authors":["una","argyleink"],"reviewers":["meyerweb","huijing"],"translators":null,"discuss":"1757","results":"https://docs.google.com/spreadsheets/d/1uFlkuSRetjBNEhGKWpkrXo4eEIsgYelxY-qR9Pd7QpM/","queries":"02_CSS","published":"2019-11-11","last_updated":"2020-05-14","chapter":"css"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 2 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - CSS +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":2,"title":"CSS","description":"CSS chapter of the 2019 Web Almanac covering color, units, selectors, layout, typography and fonts, spacing, decoration, animation, and media queries.","authors":["una","argyleink"],"reviewers":["meyerweb","huijing"],"translators":null,"discuss":"1757","results":"https://docs.google.com/spreadsheets/d/1uFlkuSRetjBNEhGKWpkrXo4eEIsgYelxY-qR9Pd7QpM/","queries":"02_CSS","published":"2019-11-11","last_updated":"2020-05-14","chapter":"css"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -417,12 +502,16 @@

    - + -
    {{ self.written_by_before() }} Una Kravets, {{ self.and() }} Adam Argyle{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Eric A. Meyer, {{ self.and() }} Chen Hui Jing{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Cascading Style Sheets (CSS) are used to paint, format, and layout web pages. Their capabilities span concepts as simple as text color to 3D perspective. It also has hooks to empower developers to handle varying screen sizes, viewing contexts, and printing. CSS helps developers wrangle content and ensure it's adapting properly to the user.

    When describing CSS to those not familiar with web technology, it can be helpful to think of it as the language to paint the walls of the house; describing the size and position of windows and doors, as well as flourishing decorations such as wallpaper or plant life. The fun twist to that story is that depending on the user walking through the house, a developer can adapt the house to that specific user's preferences or contexts!

    @@ -431,29 +520,37 @@

    Introd

    Color

    Color is an integral part of theming and styling on the web. Let's take a look at how websites tend to use color.

    Color types

    -

    Hex is the most popular way to describe color by far, with 93% usage, followed by RGB, and then HSL. Interestingly, developers are taking full advantage of the alpha-transparency argument when it comes to these color types: HSLA and RGBA are far more popular than HSL and RGB, with almost double the usage! Even though the alpha-transparency was added later to the web spec, HSLA and RGBA are supported as far back as IE9, so you can go ahead and use them, too!

    +

    + Hex is the most popular way to describe color by far, with 93% usage, followed by RGB, and then HSL. Interestingly, developers are taking full advantage of the alpha-transparency argument when it comes to these color types: HSLA and RGBA are far more popular than HSL and RGB, with almost double the usage! Even though the alpha-transparency was added later to the web spec, HSLA and RGBA are supported as far back as IE9https://caniuse.com/#feat=css3-colors, so you can go ahead and use them, too! +

    - Figure 1. Popularity of color formats. + Figure 1. Popularity of color formats.
    Figure 1. Popularity of color formats.

    Color selection

    -

    There are 148 named CSS colors, not including the special values transparent and currentcolor. You can use these by their string name for more readable styling. The most popular named colors are black and white, unsurprisingly, followed by red and blue.

    +

    + There are 148 named CSS colorshttps://www.w3.org/TR/css-color-4/#named-colors, not including the special values transparent and currentcolor. You can use these by their string name for more readable styling. The most popular named colors are black and white, unsurprisingly, followed by red and blue. +

    - Figure 2. Top named colors. + Figure 2. Top named colors.
    Figure 2. Top named colors.
    -

    Language is interestingly inferred via color as well. There are more instances of the American-style "gray" than the British-style "grey". Almost every instance of gray colors (gray, lightgray, darkgray, slategray, etc.) had nearly double the usage when spelled with an "a" instead of an "e". If gr[a/e]ys were combined, they would rank higher than blue, solidifying themselves in the #4 spot. This could be why silver is ranked higher than grey with an "e" in the charts!

    +

    + Language is interestingly inferred via color as well. There are more instances of the American-style "gray" than the British-style "grey". Almost every instance of gray colorshttps://www.rapidtables.com/web/color/gray-color.html (gray, lightgray, darkgray, slategray, etc.) had nearly double the usage when spelled with an "a" instead of an "e". If gr[a/e]ys were combined, they would rank higher than blue, solidifying themselves in the #4 spot. This could be why silver is ranked higher than grey with an "e" in the charts! +

    Color count

    How many different font colors are used across the web? So this isn't the total number of unique colors; rather, it's how many different colors are used just for text. The numbers in this chart are quite high, and from experience, we know that without CSS variables, spacing, sizes and colors can quickly get away from you and fragment into lots of tiny values across your styles. These numbers reflect a difficulty of style management, and we hope this helps create some perspective for you to bring back to your teams or projects. How can you reduce this number into a manageable and reasonable amount?

    - igure 3. Distribution of colors per page. + igure 3. Distribution of colors per page.
    Figure 3. Distribution of colors per page.
    @@ -462,7 +559,7 @@

    - Figure 4. Distribution of duplicate colors per page. + Figure 4. Distribution of duplicate colors per page.
    Figure 4. Distribution of duplicate colors per page.
    @@ -471,7 +568,7 @@

    Units

    In CSS, there are many different ways to achieve the same visual result using different unit types: rem, px, em, ch, or even cm! So which unit types are most popular?

    - Figure 5. Popularity of unit types. + Figure 5. Popularity of unit types.
    Figure 5. Popularity of unit types.
    @@ -479,7 +576,9 @@

    Units

    Length and sizing

    Unsurprisingly, In Figure 5 above, px is the most used unit type, with about 95% of web pages using pixels in some form or another (this could be element sizing, font size, and so on). However, the em unit is almost as popular, with about 90% usage. This is over 2x more popular than the rem unit, which has only 40% frequency in web pages. If you're wondering what the difference is, em is based on the parent font size, while rem is based on the base font size set to the page. It doesn't change per-component like em could, and thus allows for adjustment of all spacing evenly.

    When it comes to units based on physical space, the cm (or centimeter) unit is the most popular by far, followed by in (inches), and then Q. We know these types of units are specifically useful for print stylesheets, but we didn't even know the Q unit existed until this survey! Did you?

    -

    An earlier version of this chapter discussed the unexpected popularity of the Q unit. Thanks to the community discussion surrounding this chapter, we've identified that this was a bug in our analysis and have updated Figure 5 accordingly.

    +

    + An earlier version of this chapter discussed the unexpected popularity of the Q unit. Thanks to the community discussionhttps://discuss.httparchive.org/t/chapter-2-css/1757/6 surrounding this chapter, we've identified that this was a bug in our analysis and have updated Figure 5 accordingly. +

    Viewport-based units

    We saw larger differences in unit types when it comes to mobile and desktop usage for viewport-based units. 36.8% of mobile sites use vh (viewport height), while only 31% of desktop sites do. We also found that vh is more common than vw (viewport width) by about 11%. vmin (viewport minimum) is more popular than vmax (viewport maximum), with about 8% usage of vmin on mobile while vmax is only used by 1% of websites.

    Custom properties

    @@ -494,7 +593,7 @@

    - Figure 7. Popularity of selector types per page. + Figure 7. Popularity of selector types per page.
    Figure 7. Popularity of selector types per page.
    @@ -502,7 +601,7 @@

    - Figure 8. Popularity of selector types per selector. + Figure 8. Popularity of selector types per selector.
    Figure 8. Popularity of selector types per selector.
    @@ -511,14 +610,14 @@

    - Figure 9. Popularity of operators per ID attribute selector. + Figure 9. Popularity of operators per ID attribute selector.
    Figure 9. Popularity of operators per ID attribute selector.
    - Figure 10. Popularity of operators per class attribute selector. + Figure 10. Popularity of operators per class attribute selector.
    Figure 10. Popularity of operators per class attribute selector.
    @@ -532,17 +631,21 @@

    Layout

    Flexbox

    -

    Flexbox is a container style that directs and aligns its children; that is, it helps with layout in a constraint-based way. It had a quite rocky beginning on the web, as its specification went through two or three quite drastic changes between 2010 and 2013. Fortunately, it settled and was implemented across all browsers by 2014. Given that history, it had a slow adoption rate, but it's been a few years since then! It's quite popular now and has many articles about it and how to leverage it, but it's still new in comparison to other layout tactics.

    +

    + Flexboxhttps://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexbox is a container style that directs and aligns its children; that is, it helps with layout in a constraint-based way. It had a quite rocky beginning on the web, as its specification went through two or three quite drastic changes between 2010 and 2013. Fortunately, it settled and was implemented across all browsers by 2014. Given that history, it had a slow adoption rate, but it's been a few years since then! It's quite popular now and has many articles about it and how to leverage it, but it's still new in comparison to other layout tactics. +

    - Figure 12. Adoption of flexbox. + Figure 12. Adoption of flexbox.
    Figure 12. Adoption of flexbox.

    Quite the success story shown here, as nearly 50% of the web has flexbox usage in its stylesheets.

    Grid

    -

    Like flexbox, grid too went through a few spec alternations early on in its lifespan, but without changing implementations in publicly-deployed browsers. Microsoft had grid in the first versions of Windows 8, as the primary layout engine for its horizontally scrolling design style. It was vetted there first, transitioned to the web, and then hardened by the other browsers until its final release in 2017. It had a very successful launch in that nearly all browsers released their implementations at the same time, so web developers just woke up one day to superb grid support. Today, at the end of 2019, grid still feels like a new kid on the block, as folks are still awakening to its power and capabilities.

    +

    + Like flexbox, gridhttps://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout too went through a few spec alternations early on in its lifespan, but without changing implementations in publicly-deployed browsers. Microsoft had grid in the first versions of Windows 8, as the primary layout engine for its horizontally scrolling design style. It was vetted there first, transitioned to the web, and then hardened by the other browsers until its final release in 2017. It had a very successful launch in that nearly all browsers released their implementations at the same time, so web developers just woke up one day to superb grid support. Today, at the end of 2019, grid still feels like a new kid on the block, as folks are still awakening to its power and capabilities. +

    2%
    Figure 13. Percent of websites using grid.
    @@ -552,7 +655,7 @@

    Writ

    The web and CSS are international platform features, and writing modes offer a way for HTML and CSS to indicate a user's preferred reading and writing direction within our elements.

    - Figure 14. Popularity of direction values. + Figure 14. Popularity of direction values.
    Figure 14. Popularity of direction values.
    @@ -562,7 +665,7 @@

    - Figure 15. Distribution of the number of web fonts loaded per page. + Figure 15. Distribution of the number of web fonts loaded per page.
    Figure 15. Distribution of the number of web fonts loaded per page.
    @@ -571,7 +674,7 @@

    Font sizes

    This is a fun one, because if you asked a user how many font sizes they feel are on a page, they'd generally return a number of 5 or definitely less than 10. Is that reality though? Even in a design system, how many font sizes are there? We queried the web and found the median to be 40 on mobile and 38 on desktop. Might be time to really think hard about custom properties or creating some reusable classes to help you distribute your type ramp.

    - Figure 17. Distribution of the number of distinct font sizes per page. + Figure 17. Distribution of the number of distinct font sizes per page.
    Figure 17. Distribution of the number of distinct font sizes per page.
    @@ -592,7 +695,7 @@

    Margins

    A margin is the space outside of elements, like the space you demand when you push your arms out from yourself. This often looks like the spacing between elements, but is not limited to that effect. In a website or app, spacing plays a huge role in UX and design. Let's see how much margin spacing code goes into a stylesheet, shall we?

    - Figure 18. Distribution of the number of distinct margin values per page. + Figure 18. Distribution of the number of distinct margin values per page.
    Figure 18. Distribution of the number of distinct margin values per page.
    @@ -608,7 +711,7 @@

    z-index

    Vertical layering, or stacking, can be managed with z-index in CSS. We were curious how many different values folks use in their sites. The range of what z-index accepts is theoretically infinite, bounded only by a browser's variable size limitations. Are all those stack positions used? Let's see!

    - Figure 20. Distribution of the number of distinct 'z-index' values per page. + Figure 20. Distribution of the number of distinct 'z-index' values per page.
    Figure 20. Distribution of the number of distinct z-index values per page.
    @@ -617,7 +720,7 @@

    Blend modes

    Blend modes are similar to filters in that they are a post-processing effect that are run against a flat version of their target elements, but are unique in that they are concerned with pixel convergence. Said another way, blend modes are how 2 pixels should impact each other when they overlap. Whichever element is on the top or the bottom will affect the way that the blend mode manipulates the pixels. There are 16 blend modes -- let's see which ones are the most popular.

    @@ -648,7 +754,7 @@

    Transiti

    CSS has this awesome interpolation power that can be simply used by just writing a single rule on how to transition those values. If you're using CSS to manage states in your app, how often are you employing transitions to do the task? Let's query the web!

    - Figure 25. Distribution of the number of transitions per page. + Figure 25. Distribution of the number of transitions per page.
    Figure 25. Distribution of the number of transitions per page.
    @@ -658,7 +764,7 @@

    - Figure 26. Distribution of the number of keyframes per page. + Figure 26. Distribution of the number of keyframes per page.
    Figure 26. Distribution of the number of keyframes per page.
    @@ -668,7 +774,7 @@

    Medi

    A good place to start with Media Queries, is just about how many are used per page? How many different moments or contexts does the typical page feel they want to respond to?

    - Figure 27. Distribution of the number of media queries per page. + Figure 27. Distribution of the number of media queries per page.
    Figure 27. Distribution of the number of media queries per page.
    @@ -677,7 +783,7 @@

    - Figure 29. Adoption of media query orientation modes. + Figure 29. Adoption of media query orientation modes.
    Figure 29. Adoption of media query orientation modes.
    @@ -697,7 +803,7 @@

    +

    + We felt the biggest takeaway from these results is that custom properties offer the most bang for your buck in terms of performance, DRYness, and scalability of your stylesheets. We look forward to scrubbing the internet's stylesheets again, hunting for new datums and provocative chart treats. Reach out to @unahttps://twitter.com/una or @argyleinkhttps://twitter.com/argyleink in the comments with your queries, questions, and assertions. We'd love to hear them! +

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":3,"title":"Markup","description":"Markup chapter of the 2019 Web Almanac covering elements used, custom elements, value, products, and common use cases.","authors":["bkardell"],"reviewers":["zcorpan","tomhodgins","matthewp"],"translators":null,"discuss":"1758","results":"https://docs.google.com/spreadsheets/d/1WnDKLar_0Btlt9UgT53Giy2229bpV4IM2D_v6OM_WzA/","queries":"03_Markup","published":"2019-11-11","last_updated":"2020-03-01","chapter":"markup"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 3 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Markup +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":3,"title":"Markup","description":"Markup chapter of the 2019 Web Almanac covering elements used, custom elements, value, products, and common use cases.","authors":["bkardell"],"reviewers":["zcorpan","tomhodgins","matthewp"],"translators":null,"discuss":"1758","results":"https://docs.google.com/spreadsheets/d/1WnDKLar_0Btlt9UgT53Giy2229bpV4IM2D_v6OM_WzA/","queries":"03_Markup","published":"2019-11-11","last_updated":"2020-03-01","chapter":"markup"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -1061,22 +1161,34 @@

    - + -
    {{ self.written_by_before() }} Brian Kardell{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Simon Pieters, Tommy Hodgins, {{ self.and() }} Matthew Phillips{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    -

    In 2005, Ian "Hixie" Hickson posted some analysis of markup data building upon various previous work. Much of this work aimed to investigate class names to see if there were common informal semantics that were being adopted by developers which it might make sense to standardize upon. Some of this research helped inform new elements in HTML5.

    -

    14 years later, it's time to take a fresh look. Since then, we've also had the introduction of Custom Elements and the Extensible Web Manifesto encouraging that we find better ways to pave the cowpaths by allowing developers to explore the space of elements themselves and allow standards bodies to act more like dictionary editors. Unlike CSS class names, which might be used for anything, we can be far more certain that authors who used a non-standard element really intended this to be an element.

    +

    + In 2005, Ian "Hixie" Hickson posted some analysis of markup datahttps://web.archive.org/web/20060203035414/http://code.google.com/webstats/index.html building upon various previous work. Much of this work aimed to investigate class names to see if there were common informal semantics that were being adopted by developers which it might make sense to standardize upon. Some of this research helped inform new elements in HTML5. +

    +

    + 14 years later, it's time to take a fresh look. Since then, we've also had the introduction of Custom Elementshttps://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements and the Extensible Web Manifestohttps://extensiblewebmanifesto.org/ encouraging that we find better ways to pave the cowpaths by allowing developers to explore the space of elements themselves and allow standards bodies to act more like dictionary editorshttps://bkardell.com/blog/Dropping-The-F-Bomb-On-Standards.html. Unlike CSS class names, which might be used for anything, we can be far more certain that authors who used a non-standard element really intended this to be an element. +

    As of July 2019, the HTTP Archive has begun collecting all used element names in the DOM for about 4.4 million desktop home pages, and about 5.3 million mobile home pages which we can now begin to research and dissect. (Learn more about our Methodology.)

    This crawl encountered over 5,000 distinct non-standard element names in these pages, so we capped the total distinct number of elements that we count to the 'top' (explained below) 5,048.

    Methodology

    Names of elements on each page were collected from the DOM itself, after the initial run of JavaScript.

    -

    Looking at a raw frequency count isn't especially helpful, even for standard elements: About 25% of all elements encountered are <div>. About 17% are <a>, about 11% are <span> -- and those are the only elements that account for more than 10% of occurrences. Languages are generally like this; a small number of terms are astoundingly used by comparison. Further, when we start looking at non-standard elements for uptake, this would be very misleading as one site could use a certain element a thousand times and thus make it look artificially very popular.

    +

    + Looking at a raw frequency count isn't especially helpful, even for standard elements: About 25% of all elements encountered are <div>. About 17% are <a>, about 11% are <span> -- and those are the only elements that account for more than 10% of occurrences. Languages are generally like thishttps://www.youtube.com/watch?v=fCn8zs912OE; a small number of terms are astoundingly used by comparison. Further, when we start looking at non-standard elements for uptake, this would be very misleading as one site could use a certain element a thousand times and thus make it look artificially very popular. +

    Instead, as in Hixie's original study, what we will look at is how many sites include each element at least once in their homepage.

    Note: This is, itself, not without some potential biases. Popular products can be used by several sites, which introduce non-standard markup, even "invisibly" to individual authors. Thus, care must be taken to acknowledge that usage doesn't necessarily imply direct author knowledge and conscious adoption as much as it does the servicing of a common need, in a common way. During our research, we found several examples of this, some we will call out.

    Top elements and general info

    @@ -1141,26 +1253,26 @@

    Elements per page

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

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

    - Histogram of Hixie's 2005 analysis of element types per page + Histogram of Hixie's 2005 analysis of element types per page
    Figure 4. Histogram of Hixie's 2005 analysis of element types per page.
    - Figure 5. Histogram of element types per page as of 2019. + Figure 5. Histogram of element types per page as of 2019.
    Figure 5. Histogram of element types per page as of 2019.
    @@ -1191,7 +1303,7 @@

    Note: A lot of this is very likely due to the use of products rather than individual authors continuing to manually create this markup.

    - Figure 6. Most frequently used deprecated elements. + Figure 6. Most frequently used deprecated elements.
    Figure 6. Most frequently used deprecated elements.
    @@ -1201,7 +1313,7 @@

    - Figure 7. Top 150 elements. + Figure 7. Top 150 elements.
    Figure 7. Top 150 elements (full detail).
    @@ -1244,64 +1356,73 @@

    - Figure 8. Element popularity categorized by standardization + Figure 8. Element popularity categorized by standardization
    Figure 8. Element popularity categorized by standardization.

    Figure 8 shows the rank of each element and which category they fall into. I've separated the data points into discrete sets simply so that they can be viewed (otherwise there just aren't enough pixels to capture all that data), but they represent a single 'line' of popularity; the bottom-most being the most common, the top-most being the least common. The arrow points to the end of elements that appear in more than 1% of the pages.

    You can observe two things here. First, the set of elements that have more than 1% use are not exclusively HTML. In fact, 27 of the most popular 100 elements aren't even HTML - they are SVG! And there are non-standard tags at or very near that cutoff too! Second, note that a whole lot of HTML elements are used by less than 1% of pages.

    -

    So, are all of those elements used by less than 1% of pages "useless"? Definitely not. This is why establishing perspective matters. There are around two billion web sites on the web. If something appears on 0.1% of all websites in our dataset, we can extrapolate that this represents perhaps two million web sites in the whole web. Even 0.01% extrapolates to two hundred thousand sites. This is also why removing support for elements, even very old ones which we think aren't great ideas, is a very rare occurrence. Breaking hundreds of thousands or millions of sites just isn't a thing that browser vendors can do lightly.

    +

    + So, are all of those elements used by less than 1% of pages "useless"? Definitely not. This is why establishing perspective matters. There are around two billion web sites on the webhttps://www.websitehostingrating.com/internet-statistics-facts/. If something appears on 0.1% of all websites in our dataset, we can extrapolate that this represents perhaps two million web sites in the whole web. Even 0.01% extrapolates to two hundred thousand sites. This is also why removing support for elements, even very old ones which we think aren't great ideas, is a very rare occurrence. Breaking hundreds of thousands or millions of sites just isn't a thing that browser vendors can do lightly. +

    Many elements, even the native ones, appear on fewer than 1% of pages and are still very important and successful. <code>, for example, is an element that I both use and encounter a lot. It's definitely useful and important, and yet it is used on only 0.57% of these pages. Part of this is skewed based on what we are measuring; home pages are generally less likely to include certain kinds of things (like <code> for example). Home pages serve a less general purpose than, for example, headings, paragraphs, links and lists. However, the data is generally useful.

    We also collected information about which pages contained an author-defined (not native) .shadowRoot. About 0.22% of desktop pages and 0.15% of mobile pages had a shadow root. This might not sound like a lot, but it is roughly 6.5k sites in the mobile dataset and 10k sites on the desktop and is more than several HTML elements. <summary> for example, has about equivalent use on the desktop and it is the 146th most popular element. <datalist> appears on 0.04% of homepages and it's the 201st most popular element.

    In fact, over 15% of elements we're counting as defined by HTML are outside the top 200 in the desktop dataset . <meter> is the least popular "HTML5 era" element, which we can define as 2004-2011, before HTML moved to a Living Standard model. It is around the 1,000th most popular element. <slot>, the most recently introduced element (April 2016), is only around the 1,400th most popular element.

    Lots of data: real DOM on the real web

    With this perspective in mind about what use of native/standard features looks like in the dataset, let's talk about the non-standard stuff.

    You might expect that many of the elements we measured are used only on a single web page, but in fact all of the 5,048 elements appear on more than one page. The fewest pages an element in our dataset appears on is 15. About a fifth of them occur on more than 100 pages. About 7% occur on more than 1,000 pages.

    -

    To help analyze the data, I hacked together a little tool with Glitch. You can use this tool yourself, and please share a permalink back with the @HTTPArchive along with your observations. (Tommy Hodgins has also built a similar CLI tool which you can use to explore.)

    +

    + To help analyze the data, I hacked together a little tool with Glitchhttps://rainy-periwinkle.glitch.me. You can use this tool yourself, and please share a permalink back with the @HTTPArchivehttps://twitter.com/HTTPArchive along with your observations. (Tommy Hodgins has also built a similar CLI toolhttps://github.com/tomhodgins/hade which you can use to explore.) +

    Let's look at some data.

    Products (and libraries) and their custom markup

    -

    For several non-standard elements, their prevalence may have more to do with their inclusion in popular third-party tools than first-party adoption. For example, the <fb:like> element is found on 0.3% of pages not because site owners are explicitly writing it out but because they include the Facebook widget. Many of the elements Hixie mentioned 14 years ago seem to have dwindled, but others are still pretty huge:

    +

    + For several non-standard elements, their prevalence may have more to do with their inclusion in popular third-party tools than first-party adoption. For example, the <fb:like> element is found on 0.3% of pages not because site owners are explicitly writing it out but because they include the Facebook widget. Many of the elements Hixie mentioned 14 years agohttps://web.archive.org/web/20060203031245/http://code.google.com/webstats/2005-12/editors.html seem to have dwindled, but others are still pretty huge: +

    But there are plenty of newcomers that weren't in Hixie's original report too, and with even bigger numbers.

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

    - Figure 9. Popularity of product-specific and native elements under 5% adoption. + Figure 9. Popularity of product-specific and native elements under 5% adoption.
    Figure 9. Popularity of product-specific and native elements under 5% adoption.
    @@ -1311,35 +1432,51 @@

    a list of 1157 elements like that from the mobile dataset. Many of those, as you can see, are likely to be non-problematic as they have obscure names, misspellings and so on. But at least a few probably present some challenges. You'll note, for example, that <toast> (which Googlers recently tried to propose as <std-toast>a list of 1157 elements like that from the mobile datasethttps://rainy-periwinkle.glitch.me/permalink/53567ec94b328de965eb821010b8b5935b0e0ba316e833267dc04f1fb3b53bd5.html. Many of those, as you can see, are likely to be non-problematic as they have obscure names, misspellings and so on. But at least a few probably present some challenges. You'll note, for example, that <toast> (which Googlers recently tried to propose as <std-toast>https://www.chromestatus.com/feature/5674896879255552) appears in this list.

    There are some popular elements that are probably not so challenging:

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

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

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

    Common use cases and solutions

    -

    What if, for example, we were interested in people solving common use cases? This could be because we're looking for solutions to use cases that we currently have ourselves, or for researching more broadly what common use cases people are solving with an eye toward incubating some standardization effort. Let's take a common example: tabs. Over the years there have been a lot of requests for things like tabs. We can use a fuzzy search here and find that there are many variants of tabs. It's a little harder to count usage here since we can't as easily distinguish if two elements appear on the same page, so the count provided there conservatively simply takes the one with the largest count. In most cases the real number of pages is probably significantly larger.

    -

    There are also lots of accordions, dialogs, at least 65 variants of carousels, lots of stuff about popups, at least 27 variants of toggles and switches, and so on.

    -

    Perhaps we could research why we need 92 variants of button related elements that aren't a native button, for example, and try to fill the native gap.

    -

    If we notice popular things pop up (like <jdiv>, solving chat) we can take knowledge of things we know (like, that is what <jdiv> is about, or <olark>) and try to look at at least 43 things we've built for tackling that and follow connections to survey the space.

    +

    + What if, for example, we were interested in people solving common use cases? This could be because we're looking for solutions to use cases that we currently have ourselves, or for researching more broadly what common use cases people are solving with an eye toward incubating some standardization effort. Let's take a common example: tabs. Over the years there have been a lot of requests for things like tabs. We can use a fuzzy search here and find that there are many variants of tabshttps://rainy-periwinkle.glitch.me/permalink/c6d39f24d61d811b55fc032806cade9f0be437dcb2f5735a4291adb04aa7a0ea.html. It's a little harder to count usage here since we can't as easily distinguish if two elements appear on the same page, so the count provided there conservatively simply takes the one with the largest count. In most cases the real number of pages is probably significantly larger. +

    +

    + There are also lots of accordionshttps://rainy-periwinkle.glitch.me/permalink/e573cf279bf1d2f0f98a90f0d7e507ac8dbd3e570336b20c6befc9370146220b.html, dialogshttps://rainy-periwinkle.glitch.me/permalink/0bb74b808e7850a441fc9b93b61abf053efc28f05e0a1bc2382937e3b78695d9.html, at least 65 variants of carouselshttps://rainy-periwinkle.glitch.me/permalink/651e592cb2957c14cdb43d6610b6acf696272b2fbd0d58a74c283e5ad4c79a12.html, lots of stuff about popupshttps://rainy-periwinkle.glitch.me/permalink/981967b19a9346ac466482c51b35c49fc1c1cc66177ede440ab3ee51a7912187.html, at least 27 variants of toggles and switcheshttps://rainy-periwinkle.glitch.me/permalink/2e6827af7c9d2530cb3d2f39a3f904091c523c2ead14daccd4a41428f34da5e8.html, and so on. +

    +

    + Perhaps we could research why we need 92 variants of button related elements that aren't a native buttonhttps://rainy-periwinkle.glitch.me/permalink/5ae67c941395ca3125e42909c2c3881e27cb49cfa9aaf1cf59471e3779435339.html, for example, and try to fill the native gap. +

    +

    + If we notice popular things pop up (like <jdiv>, solving chat) we can take knowledge of things we know (like, that is what <jdiv> is about, or <olark>) and try to look at at least 43 things we've built for tackling thathttps://rainy-periwinkle.glitch.me/permalink/db8fc0e58d2d46d2e2a251ed13e3daab39eba864e46d14d69cc114ab5d684b00.html and follow connections to survey the space. +

    Conclusion

    So, there's lots of data here, but to summarize:

    -

    That last one is where you come in. We'd love to tap into the creativity and curiosity of the larger community to help explore this data using some of the tools (like https://rainy-periwinkle.glitch.me/). Please share your interesting observations and help build our commons of knowledge and understanding.

    -
    +

    + That last one is where you come in. We'd love to tap into the creativity and curiosity of the larger community to help explore this data using some of the tools (like https://rainy-periwinkle.glitch.me/https://rainy-periwinkle.glitch.me/). Please share your interesting observations and help build our commons of knowledge and understanding. +

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":4,"title":"Media","description":"Media chapter of the 2019 Web Almanac covering image file sizes and formats, responsive images, client hints, lazy loading, accessibility and video.","authors":["colinbendell","dougsillars"],"reviewers":["ahmadawais","eeeps"],"translators":null,"discuss":"1759","results":"https://docs.google.com/spreadsheets/d/1hj9bY6JJZfV9yrXHsoCRYuG8t8bR-CHuuD98zXV7BBQ/","queries":"04_Media","published":"2019-11-11","last_updated":"2020-05-19","chapter":"media"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 4 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Media +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":4,"title":"Media","description":"Media chapter of the 2019 Web Almanac covering image file sizes and formats, responsive images, client hints, lazy loading, accessibility and video.","authors":["colinbendell","dougsillars"],"reviewers":["ahmadawais","eeeps"],"translators":null,"discuss":"1759","results":"https://docs.google.com/spreadsheets/d/1hj9bY6JJZfV9yrXHsoCRYuG8t8bR-CHuuD98zXV7BBQ/","queries":"04_Media","published":"2019-11-11","last_updated":"2020-05-19","chapter":"media"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -1407,29 +1566,40 @@

    - + -
    {{ self.written_by_before() }} Colin Bendell, {{ self.and() }} Doug Sillars{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Ahmad Awais, {{ self.and() }} Eric Portis{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Images, animations, and videos are an important part of the web experience. They are important for many reasons: they help tell stories, engage audiences, and provide artistic expression in ways that often cannot be easily produced with other web technologies. The importance of these media resources can be demonstrated in two ways: by the sheer volume of bytes required to download for a page, and also the volume of pixels painted with media.

    -

    From a pure bytes perspective, HTTP Archive has historically reported an average of two-thirds of resource bytes associated from media. From a distribution perspective, we can see that virtually every web page depends on images and videos. Even at the tenth percentile, we see that 44% of the bytes are from media and can rise to 91% of the total bytes at the 90th percentile of pages.

    +

    + From a pure bytes perspective, HTTP Archive has historically reportedhttps://legacy.httparchive.org/interesting.php#bytesperpage an average of two-thirds of resource bytes associated from media. From a distribution perspective, we can see that virtually every web page depends on images and videos. Even at the tenth percentile, we see that 44% of the bytes are from media and can rise to 91% of the total bytes at the 90th percentile of pages. +

    - Figure 1. Web page bytes: image and video versus other. + Figure 1. Web page bytes: image and video versus other.
    Figure 1. Web page bytes: image and video versus other.

    While media are critical for the visual experience, the impact of this high volume of bytes has two side effects.

    First, the network overhead required to download these bytes can be large and in cellular or slow network environments (like coffee shops or tethering when in an Uber) can dramatically slow down the page performance. Images are a lower priority request by the browser but can easily block CSS and JavaScript in the download. This by itself can delay the page rendering. Yet at other times, the image content is the visual cue to the user that the page is ready. Slow transfers of visual content, therefore, can give the perception of a slow web page.

    -

    The second impact is on the financial cost to the user. This is often an ignored aspect since it is not a burden on the website owner but a burden to the end-user. Anecdotally, it has been shared that some markets, like Japan, see a drop in purchases by students near the end of the month when data caps are reached, and users cannot see the visual content.

    -

    Further, the financial cost of visiting these websites in different parts of the world is disproportionate. At the median and 90th percentile, the volume of image bytes is 1 MB and 1.9 MB respectively. Using WhatDoesMySiteCost.com we can see that the gross national income (GNI) per capita cost to a user in Madagascar a single web page load at the 90th percentile would cost 2.6% of the daily gross income. By contrast, in Germany this would be 0.3% of the daily gross income.

    +

    + The second impact is on the financial cost to the user. This is often an ignored aspect since it is not a burden on the website owner but a burden to the end-user. Anecdotally, it has been shared that some markets, like Japanhttps://twitter.com/yoavweiss/status/1195036487538003968?s=20, see a drop in purchases by students near the end of the month when data caps are reached, and users cannot see the visual content. +

    +

    + Further, the financial cost of visiting these websites in different parts of the world is disproportionate. At the median and 90th percentile, the volume of image bytes is 1 MB and 1.9 MB respectively. Using WhatDoesMySiteCost.comhttps://whatdoesmysitecost.com/#gniCost we can see that the gross national income (GNI) per capita cost to a user in Madagascar a single web page load at the 90th percentile would cost 2.6% of the daily gross income. By contrast, in Germany this would be 0.3% of the daily gross income. +

    - Figure 2. Total image bytes per web page (mobile). + Figure 2. Total image bytes per web page (mobile).
    Figure 2. Total image bytes per web page (mobile).
    @@ -1449,14 +1619,14 @@

    In
    - Figure 3. Image pixels per page (mobile): CSS versus actual. + Figure 3. Image pixels per page (mobile): CSS versus actual.
    Figure 3. Image pixels per page (mobile): CSS versus actual.
    - Figure 4. Image pixels per page (desktop): CSS versus actual. + Figure 4. Image pixels per page (desktop): CSS versus actual.
    Figure 4. Image pixels per page (desktop): CSS versus actual.
    @@ -1470,7 +1640,7 @@

    In

    Note: this is only looking at the CSS layout for both the viper and the volume of layout content. It is not evaluating the effectiveness of the responsive images or the effectiveness of providing high DPR content.

    - Figure 5. Image pixel volume versus screen size (CSS pixels). + Figure 5. Image pixel volume versus screen size (CSS pixels).
    Figure 5. Image pixel volume versus screen size (CSS pixels).
    @@ -1567,7 +1737,10 @@

    Images

    @@ -1589,7 +1762,7 @@

    In aggregate, across all page, we indeed see the prevalence of these formats. JPEG, one of the oldest formats on the web, is by far the most commonly used image formats at 60% of the image requests and 65% of all image bytes. Interestingly, PNG is the second most commonly used image format 28% of image requests and bytes. The ubiquity of support along with the precision of color and creative content are likely explanations for its wide use. In contrast SVG, GIF, and WebP share nearly the same usage at 4%.

    - Most frequent Image types used on web pages + Most frequent Image types used on web pages
    Figure 7: Image format usage.
    @@ -1597,7 +1770,7 @@

    Of course, web pages are not uniform in their use of image content. Some depend on images more than others. Look no further than the home page of google.com and you will see very little imagery compared to a typical news website. Indeed, the median website has 13 images, 61 images at the 90th percentile, and a whopping 229 images at the 99th percentile.

    - Figure 8. Image format usage per page. + Figure 8. Image format usage per page.
    Figure 8. Image format usage per page.
    @@ -1605,7 +1778,7 @@

    While the median page has nine JPEGs and four PNGs, and only in the top 25% pages GIFs were used, this doesn't report the adoption rate. The use and frequency of each format per page doesn't provide insight into the adoption of the more modern formats. Specifically, what percent of pages include at least one image in each format?

    - Figure 9. % of pages using at least 1 image. + Figure 9. % of pages using at least 1 image.
    Figure 9. Percent of pages using at least one image.
    @@ -1615,7 +1788,7 @@

    - A comparison of image formats by file size + A comparison of image formats by file size
    Figure 10. File size (KB) by image format.
    @@ -1623,7 +1796,7 @@

    - Figure 11. Bytes per pixel. + Figure 11. Bytes per pixel.
    Figure 11. Bytes per pixel.
    @@ -1638,7 +1811,7 @@

    Lighthouse test is an A/B comparing baseline with a progressively encoded JPEG. This provides a smell to indicate whether the images overall can be further optimized with lossless techniques and potentially with lossy techniques like using different quality levels.

    - Figure 12. Percent 'optimized' images. + Figure 12. Percent 'optimized' images.
    Figure 12. Percent "optimized" images.
    @@ -1646,7 +1819,7 @@

    - Figure 13. Projected page performance improvements from image optimization from Lighthouse. + Figure 13. Projected page performance improvements from image optimization from Lighthouse.
    Figure 13. Projected page performance improvements from image optimization from Lighthouse.
    @@ -1662,12 +1835,15 @@

    - Figure 14. Percent of pages using responsive images with HTML. + Figure 14. Percent of pages using responsive images with HTML.
    Figure 14. Percent of pages using responsive images with HTML.

    -

    The notably lower use of <picture> is not surprising given that it is used most often for advanced responsive web design (RWD) layouts like art direction.

    +

    + The notably lower use of <picture> is not surprising given that it is used most often for advanced responsive web design (RWD) layouts like art directionhttps://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images#Art_direction. +

    Use of sizes

    The utility of srcset is usually dependent on the precision of the sizes media query. Without sizes the browser will assume the <img> tag will fill the entire viewport instead of smaller component. Interestingly, there are five common patterns that web developers have adopted for <img sizes>:

      @@ -1736,17 +1912,19 @@

      Us

    - Figure 16. Top patterns of 'img sizes'. + Figure 16. Top patterns of 'img sizes'.
    Figure 16. Top patterns of <img sizes>.

    Client Hints

    -

    Client Hints allow content creators to move the resizing of images to HTTP content negotiation. In this way, the HTML does not need additional <img srcset> to clutter the markup, and instead can depend on a server or image CDN to select an optimal image for the context. This allows simplifying of HTML and enables origin servers to adapt overtime and disconnect the content and presentation layers.

    +

    + Client Hintshttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/client-hints allow content creators to move the resizing of images to HTTP content negotiation. In this way, the HTML does not need additional <img srcset> to clutter the markup, and instead can depend on a server or image CDN to select an optimal imagehttps://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67 for the context. This allows simplifying of HTML and enables origin servers to adapt overtime and disconnect the content and presentation layers. +

    To enable Client Hints, the web page must signal to the browser using either an extra HTTP header Accept-CH: DPR, Width, Viewport-Width or by adding the HTML <meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">. The convenience of one or the other technique depends on the team implementing and both are offered for convenience.

    - Usage of the Accept-CH: HTTP versus HTML. + Usage of the Accept-CH: HTTP versus HTML.
    Figure 17. Usage of the Accept-CH header versus the equivalent <meta> tag.
    @@ -1755,7 +1933,7 @@

    Cl

    Of the Client Hints invoked, the majority of pages use it for the original three use-cases of DPR, ViewportWidth and Width. Of course, the Width Client Hint that requires the use <img sizes> for the browser to have enough context about the layout.

    - Figure 18. Enabled Client Hints. + Figure 18. Enabled Client Hints.
    Figure 18. Enabled Client Hints.
    @@ -1763,17 +1941,23 @@

    Cl

    The network-related Client Hints, downlink, rtt, and ect, are only available on Android Chrome.

    Lazy loading

    Improving web page performance can be partially characterized as a game of illusions; moving slow things out of band and out of site of the user. In this way, lazy loading images is one of these illusions where the image and media content is only loaded when the user scrolls on the page. This improves perceived performance, even on slow networks, and saves the user from downloading bytes that are not otherwise viewed.

    -

    Earlier, in Figure 5, we showed that the volume of image content at the 75th percentile is far more than could theoretically be shown in a single desktop or mobile viewport. The offscreen images Lighthouse audit confirms this suspicion. The median web page has 27% of image content significantly below the fold. This grows to 84% at the 90th percentile.

    +

    + Earlier, in Figure 5, we showed that the volume of image content at the 75th percentile is far more than could theoretically be shown in a single desktop or mobile viewport. The offscreen imageshttps://developers.google.com/web/tools/lighthouse/audits/offscreen-images Lighthouse audit confirms this suspicion. The median web page has 27% of image content significantly below the fold. This grows to 84% at the 90th percentile. +

    - Figure 19. Lighthouse audit: Offscreen. + Figure 19. Lighthouse audit: Offscreen.
    Figure 19. Lighthouse audit: Offscreen.

    The Lighthouse audit provides us a smell as there are a number of situations that can provide tricky to detect such as the use of quality placeholders.

    -

    Lazy loading can be implemented in many different ways including using a combination of Intersection Observers, Resize Observers, or using JavaScript libraries like lazySizes, lozad, and a host of others.

    -

    In August 2019, Chrome 76 launched with the support for markup-based lazy loading using <img loading="lazy">. While the snapshot of websites used for the 2019 Web Almanac used July 2019 data, over 2,509 websites already utilized this feature.

    +

    + Lazy loading can be implementedhttps://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video in many different ways including using a combination of Intersection Observers, Resize Observers, or using JavaScript libraries like lazySizeshttps://github.com/aFarkas/lazysizes, lozadhttps://github.com/ApoorvSaxena/lozad.js, and a host of others. +

    +

    In August 2019, Chrome 76 launched with the support for markup-based lazy loading using <img>. While the snapshot of websites used for the 2019 Web Almanac used July 2019 data, over 2,509 websites already utilized this feature.

    Accessibility

    At the heart of image accessibility is the alt tag. When the alt tag is added to an image, this text can be used to describe the image to a user who is unable to view the images (either due to a disability, or a poor internet connection).

    We can detect all of the image tags in the HTML files of the dataset. Of 13 million image tags on desktop and 15 million on mobile, 91.6% of images have an alt tag present. At initial glance, it appears that image accessibility is in very good shape on the web. However, upon deeper inspection, the outlook is not as good. If we examine the length of the alt tags present in the dataset, we find that the median length of the alt tag is six characters. This maps to an empty alt tag (appearing as alt=""). Only 39% of images use alt text that is longer than six characters. The median value of "real" alt text is 31 characters, of which 25 actually describe the image.

    @@ -1783,7 +1967,7 @@

    Video can be delivered with many different formats and players. The dominant formats for mobile and desktop are .ts (segments of HLS streaming) and .mp4 (the H264 MPEG):

    - Figure 20. Count of video files by extension. + Figure 20. Count of video files by extension.
    Figure 20. Count of video files by extension.
    @@ -1792,7 +1976,7 @@

    The median video size for each format is shown below:

    - Figure 21. Median file size by video extension. + Figure 21. Median file size by video extension.
    Figure 21. Median file size by video extension.
    @@ -1802,7 +1986,7 @@

    - Figure 21. Usage of HTML video tag attributes. + Figure 21. Usage of HTML video tag attributes.
    Figure 22. Usage of HTML video tag attributes.
    @@ -1814,7 +1998,7 @@

    For more advanced playback (and to play video streams), the HTML5 native video player will not work. There are a few popular video libraries that are used to playback the video:

    - Figure 23. Top JavaScript video players. + Figure 23. Top JavaScript video players.
    Figure 23. Top JavaScript video players.
    @@ -1822,79 +2006,73 @@

    The most popular (by far) is video.js, followed by JWPLayer and HLS.js. The authors do admit that it is possible that there are other files with the name "video.js" that may not be the same video playback library.

    Conclusion

    Nearly all web pages use images and video to some degree to enhance the user experience and create meaning. These media files utilize a large amount of resources and are a large percentage of the tonnage of websites (and they are not going away!) Utilization of alternative formats, lazy loading, responsive images, and image optimization can go a long way to lower the size of media on the web.

    -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":5,"title":"Third Parties","description":"Third Parties chapter of the 2019 Web Almanac covering data of what third parties are used, what they are used for, performance impacts and privacy impacts.","authors":["patrickhulce"],"reviewers":["zcorpan","obto","jasti"],"translators":null,"discuss":"1760","results":"https://docs.google.com/spreadsheets/d/1iC4WkdadDdkqkrTY32g7hHKhXs9iHrr3Bva8CuPjVrQ/","queries":"05_Third_Parties","published":"2019-11-11","last_updated":"2020-03-02","chapter":"third-parties"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 5 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Third Parties +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":5,"title":"Third Parties","description":"Third Parties chapter of the 2019 Web Almanac covering data of what third parties are used, what they are used for, performance impacts and privacy impacts.","authors":["patrickhulce"],"reviewers":["zcorpan","obto","jasti"],"translators":null,"discuss":"1760","results":"https://docs.google.com/spreadsheets/d/1iC4WkdadDdkqkrTY32g7hHKhXs9iHrr3Bva8CuPjVrQ/","queries":"05_Third_Parties","published":"2019-11-11","last_updated":"2020-03-02","chapter":"third-parties"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -1903,12 +2081,16 @@

    - + -
    {{ self.written_by_before() }} Patrick Hulce{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Simon Pieters, David Fox, {{ self.and() }} Vamsee Jasti{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    The open web is vast, linkable, and interoperable by design. The ability to grab someone else's complex library and use it on your site with a single <link> or <script> element has supercharged developers' productivity and enabled awesome new web experiences. On the flip side, the immense popularity of a select few third-party providers raises important performance, privacy, and security concerns. This chapter examines the prevalence and impact of third-party code on the web in 2019, the usage patterns that lead to the popularity of third-party solutions, and potential repercussions for the future of web experiences.

    Definitions

    @@ -1923,7 +2105,10 @@

    Provider categories

    -

    This chapter divides third-party providers into one of these broad categories. A brief description is included below and the mapping of domain to category can be found in the third-party-web repository.

    +

    + This chapter divides third-party providers into one of these broad categories. A brief description is included below and the mapping of domain to category can be found in the third-party-web repositoryhttps://github.com/patrickhulce/third-party-web/blob/8afa2d8cadddec8f0db39e7d715c07e85fb0f8ec/data/entities.json5. +

    • Ad - display and measurement of advertisements
    • Analytics - tracking site visitor behavior
      • @@ -1959,7 +2144,10 @@

      Providers

      A relatively small set of providers dominate the third-party landscape: the top 100 domains account for 30% of network requests across the web. Powerhouses like Google, Facebook, and YouTube make the headlines here with full percentage points of share each, but smaller entities like Wix and Shopify command a substantial portion of third-party popularity as well.

      -

      While much could be said about every individual provider's popularity and performance impact, this more opinionated analysis is left as an exercise for the reader and other purpose-built tools such as third-party-web.

      +

      + While much could be said about every individual provider's popularity and performance impact, this more opinionated analysis is left as an exercise for the reader and other purpose-built tools such as third-party-webhttps://thirdpartyweb.today. +

      @@ -2100,7 +2288,7 @@

      The resource type breakdown of third-party content also lends insight into how third-party code is used across the web. While first-party requests are 56% images, 23% script, 14% CSS, and only 4% HTML, third-party requests skew more heavily toward script and HTML at 32% script, 34% images, 12% HTML, and only 6% CSS. While this suggests that third-party code is less frequently used to aid the design and instead used more frequently to facilitate or observe interactions than first-party code, a breakdown of resource types by party status tells a more nuanced story. While CSS and images are dominantly first-party at 70% and 64% respectively, fonts are largely served by third-party providers with only 28% being served from first-party sources. This concept of usage patterns is explored in more depth later in this chapter.

      - Figure 5. Percent of third-party requests by category and content type. + Figure 5. Percent of third-party requests by category and content type.
      Figure 5. Percent of third-party requests by category and content type.
      @@ -2115,7 +2303,7 @@

      - Figure 7. Distributions of resource bytes per third-party category. + Figure 7. Distributions of resource bytes per third-party category.
      Figure 7. Distributions of resource bytes per third-party category.
      @@ -2133,14 +2321,19 @@

      third-party-web.

      +

      + While much could be said about every individual provider's popularity and performance impact, this more opinionated analysis is left as an exercise for the reader and other purpose-built tools such as the previously mentioned third-party-webhttps://thirdpartyweb.today. +

      Usage patterns

      Why do site owners use third-party code? How did third-party content grow to be nearly half of all network requests? What are all these requests doing? Answers to these questions lie in the three primary usage patterns of third-party resources. Broadly, site owners reach for third parties to generate and consume data from their users, monetize their site experiences, and simplify web development.

      Generate and consume data

      Analytics is the most popular third-party category found across the web and yet is minimally user-visible. Consider the volume of information at play in the lifetime of a web visit; there's user context, device, browser, connection quality, location, page interactions, session length, return visitor status, and more being generated continuously. It's difficult, cumbersome, and expensive to maintain tools that warehouse, normalize, and analyze time series data of this magnitude. While nothing categorically necessitates that analytics fall into the domain of third-party providers, the widespread attractiveness of understanding your users, deep complexity of the problem space, and increasing emphasis on managing data respectfully and responsibly naturally surfaces analytics as a popular third-party usage pattern.

      There's also a flip side to user data though: consumption. While analytics is about generating data from your site's visitors, other third-party resources focus on consuming data about your visitors that is known only by others. Social providers fall squarely into this usage pattern. A site owner must use Facebook resources if they wish to integrate information from a visitor's Facebook profile into their site. As long as site owners are interested in personalizing their experience with widgets from social networks and leveraging the social networks of their visitors to increase their reach, social integrations are likely to remain the domain of third-party entities for the foreseeable future.

      Monetize web traffic

      -

      The open model of the web does not always serve the financial interests of content creators to their liking and many site owners resort to monetizing their sites with advertising. Because building direct relationships with advertisers and negotiating pricing contracts is a relatively difficult and time-consuming process, this concern is largely handled by third-party providers performing targeted advertising and real-time bidding. Widespread negative public opinion, the popularity of ad blocking technology, and regulatory action in major global markets such as Europe pose the largest threat to the continued use of third-party providers for monetization. While it's unlikely that site owners suddenly strike their own advertising deals or build bespoke ad networks, alternative monetization models like paywalls and experiments like Brave's Basic Attention Token have a real chance of shaking up the third-party ad landscape of the future.

      +

      + The open model of the web does not always serve the financial interests of content creators to their liking and many site owners resort to monetizing their sites with advertising. Because building direct relationships with advertisers and negotiating pricing contracts is a relatively difficult and time-consuming process, this concern is largely handled by third-party providers performing targeted advertising and real-time bidding. Widespread negative public opinion, the popularity of ad blocking technology, and regulatory action in major global markets such as Europe pose the largest threat to the continued use of third-party providers for monetization. While it's unlikely that site owners suddenly strike their own advertising deals or build bespoke ad networks, alternative monetization models like paywalls and experiments like Brave's Basic Attention Tokenhttps://basicattentiontoken.org/ have a real chance of shaking up the third-party ad landscape of the future. +

      Simplify development

      Above all, third-party resources are used to simplify the web development experience. Even previous usage patterns could arguably fall into this pattern as well. Whether analyzing user behavior, communicating with advertisers, or personalizing the user experience, third-party resources are used to make first-party development easier.

      Hosting providers are the most extreme example of this pattern. Some of these providers even enable anyone on Earth to become a site owner with no technical expertise necessary. They provide hosting of assets, tools to build sites without coding experience, and domain registration services.

      @@ -2155,63 +2348,91 @@

      Privacy

      The abundance of analytics providers and top-heavy concentration of script execution raises two primary privacy concerns for site visitors: the largest use case of third-parties is for site owners to track their users and a handful of companies receive information on a large swath of web traffic.

      -

      The interest of site owners in understanding and analyzing user behavior is not malicious on its own, but the widespread and relatively behind-the-scenes nature of web analytics raises valid concerns, and users, companies, and lawmakers have taken notice in recent years with privacy regulation such as GDPR in Europe and the CCPA in California. Ensuring that developers handle user data responsibly, treat the user respectfully, and are transparent with what data is collected is key to keeping analytics the most popular third-party category and maintaining the symbiotic nature of analyzing user behavior to deliver future user value.

      +

      + The interest of site owners in understanding and analyzing user behavior is not malicious on its own, but the widespread and relatively behind-the-scenes nature of web analytics raises valid concerns, and users, companies, and lawmakers have taken notice in recent years with privacy regulation such as GDPRhttps://en.wikipedia.org/wiki/General_Data_Protection_Regulation in Europe and the CCPAhttps://en.wikipedia.org/wiki/California_Consumer_Privacy_Act in California. Ensuring that developers handle user data responsibly, treat the user respectfully, and are transparent with what data is collected is key to keeping analytics the most popular third-party category and maintaining the symbiotic nature of analyzing user behavior to deliver future user value. +

      The top-heavy concentration of script execution is great for the potential impact of performance improvements, but less exciting for the privacy ramifications. 29% of all script execution time across the web is just from scripts on domains owned by Google or Facebook. That's a very large percentage of CPU time that is controlled by just two entities. It's critical to ensure that the same privacy protections held to analytics providers be applied in these other ad, social, and developer utility categories as well.

      Security

      -

      While the topic of security is covered more in-depth in the Security chapter, the security implications of introducing external dependencies to your site go hand-in-hand with privacy concerns. Allowing third parties to execute arbitrary JavaScript effectively provides them with complete control over your page. When a script can control the DOM and window, it can do everything. Even if code has no security concerns, it can introduce a single point of failure, which has been recognized as a potential problem for some time now.

      -

      Self-hosting third-party content addresses some of the concerns mentioned here - and others. Additionally with browsers increasingly partitioning HTTP caches the benefits of loading directly from the third-party are increasingly questionable. Perhaps this is a better way to consume third-party content for many use cases, even if it makes measuring its impact more difficult.

      +

      + While the topic of security is covered more in-depth in the Security chapter, the security implications of introducing external dependencies to your site go hand-in-hand with privacy concerns. Allowing third parties to execute arbitrary JavaScript effectively provides them with complete control over your page. When a script can control the DOM and window, it can do everything. Even if code has no security concerns, it can introduce a single point of failure, which has been recognized as a potential problem for some time nowhttps://www.stevesouders.com/blog/2010/06/01/frontend-spof/. +

      +

      + Self-hosting third-party contenthttps://csswizardry.com/2019/05/self-host-your-static-assets/ addresses some of the concerns mentioned here - and others. Additionally with browsers increasingly partitioning HTTP cacheshttps://chromestatus.com/feature/5730772021411840 the benefits of loading directly from the third-party are increasingly questionable. Perhaps this is a better way to consume third-party content for many use cases, even if it makes measuring its impact more difficult. +

      Conclusion

      Third-party content is everywhere. This is hardly surprising; the entire basis of the web is to allow interconnectedness and linking. In this chapter we have examined third-party content in terms of assets hosted away from the main domain. If we had included self-hosted third-party content (e.g. common open source libraries hosted on the main domain), third-party usage would have been even larger!

      -

      While reuse in computer technologies is generally a best practice, third parties on the web introduce dependencies that have a considerable impact on the performance, privacy, and security of a page. Self-hosting and careful provider selection can go a long way to mitigate these effects

      +

      + While reuse in computer technologieshttps://en.wikipedia.org/wiki/Code_reuse is generally a best practice, third parties on the web introduce dependencies that have a considerable impact on the performance, privacy, and security of a page. Self-hosting and careful provider selection can go a long way to mitigate these effects +

      Regardless of the important question of how third-party content is added to a page, the conclusion is the same: third parties are an integral part of the web!

      -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":6,"title":"Fonts","description":"Fonts chapter of the 2019 Web Almanac covering where fonts are loaded from, font formats, font loading performance, variable fonts and color fonts.","authors":["zachleat"],"reviewers":["hyperpress","AymenLoukil"],"translators":null,"discuss":"1761","results":"https://docs.google.com/spreadsheets/d/108g6LXdC3YVsxmX1CCwrmpZ3-DmbB8G_wwgQHX5pn6Q/","queries":"06_Fonts","published":"2019-11-11","last_updated":"2020-03-02","chapter":"fonts"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 6 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Fonts +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":6,"title":"Fonts","description":"Fonts chapter of the 2019 Web Almanac covering where fonts are loaded from, font formats, font loading performance, variable fonts and color fonts.","authors":["zachleat"],"reviewers":["hyperpress","AymenLoukil"],"translators":null,"discuss":"1761","results":"https://docs.google.com/spreadsheets/d/108g6LXdC3YVsxmX1CCwrmpZ3-DmbB8G_wwgQHX5pn6Q/","queries":"06_Fonts","published":"2019-11-11","last_updated":"2020-03-02","chapter":"fonts"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -2220,31 +2441,41 @@

    - + -
    {{ self.written_by_before() }} Zach Leatherman{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} John Teague, {{ self.and() }} Aymen Loukil{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Web fonts enable beautiful and functional typography on the web. Using web fonts not only empowers design, but it democratizes a subset of design, as it allows easier access to those who might not have particularly strong design skills. However, for all the good they can do, web fonts can also do great harm to your site's performance if they are not loaded properly.

    Are they a net positive for the web? Do they provide more benefit than harm? Are the web standards cowpaths sufficiently paved to encourage web font loading best practices by default? And if not, what needs to change? Let's take a data-driven peek at whether or not we can answer those questions by inspecting how web fonts are used on the web today.

    Where did you get those web fonts?

    The first and most prominent question: performance. There is a whole chapter dedicated to performance but we will delve a little into font-specific performance issues here.

    -

    Using hosted web fonts enables ease of implementation and maintenance, but self-hosting offers the best performance. Given that web fonts by default make text invisible while the web font is loading (also known as the Flash of Invisible Text, or FOIT), the performance of web fonts can be more critical than non-blocking assets like images.

    +

    + Using hosted web fonts enables ease of implementation and maintenance, but self-hosting offers the best performance. Given that web fonts by default make text invisible while the web font is loading (also known as the Flash of Invisible Texthttps://css-tricks.com/fout-foit-foft/, or FOIT), the performance of web fonts can be more critical than non-blocking assets like images. +

    Are fonts being hosted on the same host or by a different host?

    Differentiating self-hosting against third-party hosting is increasingly relevant in an HTTP/2 world, where the performance gap between a same-host and different-host connection can be wider. Same-host requests have the huge benefit of a better potential for prioritization against other same-host requests in the waterfall.

    Recommendations to mitigate the performance costs of loading web fonts from another host include using the preconnect, dns-prefetch, and preload resource hints, but high priority web fonts should be same-host requests to minimize the performance impact of web fonts. This is especially important for fonts used by very visually prominent content or body copy occupying the majority of a page.

    - Figure 1. Popular web font hosting strategies. + Figure 1. Popular web font hosting strategies.
    Figure 1. Popular web font hosting strategies.

    The fact that three quarters are hosted is perhaps unsurprising given Google Fonts dominance that we will discuss below.

    Google serves fonts using third-party CSS files hosted on https://fonts.googleapis.com. Developers add requests to these stylesheets using <link> tags in their markup. While these stylesheets are render blocking, they are very small. However, the font files are hosted on yet another domain, https://fonts.gstatic.com. The model of requiring two separate hops to two different domains makes preconnect a great option here for the second request that will not be discovered until the CSS is downloaded.

    -

    Note that while preload would be a nice addition to load the font files higher in the request waterfall (remember that preconnect sets up the connection, it doesn’t request the file content), preload is not yet available with Google Fonts. Google Fonts generates unique URLs for their font files which are subject to change.

    +

    + Note that while preload would be a nice addition to load the font files higher in the request waterfall (remember that preconnect sets up the connection, it doesn’t request the file content), preload is not yet available with Google Fonts. Google Fonts generates unique URLs for their font files which are subject to changehttps://github.com/google/fonts/issues/1067. +

    @@ -2374,7 +2605,7 @@
    -

    It is unsurprising that the top entries here seem to match up very similarly to Google Fonts' list of fonts sorted by popularity.

    +

    + It is unsurprising that the top entries here seem to match up very similarly to Google Fonts' list of fonts sorted by popularityhttps://fonts.google.com/?sort=popularity. +

    What font formats are being used?

    -

    WOFF2 is pretty well supported in web browsers today. Google Fonts serves WOFF2, a format that offers improved compression over its predecessor WOFF, which was itself already an improvement over other existing font formats.

    +

    + WOFF2 is pretty well supportedhttps://caniuse.com/#feat=woff2 in web browsers today. Google Fonts serves WOFF2, a format that offers improved compression over its predecessor WOFF, which was itself already an improvement over other existing font formats. +

    - Figure 7. Popularity of web font MIME types. + Figure 7. Popularity of web font MIME types.
    Figure 7. Popularity of web font MIME types.
    @@ -2550,12 +2786,14 @@

    - Figure 8. Popularity of font formats in <code>@font-face</code> declarations. + Figure 8. Popularity of font formats in <code>@font-face</code> declarations.
    Figure 8. Popularity of font formats in @font-face declarations.

    -

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

    +

    + I was hoping to see SVG fontshttps://caniuse.com/#feat=svg-fonts on the decline. They're buggy and implementations have been removed from every browser except Safari. Time to drop these, y'all. +

    The SVG data point here also makes me wonder what MIME type y'all are serving these SVG fonts with. I don't see image/svg+xml anywhere in Figure 7. Anyway, don't worry about fixing that, just get rid of them!

    WOFF2-only

    @@ -2701,19 +2939,24 @@

    WOFF2-

    Importantly, this particular data doesn't really support or detract from the case to go WOFF2-only yet, but it remains a tempting idea.

    Fighting against invisible text

    The number one tool we have to fight the default web font loading behavior of "invisible while loading" (also known as FOIT), is font-display. Adding font-display: swap to your @font-face block is an easy way to tell the browser to show fallback text while the web font is loading.

    -

    Browser support is great too. Internet Explorer and pre-Chromium Edge don't have support but they also render fallback text by default when a web font loads (no FOITs allowed here). For our Chrome tests, how commonly is font-display used?

    +

    + Browser supporthttps://caniuse.com/#feat=mdn-css_at-rules_font-face_font-display is great too. Internet Explorer and pre-Chromium Edge don't have support but they also render fallback text by default when a web font loads (no FOITs allowed here). For our Chrome tests, how commonly is font-display used? +

    26%
    Figure 10. Percent of mobile pages that utilize the font-display style.

    - I assume this will be creeping up over time, especially now that Google Fonts is adding font-display to all new code snippets copied from their site. + I assume this will be creeping up over time, especially now that Google Fonts is adding font-display to all new code snippetshttps://www.zachleat.com/web/google-fonts-display/ copied from their site. +

    +

    + If you're using Google Fonts, update your snippets! If you're not using Google Fonts, use font-display! Read more about font-display on MDNhttps://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display.

    -

    If you're using Google Fonts, update your snippets! If you're not using Google Fonts, use font-display! Read more about font-display on MDN.

    Let's have a look at what font-display values are popular:

    - Figure 11. Usage of 'font-display' values. + Figure 11. Usage of 'font-display' values.
    Figure 11. Usage of font-display values.
    @@ -2723,7 +2966,7 @@

    - Figure 12. Distribution of font requests per page. + Figure 12. Distribution of font requests per page.
    Figure 12. Distribution of font requests per page.
    @@ -2731,13 +2974,13 @@

    - Figure 13. Histogram of web fonts requested per page. + Figure 13. Histogram of web fonts requested per page.
    Figure 13. Histogram of web fonts requested per page.

    - It does seem quite interesting that web font requests seem to be pretty steady across desktop and mobile. I'm glad to see the recommendation to hide @font-face blocks inside of a @media queries didn't catch on (don't get any ideas). + It does seem quite interesting that web font requests seem to be pretty steady across desktop and mobile. I'm glad to see the recommendation to hide @font-face blocks inside of a @media querieshttps://css-tricks.com/snippets/css/using-font-face/#article-header-id-6 didn't catch on (don't get any ideas).

    That said there are marginally more requests for fonts made on mobile devices. My hunch here is that fewer typefaces are available on mobile devices, which in turn means fewer local() hits in Google Fonts CSS, falling back to network requests for these.

    You don't want to win this award

    @@ -2756,7 +2999,7 @@

    Figure 15. Percent of mobile pages that declare a web font with the unicode-range property.

    - unicode-range is a great CSS property to let the browser know specifically which code points the page would like to use in the font file. If the @font-face declaration has a unicode-range, content on the page must match one of the code points in the range before the font is requested. It is a very good thing. + unicode-rangehttps://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range is a great CSS property to let the browser know specifically which code points the page would like to use in the font file. If the @font-face declaration has a unicode-range, content on the page must match one of the code points in the range before the font is requested. It is a very good thing.

    This is another metric that I expect was skewed by Google Fonts usage, as Google Fonts uses unicode-range in most (if not all) of its CSS. I'd expect this to be less common in user land, but perhaps filtering out Google Fonts requests in the next edition of the Almanac may be possible.

    Don't request web fonts if a system font exists

    @@ -2766,7 +3009,8 @@

    using local() can be unpredictable as installed versions of fonts can be outdated and unreliable. + It should also be noted here that it has been said by smarter people than I (Bram Stein of TypeKit) that using local() can be unpredictable as installed versions of fonts can be outdated and unreliablehttps://bramstein.com/writing/web-font-anti-patterns-local-fonts.html.

    Condensed fonts and font-stretch @@ -2776,19 +3020,24 @@

    Figure 17. Percent of desktop and mobile pages that include a style with the font-stretch property.

    - Historically, font-stretch has suffered from poor browser support and was not a well-known @font-face property. Read more about font-stretch on MDN. But browser support has broadened. + Historically, font-stretch has suffered from poor browser support and was not a well-known @font-face property. Read more about font-stretch on MDNhttps://developer.mozilla.org/en-US/docs/Web/CSS/font-stretch. But browser supporthttps://caniuse.com/#feat=css-font-stretch has broadened.

    It has been suggested that using condensed fonts on smaller viewports allows more text to be viewable, but this approach isn't commonly used. That being said, that this property is used half a percentage point more on desktop than mobile is unexpected, and 7% seems much higher than I would have predicted.

    Variable fonts are the future

    -

    Variable fonts allow several font weights and styles to be included in the one font file.

    +

    + Variable fontshttps://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Fonts/Variable_Fonts_Guide allow several font weights and styles to be included in the one font file. +

    1.8%
    Figure 18. Percent of pages that include a variable font.
    -

    Even at 1.8% this was higher than expected, although I am excited to see this take off. Google Fonts v2 does include some support for variable fonts.

    +

    + Even at 1.8% this was higher than expected, although I am excited to see this take off. Google Fonts v2https://developers.google.com/fonts/docs/css2 does include some support for variable fonts. +

    - Figure 19. Usage of 'font-variation-settings' axes. + Figure 19. Usage of 'font-variation-settings' axes.
    Figure 19. Usage of font-variation-settings axes.
    @@ -2799,60 +3048,81 @@

    117

    Figure 20. The number of desktop web pages that include a color font.
    -

    Usage here of these is basically nonexistent but you can check out the excellent resource Color Fonts! WTF? for more information. Similar (but not at all) to the SVG format for fonts (which is bad and going away), this allows you to embed SVG inside of OpenType files, which is awesome and cool.

    +

    + Usage here of these is basically nonexistent but you can check out the excellent resource Color Fonts! WTF?https://www.colorfonts.wtf/ for more information. Similar (but not at all) to the SVG format for fonts (which is bad and going away), this allows you to embed SVG inside of OpenType files, which is awesome and cool. +

    Conclusion

    The biggest takeaway here is that Google Fonts dominates the web font discussion. Approaches they've taken weigh heavily on the data we've recorded here. The positives here are easy access to web fonts, good font formats (WOFF2), and for-free unicode-range configurations. The downsides here are performance drawbacks associated with third-party hosting, different-host requests, and no access to preload.

    I fully expect that in the future we'll see the "Rise of the Variable Font". This should be paired with a decline in web font requests, as Variable Fonts combine multiple individual font files into a single composite font file. But history has shown us that what usually happens here is that we optimize a thing and then add more things to fill the vacancy.

    It will be very interesting to see if color fonts increase in popularity. I expect these to be far more niche than variable fonts but may see a lifeline in the icon font space.

    Keep those fonts frosty, y'all.

    -
    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":7,"title":"Performance","description":"Performance chapter of the 2019 Web Almanac covering First Contentful Paint (FCP), Time to First Byte (TTFB), and First Input Delay (FID).","authors":["rviscomi"],"reviewers":["JMPerez","obto","sergeychernyshev","zeman"],"translators":null,"discuss":"1762","results":"https://docs.google.com/spreadsheets/d/1zWzFSQ_ygb-gGr1H1BsJCfB7Z89zSIf7GX0UayVEte4/","queries":"07_Performance","published":"2019-11-11","last_updated":"2020-03-01","chapter":"performance"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 7 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Performance +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":7,"title":"Performance","description":"Performance chapter of the 2019 Web Almanac covering First Contentful Paint (FCP), Time to First Byte (TTFB), and First Input Delay (FID).","authors":["rviscomi"],"reviewers":["JMPerez","obto","sergeychernyshev","zeman"],"translators":null,"discuss":"1762","results":"https://docs.google.com/spreadsheets/d/1zWzFSQ_ygb-gGr1H1BsJCfB7Z89zSIf7GX0UayVEte4/","queries":"07_Performance","published":"2019-11-11","last_updated":"2020-03-01","chapter":"performance"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -2861,18 +3131,28 @@

    - + -
    {{ self.written_by_before() }} Rick Viscomi{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} José M. Pérez, David Fox, Sergey Chernyshev, {{ self.and() }} Mark Zeman{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    -

    Performance is a visceral part of the user experience. For many websites, 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 to be rage clicking on the page in frustration.

    +

    + Performance is a visceral part of the user experience. For many websiteshttps://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 to be rage clickinghttps://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. 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 testing and real-user measurement (or RUM). Measuring performance in the lab ensures that each website is tested under common conditions and variables like browser, connection speed, physical location, cache state, etc. remain the same. 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.

    The state of performance

    -

    Almost all of the other chapters in the Web Almanac are based on data from the HTTP Archive. However, in order to capture how real users experience the web, we need a different dataset. In this section, we're using the Chrome UX Report (CrUX), a public dataset from Google that consists of all the same websites as the HTTP Archive, and aggregates how Chrome users actually experience them. Experiences are categorized by:

    +

    + Almost all of the other chapters in the Web Almanac are based on data from the HTTP Archivehttps://httparchive.org/. However, in order to capture how real users experience the web, we need a different dataset. In this section, we're using the Chrome UX Reporthttp://bit.ly/chrome-ux-report (CrUX), a public dataset from Google that consists of all the same websites as the HTTP Archive, and aggregates how Chrome users actually experience them. Experiences are categorized by: +

    • The form factor of the users' devices @@ -2894,22 +3174,26 @@

      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. Then, we'll look at look at a loading metric, 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 (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 Painthttps://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. Then, we'll look at look at a loading metric, Time to First Bytehttps://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 Delayhttps://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 insights we can find.

      First Contentful Paint

      - Figure 1. Distribution of websites' fast, moderate, and slow FCP performance. + Figure 1. Distribution of websites' fast, moderate, 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 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 that, websites that have a combination of fast, moderate, and slow performance seem to lean more towards fast or moderate than slow, which is good.

      Note: When a user experiences slow performance, it's hard to say what the reason might be. It could be that the website itself was built poorly and inefficiently. Or there could be other environmental factors like the user's slow connection, empty cache, etc. So, when looking at this field data we prefer to say that the user experiences themselves are slow, and not necessarily the websites.

      -

      In order to categorize whether a website is sufficiently fast we will use the new PageSpeed Insights (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.

      +

      + In order to categorize whether a website is sufficiently fast we will use the new PageSpeed Insightshttps://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. +

      - Figure 2. Distribution of websites labeled as having fast, moderate, or slow FCP. + Figure 2. Distribution of websites labeled as having fast, moderate, or slow FCP.
      Figure 2. Distribution of websites labeled as having fast, moderate, or slow FCP.
      @@ -2919,14 +3203,14 @@

      FCP by device

      - Figure 3. Distribution of <em>desktop</em> websites' fast, moderate, and slow FCP performance. + Figure 3. Distribution of <em>desktop</em> websites' fast, moderate, and slow FCP performance.
      Figure 3. Distribution of desktop websites' fast, moderate, and slow FCP performance.
      - Figure 4. Distribution of 'phone' websites' fast, moderate, and slow FCP performance. + Figure 4. Distribution of 'phone' websites' fast, moderate, and slow FCP performance.
      Figure 4. Distribution of phone websites' fast, moderate, and slow FCP performance.
      @@ -2934,7 +3218,7 @@

      - Figure 5. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by device type. + Figure 5. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by device type.
      Figure 5. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by device type.
      @@ -2944,7 +3228,7 @@

      FCP by effective connection type

      - Figure 6. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by ECT. + Figure 6. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by ECT.
      Figure 6. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by ECT.
      @@ -2953,36 +3237,46 @@

      FCP by geography

      - Figure 7. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by geo. + Figure 7. Distribution of websites labeled as having fast, moderate, or slow FCP, broken down by geo.
      Figure 7. Distribution of websites labeled 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. 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 (APAC) geos: Korea, Taiwan, and Japan. This could be explained by the availability of extremely fast network connection speeds in these regions. 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.

      +

      + 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-Pacifichttps://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 regionshttps://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 10% of fast websites. These geos also have more than triple the proportion of slow websites than Korea.

      Time to First Byte (TTFB)

      -

      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.

      +

      + Time to First Bytehttps://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 + 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 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.

      +

      + To help explain TTFB and the many factors that affect it, let's borrow a diagram from the Navigation Timing API spechttps://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_API. 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. +

      - Figure 9. Distribution of websites' fast, moderate, and slow TTFB performance. + Figure 9. Distribution of websites' fast, moderate, and slow TTFB performance.
      Figure 9. Distribution of websites' fast, moderate, and slow TTFB performance.
      -

      Similar to the FCP chart in Figure 1, this is a view of 1,000 representative samples ordered by fast TTFB. A fast TTFB 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.

      +

      + Similar to the FCP chart in Figure 1, this is a view of 1,000 representative samples ordered by fast TTFB. A fast TTFBhttps://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, taking inspiration from the PSI methodology used above for FCP. If a website serves fast TTFB to 75% or more user experiences, it's labeled 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 10. Distribution of websites labeled as having fast, moderate, or slow TTFB. + Figure 10. Distribution of websites labeled as having fast, moderate, or slow TTFB.
      Figure 10. Distribution of websites labeled as having fast, moderate, or slow TTFB.
      @@ -2991,18 +3285,20 @@

      TTFB by geo

      - Figure 11. Distribution of websites labeled as having fast, moderate, or slow TTFB, broken down by geo. + Figure 11. Distribution of websites labeled as having fast, moderate, or slow TTFB, broken down by geo.
      Figure 11. Distribution of websites labeled 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 15% of websites with fast TTFB. India, for example, has fewer than 1% of websites with fast TTFB and 79% with slow TTFB.

      First Input Delay

      -

      The last field metric we'll look at is 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.

      +

      + The last field metric we'll look at is First Input Delayhttps://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 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.

      - Figure 12. Distribution of websites' fast, moderate, and slow FID performance. + Figure 12. Distribution of websites' fast, moderate, and slow FID performance.
      Figure 12. Distribution of websites' fast, moderate, and slow FID performance.
      @@ -3010,7 +3306,7 @@

      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 and Figure 9, 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.

      - Figure 13. Distribution of websites labeled as having fast, moderate, or slow TTFB. + Figure 13. Distribution of websites labeled as having fast, moderate, or slow TTFB.
      Figure 13. Distribution of websites labeled as having fast, moderate, or slow TTFB.
      @@ -3020,14 +3316,14 @@

      FID by device

      - Figure 14. Distribution of 'desktop' websites' fast, moderate, and slow FID performance. + Figure 14. Distribution of 'desktop' websites' fast, moderate, and slow FID performance.
      Figure 14. Distribution of desktop websites' fast, moderate, and slow FID performance.
      - Figure 15. Distribution of 'phone' websites' fast, moderate, and slow FID performance. + Figure 15. Distribution of 'phone' websites' fast, moderate, and slow FID performance.
      Figure 15. Distribution of phone websites' fast, moderate, and slow FID performance.
      @@ -3035,7 +3331,7 @@

      - Figure 16. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by device type. + Figure 16. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by device type.
      Figure 16. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by device type.
      @@ -3044,7 +3340,7 @@

      FID by effective connection type

      - Figure 17. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by ECT. + Figure 17. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by ECT.
      Figure 17. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by ECT.
      @@ -3054,7 +3350,7 @@

      FID by geo

      - Figure 18. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by geo. + Figure 18. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by geo.
      Figure 18. Distribution of websites labeled as having fast, moderate, or slow FID, broken down by geo.
      @@ -3064,52 +3360,77 @@

      Conclusion

      Quantifying how fast a web page loads is an imperfect science that can't be represented by a single metric. Conventional metrics like onload can miss the mark entirely by measuring irrelevant or imperceptible parts of the user experience. User-perceived metrics like FCP and FID more faithfully convey what users see and feel. Even still, neither metric can be looked at in isolation to draw conclusions about whether the overall page load experience was fast or slow. Only by looking at many metrics holistically, can we start to understand the performance for an individual website and the state of the web.

      The data presented in this chapter showed that there is still a lot of work to do to meet the goals set for fast websites. Certain form factors, effective connection types, and geos do correlate with better user experiences, but we can't forget about the combinations of demographics with poor performance. In many cases, the web platform is used for business; making more money from improving conversion rates can be a huge motivator for speeding up a website. Ultimately, for all websites, performance is about delivering positive experiences to users in a way that doesn't impede, frustrate, or enrage them.

      -

      As the web gets another year older and our ability to measure how users experience it improves incrementally, I'm looking forward to developers having access to metrics that capture more of the holistic user experience. FCP is very early on the timeline of showing useful content to users, and newer metrics like Largest Contentful Paint (LCP) are emerging to improve our visibility into how page loads are perceived. The Layout Instability API has also given us a novel glimpse into the frustration users experience beyond page load.

      +

      + As the web gets another year older and our ability to measure how users experience it improves incrementally, I'm looking forward to developers having access to metrics that capture more of the holistic user experience. FCP is very early on the timeline of showing useful content to users, and newer metrics like Largest Contentful Painthttps://web.dev/largest-contentful-paint (LCP) are emerging to improve our visibility into how page loads are perceived. The Layout Instability APIhttps://web.dev/layout-instability-api has also given us a novel glimpse into the frustration users experience beyond page load. +

      Equipped with these new metrics, the web in 2020 will become even more transparent, better understood, and give developers an advantage to make more meaningful progress to improve performance and contribute to positive user experiences.

      -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":8,"title":"Security","description":"Security chapter of the 2019 Web Almanac covering Transport Layer Security (TLS(), mixed content, security headers, cookies, and Subresource Integrity.","authors":["ScottHelme","arturjanc"],"reviewers":["bazzadp","ghedo","paulcalvano"],"translators":null,"discuss":"1763","results":"https://docs.google.com/spreadsheets/d/1Zq2tQhPE06YZUcbzryRrBE6rdZgHHlqEp2XcgS37cm8/","queries":"08_Security","published":"2019-11-11","last_updated":"2020-05-19","chapter":"security"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 8 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Security +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":8,"title":"Security","description":"Security chapter of the 2019 Web Almanac covering Transport Layer Security (TLS(), mixed content, security headers, cookies, and Subresource Integrity.","authors":["ScottHelme","arturjanc"],"reviewers":["bazzadp","ghedo","paulcalvano"],"translators":null,"discuss":"1763","results":"https://docs.google.com/spreadsheets/d/1Zq2tQhPE06YZUcbzryRrBE6rdZgHHlqEp2XcgS37cm8/","queries":"08_Security","published":"2019-11-11","last_updated":"2020-05-19","chapter":"security"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -3118,19 +3439,26 @@

    - + -
    {{ self.written_by_before() }} Scott Helme, {{ self.and() }} Artur Janc{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Barry Pollard, Alessandro Ghedini, {{ self.and() }} Paul Calvano{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    This chapter of the Web Almanac looks at the current status of security on the web. With security and privacy becoming increasingly more important online there has been an increase in the availability of features to protect site operators and users. We're going to look at the adoption of these new features across the web.

    Transport Layer Security

    -

    Perhaps the largest push to increasing security and privacy online we're seeing at present is the widespread adoption of Transport Layer Security (TLS). TLS (or the older version, SSL) is the protocol that gives us the 'S' in HTTPS and allows secure and private browsing of websites. Not only are we seeing a great increase in the use of HTTPS across the web, but also an increase in more modern versions of TLS like TLSv1.2 and TLSv1.3, which is also important.

    +

    + Perhaps the largest push to increasing security and privacy online we're seeing at present is the widespread adoption of Transport Layer Security (TLS). TLS (or the older version, SSL) is the protocol that gives us the 'S' in HTTPS and allows secure and private browsing of websites. Not only are we seeing a great increase in the use of HTTPS across the webhttps://httparchive.org/reports/state-of-the-web#pctHttps, but also an increase in more modern versions of TLS like TLSv1.2 and TLSv1.3, which is also important. +

    - Figure 1. Usage of HTTP versus HTTPS. + Figure 1. Usage of HTTP versus HTTPS.
    Figure 1. Usage of HTTP versus HTTPS.
    @@ -3138,17 +3466,20 @@

    Protocol versions

    - Figure 2. Usage of TLS protocol versions. + Figure 2. Usage of TLS protocol versions.
    Figure 2. Usage of TLS protocol versions.
    -

    Figure 2 shows the support for various protocol versions. Use of legacy TLS versions like TLSv1.0 and TLSv1.1 is minimal and almost all support is for the newer TLSv1.2 and TLSv1.3 versions of the protocol. Even though TLSv1.3 is still very young as a standard (TLSv1.3 was only formally approved in August 2018), over 40% of requests using TLS are using the latest version!

    +

    + Figure 2 shows the support for various protocol versions. Use of legacy TLS versions like TLSv1.0 and TLSv1.1 is minimal and almost all support is for the newer TLSv1.2 and TLSv1.3 versions of the protocol. Even though TLSv1.3 is still very young as a standard (TLSv1.3 was only formally approved in August 2018https://tools.ietf.org/html/rfc8446), over 40% of requests using TLS are using the latest version! +

    This is likely due to many sites using requests from the larger players for third-party content. For example, any sites load Google Analytics, Google AdWords, or Google Fonts and these large players like Google are typically early adopters for new protocols.

    If we look at just home pages, and not all the other requests made on sites, then the usage of TLS is considerably as expected, though still quite high which is likely due to CMS sites like Wordpress and CDNs:

    - Figure 3. Usage of TLS protocol versions for home page requests only. + Figure 3. Usage of TLS protocol versions for home page requests only.
    Figure 3. Usage of TLS protocol versions for home page requests only.
    @@ -3225,8 +3556,13 @@

    Figure 4. Top ten Certificate Authority used.

    As previously discussed, the volume for Google likely reflects repeated use of Google Analytics, Google Adwords, or Google Fonts on other sites.

    -

    The rise of Let's Encrypt has been meteoric after their launch in early 2016, since then they've become one of the top certificate issuers in the world. The availability of free certificates and the automated tooling has been critically important to the adoption of HTTPS on the web. Let's Encrypt certainly had a significant part to play in both of those.

    -

    The reduced cost has removed the barrier to entry for HTTPS, but the automation Let's Encrypt uses is perhaps more important in the long run as it allows shorter certificate lifetimes which has many security benefits.

    +

    + The rise of Let's Encrypthttps://letsencrypt.org/ has been meteoric after their launch in early 2016, since then they've become one of the top certificate issuers in the world. The availability of free certificates and the automated tooling has been critically important to the adoption of HTTPS on the web. Let's Encrypt certainly had a significant part to play in both of those. +

    +

    + The reduced cost has removed the barrier to entry for HTTPS, but the automation Let's Encrypt uses is perhaps more important in the long run as it allows shorter certificate lifetimes which has many security benefitshttps://scotthelme.co.uk/why-we-need-to-do-more-to-reduce-certificate-lifetimes/. +

    Authentication key type

    Alongside the important requirement to use HTTPS is the requirement to also use a good configuration. With so many configuration options and choices to make, this is a careful balance.

    First of all, we'll look at the keys used for authentication purposes. Traditionally certificates have been issued based on keys using the RSA algorithm, however a newer and better algorithm uses ECDSA (Elliptic Curve Digital Signature Algorithm) which allows the use of smaller keys that demonstrate better performance than their RSA counterparts. Looking at the results of our crawl we still see a large % of the web using RSA.

    @@ -3260,10 +3596,14 @@

    Forward secrecy

    -

    Forward secrecy is a property of some key exchange mechanisms that secures the connection in such a way that it prevents each connection to a server from being exposed even in case of a future compromise of the server's private key. This is well understood within the security community as desirable on all TLS connections to safeguard the security of those connections. It was introduced as an optional configuration in 2008 with TLSv1.2 and has become mandatory in 2018 with TLSv1.3 requiring the use of Forward Secrecy.

    +

    + Forward secrecyhttps://en.wikipedia.org/wiki/Forward_secrecy is a property of some key exchange mechanisms that secures the connection in such a way that it prevents each connection to a server from being exposed even in case of a future compromise of the server's private key. This is well understood within the security community as desirable on all TLS connections to safeguard the security of those connections. It was introduced as an optional configuration in 2008 with TLSv1.2 and has become mandatory in 2018 with TLSv1.3 requiring the use of Forward Secrecy. +

    Looking at the % of TLS requests that provide Forward Secrecy, we can see that support is tremendous. 96.92% of Desktop and 96.49% of mobile requests use Forward secrecy. We'd expect that the continuing increase in the adoption of TLSv1.3 will further increase these numbers.

    Cipher suites

    -

    TLS allows the use of various cipher suites - some newer and more secure, and some older and insecure. Traditionally newer TLS versions have added cipher suites but have been reluctant to remove older cipher suites. TLSv1.3 aims to simplify this by offering a reduced set of ciphers suites and will not permit the older, insecure, cipher suites to be used. Tools like SSL Labs allow the TLS setup of a website (including the cipher suites supported and their preferred order) to be easily seen, which helps drive better configurations. We can see that the majority of cipher suites negotiated for TLS requests were indeed excellent:

    +

    + TLS allows the use of various cipher suites - some newer and more secure, and some older and insecure. Traditionally newer TLS versions have added cipher suites but have been reluctant to remove older cipher suites. TLSv1.3 aims to simplify this by offering a reduced set of ciphers suites and will not permit the older, insecure, cipher suites to be used. Tools like SSL Labshttps://www.ssllabs.com/ allow the TLS setup of a website (including the cipher suites supported and their preferred order) to be easily seen, which helps drive better configurations. We can see that the majority of cipher suites negotiated for TLS requests were indeed excellent: +

    @@ -3312,8 +3652,14 @@

    Figure 6. Cipher suite usage used.

    -

    It is positive to see such wide stream use of GCM ciphers since the older CBC ciphers are less secure. CHACHA20_POLY1305 is still an niche cipher suite, and we even still have a very small use of the insecure 3DES ciphers.

    -

    It should be noticed that these were the cipher suites used for the crawl using Chrome, but sites will likely also support other cipher suites as well for older browsers. Other sources, for example SSL Pulse, can provide more detail on the range of all cipher suites and protocols supported.

    +

    + It is positive to see such wide stream use of GCM ciphers since the older CBC ciphers are less secure. CHACHA20_POLY1305https://blog.cloudflare.com/it-takes-two-to-chacha-poly/ is still an niche cipher suite, and we even still have a very small use of the insecure 3DES ciphershttps://en.wikipedia.org/wiki/Triple_DES#Security. +

    +

    + It should be noticed that these were the cipher suites used for the crawl using Chrome, but sites will likely also support other cipher suites as well for older browsers. Other sources, for example SSL Pulsehttps://www.ssllabs.com/ssl-pulse/, can provide more detail on the range of all cipher suites and protocols supported. +

    Mixed content

    Most sites on the web originally existed as HTTP websites and have had to migrate their site to HTTPS. This 'lift and shift' operation can be difficult and sometimes things get missed or left behind. This results in sites having mixed content, where their pages load over HTTPS but something on the page, perhaps an image or a style, is loaded over HTTP. Mixed content is bad for security and privacy and can be difficult to find and fix.

    @@ -3345,18 +3691,24 @@

    Figure 7. Mixed content usage.

    We can see that around 20% of sites across mobile (645,485 sites) and desktop (594,072 sites) present some form of mixed content. Whilst passive mixed content, something like an image, is less dangerous, we can still see that almost a quarter of sites with mixed content have active mixed content. Active mixed content, like JavaScript, is more dangerous as an attacker can insert their own hostile code into a page easily.

    -

    In the past web browsers have allowed passive mixed content and flagged it with a warning but blocked active mixed content. More recently however, Chrome announced it intends to improve here and as HTTPS becomes the norm it will block all mixed content instead.

    +

    + In the past web browsers have allowed passive mixed content and flagged it with a warning but blocked active mixed content. More recently however, Chrome announcedhttps://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html it intends to improve here and as HTTPS becomes the norm it will block all mixed content instead. +

    Security headers

    -

    Many new and recent features for site operators to better protect their users have come in the form of new HTTP response headers that can configure and control security protections built into the browser. Some of these features are easy to enable and provide a huge level of protection whilst others require a little more work from site operators. If you wish to check if a site is using these headers and has them correctly configured, you can use the Security Headers tool to scan it.

    +

    + Many new and recent features for site operators to better protect their users have come in the form of new HTTP response headers that can configure and control security protections built into the browser. Some of these features are easy to enable and provide a huge level of protection whilst others require a little more work from site operators. If you wish to check if a site is using these headers and has them correctly configured, you can use the Security Headershttps://securityheaders.com/ tool to scan it. +

    - Figure 8. Usage of Security Headers + Figure 8. Usage of Security Headers
    Figure 8. Usage of Security Headers

    HTTP Strict Transport Security

    -

    The HSTS header allows a website to instruct a browser that it should only ever communicate with the site over a secure HTTPS connection. This means that any attempts to use a http:// URL will automatically be converted to https:// before a request is made. Given that over 40% of requests were capable of using TLS, we see a much lower % of requests instructing the browser to require it.

    +

    + The HSTShttps://tools.ietf.org/html/rfc6797 header allows a website to instruct a browser that it should only ever communicate with the site over a secure HTTPS connection. This means that any attempts to use a http:// URL will automatically be converted to https:// before a request is made. Given that over 40% of requests were capable of using TLS, we see a much lower % of requests instructing the browser to require it. +

    @@ -3440,26 +3792,39 @@

    Figure 10. Medium values of HSTS `max-age` policy by percentile.

    HSTS preloading

    -

    With the HSTS policy delivered via an HTTP response Header, when visiting a site for the first time a browser will not know whether a policy is configured. To avoid this Trust On First Use problem, a site operator can have the policy preloaded into the browser (or other user agents) meaning you are protected even before you visit the site for the first time.

    -

    There are a number of requirements for preloading, which are outlined on the HSTS preload site. We can see that only a small number of sites, 0.31% on desktop and 0.26% on mobile, are eligible according to current criteria. Sites should ensure they have fully transitions all sites under their domain to HTTPS before submitting to preload the domain or they risk blocking access to HTTP-only sites.

    +

    + With the HSTS policy delivered via an HTTP response Header, when visiting a site for the first time a browser will not know whether a policy is configured. To avoid this Trust On First Usehttps://en.wikipedia.org/wiki/Trust_on_first_use problem, a site operator can have the policy preloaded into the browser (or other user agents) meaning you are protected even before you visit the site for the first time. +

    +

    + There are a number of requirements for preloading, which are outlined on the HSTS preloadhttps://hstspreload.org/ site. We can see that only a small number of sites, 0.31% on desktop and 0.26% on mobile, are eligible according to current criteria. Sites should ensure they have fully transitions all sites under their domain to HTTPS before submitting to preload the domain or they risk blocking access to HTTP-only sites. +

    Content Security Policy

    -

    Web applications face frequent attacks where hostile content finds its way into a page. The most worrisome form of content is JavaScript and when an attacker finds a way to insert JavaScript into a page, they can launch damaging attacks. These attacks are known as Cross-Site Scripting (XSS) and Content Security Policy (CSP) provides an effective defense against these attacks.

    +

    + Web applications face frequent attacks where hostile content finds its way into a page. The most worrisome form of content is JavaScript and when an attacker finds a way to insert JavaScript into a page, they can launch damaging attacks. These attacks are known as Cross-Site Scripting (XSS)https://en.wikipedia.org/wiki/Cross-site_scripting and Content Security Policy (CSP)https://www.w3.org/TR/CSP2/ provides an effective defense against these attacks. +

    CSP is an HTTP header (Content-Security-Policy) published by a website which tells the browser rules around content allowed on a site. If additional content is injected into the site due to a security flaw, and it is not allowed by the policy, the browser will block it from being used. Alongside XSS protection, CSP also offers several other key benefits such as making migration to HTTPS easier.

    -

    Despite the many benefits of CSP, it can be complicated to implement on websites since its very purpose is to limit what is acceptable on a page. The policy must allow all content and resources you need and can easily get large and complex. Tools like Report URI can help you analyze and build the appropriate policy.

    +

    + Despite the many benefits of CSP, it can be complicated to implement on websites since its very purpose is to limit what is acceptable on a page. The policy must allow all content and resources you need and can easily get large and complex. Tools like Report URIhttps://report-uri.com/ can help you analyze and build the appropriate policy. +

    We find that only 5.51% of desktop pages include a CSP and only 4.73% of mobile pages include a CSP, likely due to the complexity of deployment.

    Hash/nonce

    -

    A common approach to CSP is to create a whitelist of 3rd party domains that are permitted to load content, such as JavaScript, into your pages. Creating and managing these whitelists can be difficult so hashes and nonces were introduced as an alternative approach. A hash is calculated based on contents of the script so if this is published by the website operator and the script is changed, or another script is added, then it will not match the hash and will be blocked. A nonce is a one-time code (which should be changed each time the page is loaded to prevent it being guessed) which is allowed by the CSP and which the script is tagged with. You can see an example of a nonce on this page by viewing the source to see how Google Tag Manager is loaded.

    +

    + A common approach to CSP is to create a whitelist of 3rd party domains that are permitted to load content, such as JavaScript, into your pages. Creating and managing these whitelists can be difficult so hasheshttps://www.w3.org/TR/CSP2/#source-list-valid-hashes and nonceshttps://www.w3.org/TR/CSP2/#source-list-valid-nonces were introduced as an alternative approach. A hash is calculated based on contents of the script so if this is published by the website operator and the script is changed, or another script is added, then it will not match the hash and will be blocked. A nonce is a one-time code (which should be changed each time the page is loaded to prevent it being guessed) which is allowed by the CSP and which the script is tagged with. You can see an example of a nonce on this page by viewing the source to see how Google Tag Manager is loaded. +

    Of the sites surveyed only 0.09% of desktop pages use a nonce source and only 0.02% of desktop pages use a hash source. The number of mobile pages use a nonce source is slightly higher at 0.13% but the use of hash sources is lower on mobile pages at 0.01%.

    strict-dynamic

    - The proposal of strict-dynamic in the next iteration of CSP further reduces the burden on site operators for using CSP by allowing a whitelisted script to load further script dependencies. Despite the introduction of this feature, which already has support in some modern browsers, only 0.03% of desktop pages and 0.1% of mobile pages include it in their policy. + The proposal of strict-dynamichttps://www.w3.org/TR/CSP3/#strict-dynamic-usage in the next iteration of CSPhttps://www.w3.org/TR/CSP3/ further reduces the burden on site operators for using CSP by allowing a whitelisted script to load further script dependencies. Despite the introduction of this feature, which already has support in some modern browsershttps://caniuse.com/#feat=mdn-http_headers_csp_content-security-policy_strict-dynamic, only 0.03% of desktop pages and 0.1% of mobile pages include it in their policy.

    trusted-types

    -

    XSS attacks come in various forms and Trusted-Types was created to help specifically with DOM-XSS. Despite being an effective mechanism, our data shows that only 2 mobile and desktop pages use the Trusted-Types directive.

    +

    + XSS attacks come in various forms and Trusted-Typeshttps://github.com/w3c/webappsec-trusted-types was created to help specifically with DOM-XSS. Despite being an effective mechanism, our data shows that only 2 mobile and desktop pages use the Trusted-Types directive. +

    unsafe inline and unsafe-eval

    @@ -3474,13 +3839,18 @@

    frame-ancestors

    -

    Another common attack known as clickjacking is conducted by an attacker who will place a target website inside an iframe on a hostile website, and then overlay hidden controls and buttons that they are in control of. Whilst the X-Frame-Options header (discussed below) originally set out to control framing, it wasn't flexible and frame-ancestors in CSP stepped in to provide a more flexible solution. Site operators can now specify a list of hosts that are permitted to frame them and any other hosts attempting to frame them will be prevented.

    +

    + Another common attack known as clickjackinghttps://en.wikipedia.org/wiki/Clickjacking is conducted by an attacker who will place a target website inside an iframe on a hostile website, and then overlay hidden controls and buttons that they are in control of. Whilst the X-Frame-Options header (discussed below) originally set out to control framing, it wasn't flexible and frame-ancestors in CSP stepped in to provide a more flexible solution. Site operators can now specify a list of hosts that are permitted to frame them and any other hosts attempting to frame them will be prevented. +

    Of the pages surveyed, 2.85% of desktop pages include the frame-ancestors directive in CSP with 0.74% of desktop pages setting Frame-Ancestors to 'none', preventing any framing, and 0.47% of pages setting frame-ancestors to 'self', allowing only their own site to frame itself. On mobile we see 2.52% of pages using frame-ancestors with 0.71% setting the value of 'none' and 0.41% setting the value to 'self'.

    Referrer Policy

    - The Referrer-Policy header allows a site to control what information will be sent in the Referer header when a user navigates away from the current page. This can be the source of information leakage if there is sensitive data in the URL, such as search queries or other user-dependent information included in URL parameters. By controlling what information is sent in the Referer header, ideally limiting it, a site can protect the privacy of their visitors by reducing the information sent to 3rd parties. + The Referrer-Policyhttps://www.w3.org/TR/referrer-policy/ header allows a site to control what information will be sent in the Referer header when a user navigates away from the current page. This can be the source of information leakage if there is sensitive data in the URL, such as search queries or other user-dependent information included in URL parameters. By controlling what information is sent in the Referer header, ideally limiting it, a site can protect the privacy of their visitors by reducing the information sent to 3rd parties. +

    +

    + Note the Referrer Policy does not follow the Referer header's misspelling which has become a well-known errorhttps://stackoverflow.com/questions/3087626/was-the-misspelling-of-the-http-field-name-referer-intentional.

    -

    Note the Referrer Policy does not follow the Referer header's misspelling which has become a well-known error.

    A total of 3.25% of desktop pages and 2.95% of mobile pages issue a Referrer-Policy header and below we can see the configurations those pages used.

    @@ -3540,10 +3910,13 @@

    Figure 11. Referrer-Policy configuration option usage.

    -

    This table shows the valid values set by pages and that, of the pages which use this header, 99.75% of them on desktop and 96.55% of them on mobile are setting a valid policy. The most popular choice of configuration is no-referrer-when-downgrade which will prevent the Referer header being sent when a user navigates from a HTTPS page to a HTTP page. The second most popular choice is strict-origin-when-cross-origin which prevents any information being sent on a scheme downgrade (HTTPS to HTTP navigation) and when information is sent in the Referer it will only contain the origin of the source and not the full URL (for example https://www.example.com rather than https://www.example.com/page/). Details on the other valid configurations can be found in the Referrer Policy specification, though such a high usage of unsafe-url warrants further investigation but is likely to be a third-party component like analytics or advertisement libraries.

    +

    + This table shows the valid values set by pages and that, of the pages which use this header, 99.75% of them on desktop and 96.55% of them on mobile are setting a valid policy. The most popular choice of configuration is no-referrer-when-downgrade which will prevent the Referer header being sent when a user navigates from a HTTPS page to a HTTP page. The second most popular choice is strict-origin-when-cross-origin which prevents any information being sent on a scheme downgrade (HTTPS to HTTP navigation) and when information is sent in the Referer it will only contain the origin of the source and not the full URL (for example https://www.example.com rather than https://www.example.com/page/). Details on the other valid configurations can be found in the Referrer Policy specificationhttps://www.w3.org/TR/referrer-policy/#referrer-policies, though such a high usage of unsafe-url warrants further investigation but is likely to be a third-party component like analytics or advertisement libraries. +

    Feature Policy

    - As the web platform becomes more powerful and feature rich, attackers can abuse these new APIs in interesting ways. In order to limit misuse of powerful APIs, a site operator can issue a Feature-Policy header to disable features that are not required, preventing them from being abused. + As the web platform becomes more powerful and feature rich, attackers can abuse these new APIs in interesting ways. In order to limit misuse of powerful APIs, a site operator can issue a Feature-Policyhttps://w3c.github.io/webappsec-feature-policy/ header to disable features that are not required, preventing them from being abused.

    Here are the 5 most popular features that are controlled with a Feature Policy.

    @@ -3643,7 +4016,7 @@

    X-Frame-Options

    - The X-Frame-Options header allows a page to control whether or not it can be placed in an iframe by another page. Whilst lacking the flexibility of frame-ancestors in CSP, mentioned above, it was effective if you didn't require fine grained control of framing. + The X-Frame-Optionshttps://tools.ietf.org/html/rfc7034 header allows a page to control whether or not it can be placed in an iframe by another page. Whilst lacking the flexibility of frame-ancestors in CSP, mentioned above, it was effective if you didn't require fine grained control of framing.

    We see that the usage of the X-Frame-Options header is quite high on both desktop (16.99%) and mobile (14.77%) and can also look more closely at the specific configurations used.

    @@ -3679,19 +4052,21 @@

    Figure 14. X-Frame-Options configuration used.
    -

    It seems that the vast majority of pages restrict framing to only their own origin and the next significant approach is to prevent framing altogether. This is similar to frame-ancestors in CSP where these 2 approaches are also the most common. It should also be noted that the allow-from option, which in theory allow site owners to list the third-party domains allowed to frame was never well supported and has been deprecated.

    +

    + It seems that the vast majority of pages restrict framing to only their own origin and the next significant approach is to prevent framing altogether. This is similar to frame-ancestors in CSP where these 2 approaches are also the most common. It should also be noted that the allow-from option, which in theory allow site owners to list the third-party domains allowed to frame was never well supportedhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options#Browser_compatibility and has been deprecated. +

    X-Content-Type-Options

    - The X-Content-Type-Options header is the most widely deployed Security Header and is also the most simple, with only one possible configuration value nosniff. When this header is issued a browser must treat a piece of content as the MIME Type declared in the Content-Type header and not try to change the advertised value when it infers a file is of a different type. Various security flaws can be introduced if a browser is persuaded to incorrectly sniff the type.. + The X-Content-Type-Optionshttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options header is the most widely deployed Security Header and is also the most simple, with only one possible configuration value nosniff. When this header is issued a browser must treat a piece of content as the MIME Type declared in the Content-Type header and not try to change the advertised value when it infers a file is of a different type. Various security flaws can be introduced if a browser is persuaded to incorrectly sniff the type..

    We find that an identical 17.61% of pages on both mobile and desktop issue the X-Content-Type-Options header.

    X-XSS-Protection

    - The X-XSS-Protection header allows a site to control the XSS Auditor or XSS Filter built into a browser, which should in theory provide some XSS protection. + The X-XSS-Protectionhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection header allows a site to control the XSS Auditor or XSS Filter built into a browser, which should in theory provide some XSS protection.

    14.69% of Desktop requests, and 15.2% of mobile requests used the X-XSS-Protection header. Digging into the data we can see what the intention for most site operators was in figure 13.

    @@ -3736,14 +4111,28 @@

    Setting a value of 0 in the header instructs the browser to disable any XSS auditor/filter that it may have. Some historic attacks demonstrated how the auditor or filter could be tricked into assisting an attacker rather than protecting the user so some site operators could disable it if they were confident they have adequate protection against XSS in place.

    Due to these attacks, Edge retired their XSS Filter, Chrome deprecated their XSS Auditor and Firefox never implemented support for the feature. We still see widespread use of the header at approximately 15% of all sites, despite it being largely useless now.

    Report-To

    -

    The Reporting API was introduced to allow site operators to gather various pieces of telemetry from the browser. Many errors or problems on a site can result in a poor experience for the user yet a site operator can only find out if the user contacts them. The Reporting API provides a mechanism for a browser to automatically report these problems without any user interaction or interruption. The Reporting API is configured by delivering the Report-To header.

    -

    By specifying the header, which contains a location where the telemetry should be sent, a browser will automatically begin sending the data and you can use a 3rd party service like Report URI to collect the reports or collect them yourself. Given the ease of deployment and configuration, we can see that only a small fraction of desktop (1.70%) and mobile (1.57%) sites currently enable this feature. To see the kind of telemetry you can collect, refer to the Reporting API specification.

    +

    + The Reporting APIhttps://www.w3.org/TR/reporting/ was introduced to allow site operators to gather various pieces of telemetry from the browserhttps://scotthelme.co.uk/introducing-the-reporting-api-nel-other-major-changes-to-report-uri/. Many errors or problems on a site can result in a poor experience for the user yet a site operator can only find out if the user contacts them. The Reporting API provides a mechanism for a browser to automatically report these problems without any user interaction or interruption. The Reporting API is configured by delivering the Report-To header. +

    +

    + By specifying the header, which contains a location where the telemetry should be sent, a browser will automatically begin sending the data and you can use a 3rd party service like Report URIhttps://report-uri.com/ to collect the reports or collect them yourself. Given the ease of deployment and configuration, we can see that only a small fraction of desktop (1.70%) and mobile (1.57%) sites currently enable this feature. To see the kind of telemetry you can collect, refer to the Reporting API specificationhttps://www.w3.org/TR/reporting/. +

    Network Error Logging

    -

    Network Error Logging (NEL) provides detailed information about various failures in the browser that can result in a site being inoperative. Whereas the Report-To is used to report problems with a page that is loaded, the NEL header allows sites to inform the browser to cache this policy and then to report future connection problems when they happen via the endpoint configured in the Reporting-To header above. NEL can therefore be seen as an extension of the Reporting API.

    +

    + Network Error Logging (NEL)https://www.w3.org/TR/network-error-logging/ provides detailed information about various failures in the browser that can result in a site being inoperative. Whereas the Report-To is used to report problems with a page that is loaded, the NEL header allows sites to inform the browser to cache this policy and then to report future connection problems when they happen via the endpoint configured in the Reporting-To header above. NEL can therefore be seen as an extension of the Reporting API. +

    Of course, with NEL depending on the Reporting API, we shouldn't see the usage of NEL exceed that of the Reporting API, so we see similarly low numbers here too at 1.70% for desktop requests and 1.57% for mobile. The fact these numbers are identical suggest they are being deployed together.

    -

    NEL provides incredibly valuable information and you can read more about the type of information in the Network Error Logging specification.

    +

    + NEL provides incredibly valuable information and you can read more about the type of information in the Network Error Logging specificationhttps://w3c.github.io/network-error-logging/#predefined-network-error-types. +

    Clear Site Data

    -

    With the increasing ability to store data locally on a user's device, via cookies, caches and local storage to name but a few, site operators needed a reliable way to manage this data. The Clear Site Data header provides a means to ensure that all data of a particular type is removed from the device, though it is not yet supported in all browsers.

    +

    + With the increasing ability to store data locally on a user's device, via cookies, caches and local storage to name but a few, site operators needed a reliable way to manage this data. The Clear Site Data header provides a means to ensure that all data of a particular type is removed from the device, though it is not yet supported in all browsershttps://caniuse.com/#feat=mdn-http_headers_clear-site-data. +

    Given the nature of the header, it is unsurprising to see almost no usage reported - just 9 desktop requests and 7 mobile requests. With our data only looking at the homepage of a site, we're unlikely to see the most common use of the header which would be on a logout endpoint. Upon logging out of a site, the site operator would return the Clear Site Data header and the browser would remove all data of the indicated types. This is unlikely to take place on the homepage of a site.

    Cookies

    Cookies have many security protections available and whilst some of those are long standing, and have been available for years, some of them are really quite new have been introduced only in the last couple of years.

    @@ -3758,7 +4147,9 @@

    SameSite

    -

    As a much more recent addition to cookie protections, the SameSite flag is a powerful protection against Cross-Site Request Forgery (CSRF) attacks (often also known as XSRF).

    +

    + As a much more recent addition to cookie protections, the SameSite flag is a powerful protection against Cross-Site Request Forgery (CSRF)https://en.wikipedia.org/wiki/Cross-site_request_forgery attacks (often also known as XSRF). +

    These attacks work by using the fact that browsers will typically include relevant cookies in all requests. Therefore, if you are logged in, and so have cookies set, and then visit a malicious site, it can make a call for an API and the browser will "helpfully" send the cookies. Adding the SameSite attribute to a Cookie, allows a website to inform the browser not to send the cookies when calls are issued from third-party sites and hence the attack fails.

    Being a recently introduced mechanism, the usage of Same-Site cookies is much lower as we would expect at 0.1% of requests on both desktop and mobile. There are use cases when a cookie should be sent cross-site. For example, single sign-on sites implicitly work by setting the cookie along with an authentication token.

    @@ -3795,7 +4186,9 @@

    Figure 16. SameSite configuration usage.

    We can see that of those pages already using Same-Site cookies, more than half of them are using it in strict mode. This is closely followed by sites using Same-Site in lax mode and then a small selection of sites using the value none. This last value is used to opt-out of the upcoming change where browser vendors may implement lax mode by default.

    -

    Because it provides much needed protection against a dangerous attack, there are currently indications that leading browsers could implement this feature by default and enable it on cookies even though the value is not set. If this were to happen the SameSite protection would be enabled, though in its weaker setting of lax mode and not strict mode, as that would likely cause more breakage.

    +

    + Because it provides much needed protection against a dangerous attack, there are currently indications that leading browsers could implement this feature by defaulthttps://blog.chromium.org/2019/10/developers-get-ready-for-new.html and enable it on cookies even though the value is not set. If this were to happen the SameSite protection would be enabled, though in its weaker setting of lax mode and not strict mode, as that would likely cause more breakage. +

    Prefixes

    Another recent addition to cookies are Cookie Prefixes. These use the name of your cookie to add one of two further protections to those already covered. While the above flags can be accidentally unset on cookies, the name will not change so using the name to define security attributes can more reliably enforce them.

    Currently the name of your cookie can be prefixed with either __Secure- or __Host-, with both offering additional security to the cookie.

    @@ -3855,7 +4248,10 @@

    At the same time, gaps in TLS configurations are still fairly common. Over 15% of pages suffer from mixed content issues, resulting in browser warnings, and 4% of sites contain active mixed content, blocked by modern browsers for security reasons. Similarly, the benefits of HTTP Strict Transport Security only extend to a small subset of major sites, and the majority of websites don't enable the most secure HSTS configurations and are not eligible for HSTS preloading. Despite progress in HTTPS adoption, a large number of cookies is still set without the Secure flag; only 4% of homepages that set cookies prevent them from being sent over unencrypted HTTP.

    Defending against common web vulnerabilities

    - Web developers working on sites with sensitive data often enable opt-in web security features to protect their applications from XSS, CSRF, clickjacking, and other common web bugs. These issues can be mitigated by setting a number of standard, broadly supported HTTP response headers, including X-Frame-OptionsXSShttps://en.wikipedia.org/wiki/Cross-site_scripting, CSRFhttps://en.wikipedia.org/wiki/Cross-site_request_forgery, clickjackinghttps://en.wikipedia.org/wiki/Clickjacking, and other common web bugs. These issues can be mitigated by setting a number of standard, broadly supported HTTP response headers, including X-Frame-Options, X-Content-Type-Options, and Content-Security-Policy. @@ -3866,87 +4262,86 @@

    Modern web platform defenses

    In the recent years, web browsers have implemented powerful new mechanisms which offer protections from major classes of vulnerabilities and new web threats; this includes Subresource Integrity, SameSite cookies, and cookie prefixes.

    -

    These features have seen adoption only by a relatively small number of websites; their total coverage is generally well below 1%. The even more recent security mechanisms such as Trusted Types, Cross-Origin Resource Policy or Cross-Origin-Opener Policy have not seen any widespread adoption as of yet.

    +

    + These features have seen adoption only by a relatively small number of websites; their total coverage is generally well below 1%. The even more recent security mechanisms such as Trusted Typeshttps://w3c.github.io/webappsec-trusted-types/dist/spec/, Cross-Origin Resource Policyhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP) or Cross-Origin-Opener Policyhttps://www.chromestatus.com/feature/5432089535053824 have not seen any widespread adoption as of yet. +

    Similarly, convenience features such as the Reporting API, Network Error Logging and the Clear-Site-Data header are also still in their infancy and are currently being used by a small number of sites.

    Tying it all together

    At web scale, the total coverage of opt-in platform security features is currently relatively low. Even the most broadly adopted protections are enabled by less than a quarter of websites, leaving the majority of the web without platform safeguards against common security issues; more recent security mechanisms, such as Content Security Policy or Referrer Policy, are enabled by less than 5% of websites.

    -

    It is important to note, however, that the adoption of these mechanisms is skewed towards larger web applications which frequently handle more sensitive user data. The developers of these sites more frequently invest in improving their web defenses, including enabling a range of protections against common vulnerabilities; tools such as Mozilla Observatory and Security Headers can provide a useful checklist of web available security features.

    +

    + It is important to note, however, that the adoption of these mechanisms is skewed towards larger web applications which frequently handle more sensitive user data. The developers of these sites more frequently invest in improving their web defenses, including enabling a range of protections against common vulnerabilities; tools such as Mozilla Observatoryhttps://observatory.mozilla.org/ and Security Headershttps://securityheaders.com/ can provide a useful checklist of web available security features. +

    If your web application handles sensitive user data, consider enabling the security mechanisms outlined in this section to protect your users and make the web safer.

    -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":9,"title":"Accessibility","description":"Accessibility chapter of the 2019 Web Almanac covering ease of reading, media, ease of navigation, and compatibility with assistive technologies.","authors":["nektarios-paisios","obto","kleinab"],"reviewers":["ljme"],"translators":null,"discuss":"1764","results":"https://docs.google.com/spreadsheets/d/16JGy-ehf4taU0w4ABiKjsHGEXNDXxOlb__idY8ifUtQ/","queries":"09_Accessibility","published":"2019-11-11","last_updated":"2020-03-02","chapter":"accessibility"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 9 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Accessibility +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":9,"title":"Accessibility","description":"Accessibility chapter of the 2019 Web Almanac covering ease of reading, media, ease of navigation, and compatibility with assistive technologies.","authors":["nektarios-paisios","obto","kleinab"],"reviewers":["ljme"],"translators":null,"discuss":"1764","results":"https://docs.google.com/spreadsheets/d/16JGy-ehf4taU0w4ABiKjsHGEXNDXxOlb__idY8ifUtQ/","queries":"09_Accessibility","published":"2019-11-11","last_updated":"2020-03-02","chapter":"accessibility"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -3955,27 +4350,35 @@

    - + -
    {{ self.written_by_before() }} Nektarios Paisios, David Fox, {{ self.and() }} Abigail Klein{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Laura Eberly{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Accessibility on the web is essential for an inclusive and equitable society. As more of our social and work lives move to the online world, it becomes even more important for people with disabilities to be able to participate in all online interactions without barriers. Just as building architects can create or omit accessibility features such as wheelchair ramps, web developers can help or hinder the assistive technology users rely on.

    When thinking about users with disabilities, we should remember that their user journeys are often the same—they just use different tools. These popular tools include but are not limited to: screen readers, screen magnifiers, browser or text size zooming, and voice controls.

    Often, improving the accessibility of your site has benefits for everyone. While we typically think of people with disabilities as people with a permanent disability, anybody can have a temporary or situational disability. For example, someone might be permanently blind, have a temporary eye infection, or, situationally, be outside under a glaring sun. All of these might explain why someone is unable to see their screen. Everyone has situational disabilities, and so improving the accessibility of your web page will improve the experience of all users in any situation.

    -

    The Web Content Accessibility Guidelines (WCAG) advise on how to make a website accessible. These guidelines were used as the basis for our analysis. However, in many cases it is difficult to programmatically analyze the accessibility of a website. For instance, the web platform provides several ways of achieving similar functional results, but the underlying code powering them may be completely different. Therefore, our analysis is just an approximation of overall web accessibility.

    +

    + The Web Content Accessibility Guidelineshttps://www.w3.org/WAI/WCAG21/quickref/ (WCAG) advise on how to make a website accessible. These guidelines were used as the basis for our analysis. However, in many cases it is difficult to programmatically analyze the accessibility of a website. For instance, the web platform provides several ways of achieving similar functional results, but the underlying code powering them may be completely different. Therefore, our analysis is just an approximation of overall web accessibility. +

    We've split up our most interesting insights into four categories: ease of reading, media on the web, ease of page navigation, and compatibility with assistive technologies.

    No significant difference in accessibility was found between desktop and mobile during testing. As a result, all of our presented metrics are the result of our desktop analysis unless otherwise stated.

    Ease of reading

    The primary goal of a web page is to deliver content users want to engage with. This content might be a video or an assortment of images, but many times, it's simply the text on the page. It's extremely important that our textual content is legible to our readers. If visitors can't read a web page, they can't engage with it, which ends up with them leaving. In this section we'll look at three areas in which sites struggled.

    Color contrast

    -

    There are many cases where visitors to your site may not be able see it perfectly. Visitors may be colorblind and unable to distinguish between the font and background color (1 in every 12 men and 1 in 200 women of European descent). Perhaps they're simply reading while the sun is out and creating tons of glare on their screen—significantly impairing their vision. Or maybe they've just grown older and their eyes can't distinguish colors as well as they used to.

    +

    + There are many cases where visitors to your site may not be able see it perfectly. Visitors may be colorblind and unable to distinguish between the font and background color (1 in every 12 men and 1 in 200 womenhttp://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf of European descent). Perhaps they're simply reading while the sun is out and creating tons of glare on their screen—significantly impairing their vision. Or maybe they've just grown older and their eyes can't distinguish colors as well as they used to. +

    In order to make sure your website is readable under these conditions, making sure your text has sufficient color contrast with its background is critical.

    - Figure 1. Example of what text with insufficient color contrast looks like. Courtesy of LookZook + Figure 1. Example of what text with insufficient color contrast looks like. Courtesy of LookZook
    Figure 1. Example of what text with insufficient color contrast looks like. Courtesy of LookZook
    @@ -3983,9 +4386,14 @@

    Only 22.04% of sites gave all of their text sufficient color contrast. Or in other words: 4 out of every 5 sites have text which easily blends into the background, making it unreadable.

    Note that we weren't able to analyze any text inside of images, so our reported metric is an upper-bound of the total number of websites passing the color contrast test.

    Zooming and scaling pages

    -

    Using a legible font size and target size helps users read and interact with your website. But even websites perfectly following all of these guidelines can't meet the specific needs of each visitor. This is why device features like pinch-to-zoom and scaling are so important: they allow users to tweak your pages so their needs are met. Or in the case of particularly inaccessible sites using tiny fonts and buttons, it gives users the chance to even use the site.

    +

    + Using a legible font sizehttps://accessibleweb.com/question-answer/minimum-font-size/ and target sizehttps://www.w3.org/WAI/WCAG21/quickref/#target-size helps users read and interact with your website. But even websites perfectly following all of these guidelines can't meet the specific needs of each visitor. This is why device features like pinch-to-zoom and scaling are so important: they allow users to tweak your pages so their needs are met. Or in the case of particularly inaccessible sites using tiny fonts and buttons, it gives users the chance to even use the site. +

    There are rare cases when disabling scaling is acceptable, like when the page in question is a web-based game using touch controls. If left enabled in this case, players' phones will zoom in and out every time the player taps twice on the game, ironically making it inaccessible.

    -

    Because of this, developers are given the ability to disable this feature by setting one of the following two properties in the meta viewport tag:

    +

    + Because of this, developers are given the ability to disable this feature by setting one of the following two properties in the meta viewport taghttps://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag: +

    1. user-scalable set to 0 or no

      @@ -3994,10 +4402,13 @@

      ignores the tag. All sites, no matter what, can be zoomed and scaled on newer iOS devices.

      +

      + Sadly, developers have misused this so much that almost one out of every three sites on mobile (32.21%) disable this feature, and Apple (as of iOS 10) no longer allows web-developers to disable zooming. Mobile Safari simply ignores the taghttps://archive.org/details/ios-10-beta-release-notes. All sites, no matter what, can be zoomed and scaled on newer iOS devices. +

      - Figure 2. Percentage of sites that disable zooming and scaling vs device type. + Figure 2. Percentage of sites that disable zooming and scaling vs device type.
      Figure 2. Percentage of sites that disable zooming and scaling vs device type.
      @@ -4005,24 +4416,28 @@

      Language identification

      The web is full of wondrous amounts of content. However, there's a catch: over 1,000 different languages exist in the world, and the content you're looking for may not be written in one you are fluent in. In recent years, we've made great strides in translation technologies and you probably have used one of them on the web (e.g., Google translate).

      - In order to facilitate this feature, the translation engines need to know what language your pages are written in. This is done by using the lang attribute. Without this, computers must guess what language your page is written in. As you might imagine, this leads to many errors, especially when pages use multiple languages (e.g., your page navigation is in English, but the post content is in Japanese). + In order to facilitate this feature, the translation engines need to know what language your pages are written in. This is done by using the lang attributehttps://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang. Without this, computers must guess what language your page is written in. As you might imagine, this leads to many errors, especially when pages use multiple languages (e.g., your page navigation is in English, but the post content is in Japanese).

      This problem is even more pronounced on text-to-speech assistive technologies like screen readers, where if no language has been specified, they tend to read the text in the default user language.

      Of the pages analyzed, 26.13% do not specify a language with the lang attribute. This leaves over a quarter of pages susceptible to all of the problems described above. The good news? Of sites using the lang attribute, they specify a valid language code correctly 99.68% of the time.

      Distracting content

      Some users, such as those with cognitive disabilities, have difficulties concentrating on the same task for long periods of time. These users don't want to deal with pages that include lots of motion and animations, especially when these effects are purely cosmetic and not related to the task at hand. At a minimum, these users need a way to turn all distracting animations off.

      - Unfortunately, our findings indicate that infinitely looping animations are quite common on the web, with 21.04% of pages using them through infinite CSS animations or <marquee> and <blink> elements. + Unfortunately, our findings indicate that infinitely looping animations are quite common on the web, with 21.04% of pages using them through infinite CSS animations or <marquee>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/marquee and <blink>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/blink elements.

      It is interesting to note however, that the bulk of this problem appears to be a few popular third-party stylesheets which include infinitely looping CSS animations by default. We were unable to determine how many pages actually used these animation styles.

      Media on the web

      Alternative text on images

      -

      Images are an essential part of the web experience. They can tell powerful stories, grab attention, and elicit emotion. But not everyone can see these images that we rely on to tell parts of our stories. Thankfully, in 1995, HTML 2.0 provided a solution to this problem: the alt attribute. The alt attribute provides web developers with the capability of adding a textual description to the images we use, so that when someone is unable to see our images (or the images are unable to load), they can read the alt text for a description. The alt text fills them in on the part of the story they would have otherwise missed.

      +

      + Images are an essential part of the web experience. They can tell powerful stories, grab attention, and elicit emotion. But not everyone can see these images that we rely on to tell parts of our stories. Thankfully, in 1995, HTML 2.0 provided a solution to this problem: the alt attributehttps://webaim.org/techniques/alttext/. The alt attribute provides web developers with the capability of adding a textual description to the images we use, so that when someone is unable to see our images (or the images are unable to load), they can read the alt text for a description. The alt text fills them in on the part of the story they would have otherwise missed. +

      Even though alt attributes have been around for 25 years, 49.91% of pages still fail to provide alt attributes for some of their images, and 8.68% of pages never use them at all.

      Captions for audio and video

      Just as images are powerful storytellers, so too are audio and video in grabbing attention and expressing ideas. When audio and video content is not captioned, users who cannot hear this content miss out on large portions of the web. One of the most common things we hear from users who are Deaf or hard of hearing is the need to include captions for all audio and video content.

      - Of sites using <audio> or <video> elements, only 0.54% provide captions (as measured by those that include the <track> element). Note that some websites have custom solutions for providing video and audio captions to users. We were unable to detect these and thus the true percentage of sites utilizing captions is slightly higher. + Of sites using <audio>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio or <video>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video elements, only 0.54% provide captions (as measured by those that include the <track>https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video element). Note that some websites have custom solutions for providing video and audio captions to users. We were unable to detect these and thus the true percentage of sites utilizing captions is slightly higher.

      Ease of page navigation

      When you open the menu in a restaurant, the first thing you probably do is read all of the section headers: appetizers, salads, main course, and dessert. This allows you to scan a menu for all of the options and jump quickly to the dishes most interesting to you. Similarly, when a visitor opens a web page, their goal is to find the information they are most interested in—the reason they came to the page in the first place. In order to help users find their desired content as fast as possible (and prevent them from hitting the back button), we try to separate the contents of our pages into several visually distinct sections, for example: a site header for navigation, various headings in our articles so users can quickly scan them, a footer for other extraneous resources, and more.

      @@ -4038,17 +4453,19 @@

      - Figure 3. Popularity of heading levels. + Figure 3. Popularity of heading levels.
      Figure 3. Popularity of heading levels.

      Main landmark

      -

      A main landmark indicates to screen readers where the main content of a web page starts so users can jump right to it. Without this, screen reader users have to manually skip over your navigation every single time they go to a new page within your site. Obviously, this is rather frustrating.

      +

      + A main landmarkhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Main_role indicates to screen readers where the main content of a web page starts so users can jump right to it. Without this, screen reader users have to manually skip over your navigation every single time they go to a new page within your site. Obviously, this is rather frustrating. +

      We found only one in every four pages (26.03%) include a main landmark. And surprisingly, 8.06% of pages erroneously contained more than one main landmark, leaving these users guessing which landmark contains the actual main content.

      - Figure 4. Percent of pages by their number of 'main' landmarks. + Figure 4. Percent of pages by their number of 'main' landmarks.
      Figure 4. Percent of pages by their number of "main" landmarks.
      @@ -4056,20 +4473,20 @@

      HTML section elements

      Since HTML5 was released in 2008, and made the official standard in 2014, there are many HTML elements to aid computers and screen readers in understanding our page layout and structure.

      - Elements like <header>, <footer>, <navigation>, and <main> indicate where specific types of content live and allow users to quickly jump around your page. These are being used widely across the web, with most of them being used on over 50% of pages (<main> being the outlier). + Elements like <header>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/header, <footer>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/footer, <navigation>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nav, and <main>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/main indicate where specific types of content live and allow users to quickly jump around your page. These are being used widely across the web, with most of them being used on over 50% of pages (<main> being the outlier).

      - Others like <article>, <hr>, and <aside> aid readers in understanding a page's main content. For example, <article> says where one article ends and another begins. These elements are not used nearly as much, with each sitting at around 20% usage. Not all of these belong on every web page, so this isn't necessarily an alarming statistic. + Others like <article>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article, <hr>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hr, and <aside>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside aid readers in understanding a page's main content. For example, <article> says where one article ends and another begins. These elements are not used nearly as much, with each sitting at around 20% usage. Not all of these belong on every web page, so this isn't necessarily an alarming statistic.

      All of these elements are primarily designed for accessibility support and have no visual effect, which means you can safely replace existing elements with them and suffer no unintended consequences.

      - Figure 5. Usage of various HTML semantic elements. + Figure 5. Usage of various HTML semantic elements.
      Figure 5. Usage of various HTML semantic elements.
      @@ -4078,33 +4495,38 @@

      - Figure 6. Other HTML elements used for navigation + Figure 6. Other HTML elements used for navigation
      Figure 6. Other HTML elements used for navigation.

      -

      A skip link is a link placed at the top of a page which allows screen readers or keyboard-only users to jump straight to the main content. It effectively "skips" over all navigational links and menus at the top of the page. Skip links are especially useful to keyboard users who don't use a screen reader, as these users don't usually have access to other modes of quick navigation (like landmarks and headings). 14.19% of the pages in our sample were found to have skip links.

      +

      + A skip linkhttps://webaim.org/techniques/skipnav/ is a link placed at the top of a page which allows screen readers or keyboard-only users to jump straight to the main content. It effectively "skips" over all navigational links and menus at the top of the page. Skip links are especially useful to keyboard users who don't use a screen reader, as these users don't usually have access to other modes of quick navigation (like landmarks and headings). 14.19% of the pages in our sample were found to have skip links. +

      If you'd like to see a skip link in action for yourself, you can! Just do a quick Google search and hit "tab" as soon as you land on the search result pages. You'll be greeted with a previously hidden link just like the one in Figure 7.

      - Figure 7. What a skip link looks like on google.com. + Figure 7. What a skip link looks like on google.com.
      Figure 7. What a skip link looks like on google.com.
      -

      In fact you don't need to even leave this site as we use them here too!

      +

      + In fact you don't need to even leave this site as we use them here toohttps://github.com/HTTPArchive/almanac.httparchive.org/pull/645! +

      It's hard to accurately determine what a skip link is when analyzing sites. For this analysis, if we found an anchor link (href=#heading1) within the first 3 links on the page, we defined this as a page with a skip link. So 14.19% is a strict upper bound.

      Shortcuts

      - Shortcut keys set via the aria-keyshortcuts or accesskey attributes can be used in one of two ways: + Shortcut keys set via the aria-keyshortcutshttps://www.w3.org/TR/wai-aria-1.1/#aria-keyshortcuts or accesskeyhttps://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey attributes can be used in one of two ways:

      1. Activating an element on the page, like a link or button.

      2. Giving a certain element on the page focus. For example, shifting focus to a certain input on the page, allowing a user to then start typing into it.

      - Adoption of aria-keyshortcuts was almost absent from our sample, with it only being used on 159 sites out of over 4 million analyzed. The accesskey attribute was used more frequently, being found on 2.47% of web pages (1.74% on mobile). We believe the higher usage of shortcuts on desktop is due to developers expecting mobile sites to only be accessed via a touch screen and not a keyboard. + Adoption of aria-keyshortcutshttps://www.w3.org/TR/wai-aria-1.1/#aria-keyshortcuts was almost absent from our sample, with it only being used on 159 sites out of over 4 million analyzed. The accesskeyhttps://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey attribute was used more frequently, being found on 2.47% of web pages (1.74% on mobile). We believe the higher usage of shortcuts on desktop is due to developers expecting mobile sites to only be accessed via a touch screen and not a keyboard.

      What is especially surprising here is 15.56% of mobile and 13.03% of desktop sites which use shortcut keys assign the same shortcut to multiple different elements. This means browsers have to guess which element should own this shortcut key.

      Tables

      @@ -4112,22 +4534,24 @@

      Headings

      Depending on the way a particular table is structured, the use of table headers makes it easier to read across columns or rows without losing context on what data that particular column or row refers to. Having to navigate a table lacking in header rows or columns is a subpar experience for a screen reader user. This is because it's hard for a screen reader user to keep track of their place in a table absent of headers, especially when the table is quite large.

      - To mark up table headers, simply use the <th> tag (instead of <td>), or either of the ARIA columnheader or rowheader roles. Only 24.5% of pages with tables were found to markup their tables with either of these methods. So the three quarters of pages choosing to include tables without headers are creating serious challenges for screen reader users. + To mark up table headers, simply use the <th>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/th tag (instead of <td>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/td), or either of the ARIA columnheaderhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Table_Role or rowheaderhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Table_Role roles. Only 24.5% of pages with tables were found to markup their tables with either of these methods. So the three quarters of pages choosing to include tables without headers are creating serious challenges for screen reader users.

      Using <th> and <td> was by far the most commonly used method for marking up table headers. The use of columnheader and rowheader roles was almost non-existent with only 677 total sites using them (0.058%).

      Captions

      - Table captions via the <caption> element are helpful in providing more context for readers of all kinds. A caption can prepare a reader to take in the information your table is sharing, and it can be especially useful for people who may get distracted or interrupted easily. They are also useful for people who may lose their place within a large table, such as a screen reader user or someone with a learning or intellectual disability. The easier you can make it for readers to understand what they're analyzing, the better. + Table captions via the <caption>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/caption element are helpful in providing more context for readers of all kinds. A caption can prepare a reader to take in the information your table is sharing, and it can be especially useful for people who may get distracted or interrupted easily. They are also useful for people who may lose their place within a large table, such as a screen reader user or someone with a learning or intellectual disability. The easier you can make it for readers to understand what they're analyzing, the better.

      Despite this, only 4.32% of pages with tables provide captions.

      Compatibility with assistive technologies

      The use of ARIA

      -

      One of the most popular and widely used specifications for accessibility on the web is the Accessible Rich Internet Applications (ARIA) standard. This standard offers a large array of additional HTML attributes to help convey the purpose behind visual elements (i.e., their semantic meaning), and what kinds of actions they're capable of.

      +

      + One of the most popular and widely used specifications for accessibility on the web is the Accessible Rich Internet Applicationshttps://www.w3.org/WAI/standards-guidelines/aria/ (ARIA) standard. This standard offers a large array of additional HTML attributes to help convey the purpose behind visual elements (i.e., their semantic meaning), and what kinds of actions they're capable of. +

      Using ARIA correctly and appropriately can be challenging. For example, of pages making use of ARIA attributes, we found 12.31% have invalid values assigned to their attributes. This is problematic because any mistake in the use of an ARIA attribute has no visual effect on the page. Some of these errors can be detected by using an automated validation tool, but generally they require hands-on use of real assistive software (like a screen reader). This section will examine how ARIA is used on the web, and specifically which parts of the standard are most prevalent.

      - Figure 8. Percent of total pages vs ARIA attribute. + Figure 8. Percent of total pages vs ARIA attribute.
      Figure 8. Percent of total pages vs ARIA attribute.
      @@ -4139,7 +4563,7 @@

      Currently, 46.91% of pages use at least one ARIA role attribute. In Figure 9 below, we've compiled a list of the top ten most widely used ARIA role values.

      - Figure 9. Top 10 aria roles. + Figure 9. Top 10 aria roles.
      Figure 9. Top 10 aria roles.
      @@ -4150,27 +4574,34 @@
      posinset and setsize attributes were only used on 0.01% of pages. These attributes convey to a screen reader user how many items are in a list or menu and which item is currently selected. So, if a visually impaired user is trying to navigate through a menu, they might hear index announcements like: "Home, 1 of 5", "Products, 2 of 5", "Downloads, 3 of 5", etc.

      Many sites attempt to make dialogs accessible
      -

      The relative popularity of the dialog role stands out because making dialogs accessible for screen reader users is very challenging. It is therefore exciting to see around 8% of the analyzed pages stepping up to the challenge. Again, we suspect this might be due to the use of some UI frameworks.

      +

      + The relative popularity of the dialog rolehttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role stands out because making dialogs accessible for screen reader users is very challenging. It is therefore exciting to see around 8% of the analyzed pages stepping up to the challenge. Again, we suspect this might be due to the use of some UI frameworks. +

      Labels on interactive elements

      The most common way that a user interacts with a website is through its controls, such as links or buttons to navigate the website. However, many times screen reader users are unable to tell what action a control will perform once activated. Often the reason this confusion occurs is due to the lack of a textual label. For example, a button displaying a left-pointing arrow icon to signify it's the "Back" button, but containing no actual text.

      Only about a quarter (24.39%) of pages that use buttons or links include textual labels with these controls. If a control is not labeled, a screen reader user might read something generic, such as the word "button" instead of a meaningful word like "Search".

      Buttons and links are almost always included in the tab order and thus have extremely high visibility. Navigating through a website using the tab key is one of the primary ways through which users who use only the keyboard explore your website. So a user is sure to encounter your unlabeled buttons and links if they are moving through your website using the tab key.

      Accessibility of Form Controls

      - Filling out forms is a task many of us do every single day. Whether we're shopping, booking travel, or applying for a job, forms are the main way users share information with web pages. Because of this, ensuring your forms are accessible is incredibly important. The simplest means of accomplishing this is by providing labels (via the <label> element, aria-label or aria-labelledby<label> elementhttps://developer.mozilla.org/en-US/docs/Web/HTML/Element/label, aria-labelhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute or aria-labelledbyhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute) for each of your inputs. Sadly, only 22.33% of pages provide labels for all their form inputs, meaning 4 out of every 5 pages have forms that may be very difficult to fill out.

      Indicators of required and invalid fields

      -

      When we come across a field with a big red asterisk next to it, we know it's a required field. Or when we hit submit and are informed there were invalid inputs, anything highlighted in a different color needs to be corrected and then resubmitted. However, people with low or no vision cannot rely on these visual cues, which is why the HTML input attributes required, aria-required, and aria-invalid are so important. They provide screen readers with the equivalent of red asterisks and red highlighted fields. As a nice bonus, when you inform browsers what fields are required, they'll validate parts of your forms for you. No JavaScript required.

      +

      + When we come across a field with a big red asterisk next to it, we know it's a required field. Or when we hit submit and are informed there were invalid inputs, anything highlighted in a different color needs to be corrected and then resubmitted. However, people with low or no vision cannot rely on these visual cues, which is why the HTML input attributes required, aria-required, and aria-invalid are so important. They provide screen readers with the equivalent of red asterisks and red highlighted fields. As a nice bonus, when you inform browsers what fields are required, they'll validate parts of your formshttps://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation for you. No JavaScript required. +

      Of pages using forms, 21.73% use required or aria-required when marking up required fields. Only one in every five sites make use of this. This is a simple step to make your site accessible, and unlocks helpful browser features for all users.

      We also found 3.52% of sites with forms make use of aria-invalid. However, since many forms only make use of this field once incorrect information is submitted, we could not ascertain the true percentage of sites using this markup.

      Duplicate IDs

      - IDs can be used in HTML to link two elements together. For example, the <label> element works this way. You specify the ID of the input field this label is describing and the browser links them together. The result? Users can now click on this label to focus on the input field, and screen readers will use this label as the description. + IDs can be used in HTML to link two elements together. For example, the <label> elementhttps://developer.mozilla.org/en-US/docs/Web/HTML/Element/label works this way. You specify the ID of the input field this label is describing and the browser links them together. The result? Users can now click on this label to focus on the input field, and screen readers will use this label as the description.

      -

      Unfortunately, 34.62% of sites have duplicate IDs, which means on many sites the ID specified by the user could refer to multiple different inputs. So when a user clicks on the label to select a field, they may end up selecting something different than they intended. As you might imagine, this could have negative consequences in something like a shopping cart.

      - This issue is even more pronounced for screen readers because their users may not be able to visually double check what is selected. Plus, many ARIA attributes, such as aria-describedby and aria-labelledbyselecting something differenthttps://www.deque.com/blog/unique-id-attributes-matter/ than they intended. As you might imagine, this could have negative consequences in something like a shopping cart. +

      +

      + This issue is even more pronounced for screen readers because their users may not be able to visually double check what is selected. Plus, many ARIA attributes, such as aria-describedbyhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute and aria-labelledbyhttps://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute, work similarly to the label element detailed above. So to make your site accessible, removing all duplicate IDs is a good first step.

      Conclusion

      @@ -4184,86 +4615,73 @@

      + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

      -

    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":10,"title":"SEO","description":"SEO chapter of the 2019 Web Almanac covering content, meta tags, indexability, linking, speed, structured data, internationalization, SPAs, AMP and security.","authors":["ymschaap","rachellcostello","AVGP"],"reviewers":["clarkeclark","andylimn","AymenLoukil","catalinred","mattludwig"],"translators":null,"discuss":"1765","results":"https://docs.google.com/spreadsheets/d/1uARtBWwz9nJOKqKPFinAMbtoDgu5aBtOhsBNmsCoTaA/","queries":"10_SEO","published":"2019-11-11","last_updated":"2020-03-01","chapter":"seo"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 10 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - SEO +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":10,"title":"SEO","description":"SEO chapter of the 2019 Web Almanac covering content, meta tags, indexability, linking, speed, structured data, internationalization, SPAs, AMP and security.","authors":["ymschaap","rachellcostello","AVGP"],"reviewers":["clarkeclark","andylimn","AymenLoukil","catalinred","mattludwig"],"translators":null,"discuss":"1765","results":"https://docs.google.com/spreadsheets/d/1uARtBWwz9nJOKqKPFinAMbtoDgu5aBtOhsBNmsCoTaA/","queries":"10_SEO","published":"2019-11-11","last_updated":"2020-03-01","chapter":"seo"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -4272,15 +4690,21 @@

    - + -
    {{ self.written_by_before() }} Yvo Schaap, Rachel Costello, {{ self.and() }} Martin Splitt{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} John Fox, Andrew Limn, Aymen Loukil, Catalin Rosu, {{ self.and() }} Matt Ludwig{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Search Engine Optimization (SEO) isn't just a hobby or a side project for digital marketers, it is crucial for the success of a website. The primary goal of SEO is to make sure that a website is optimized for the search engine bots that need to crawl and index its pages, as well as for the users that will be navigating the website and consuming its content. SEO impacts everyone working on a website, from the developer who is building it, through to the digital marketer who will need to promote it to new potential customers.

    -

    Let's put the importance of SEO into perspective. Earlier this year, the SEO industry looked on in horror (and fascination) as ASOS reported an 87% decrease in profits after a "difficult year". The brand attributed their issues to a drop in search engine rankings which occurred after they launched over 200 microsites and significant changes to their website's navigation, among other technical changes. Yikes.

    +

    + Let's put the importance of SEO into perspective. Earlier this year, the SEO industry looked on in horror (and fascination) as ASOS reported an 87% decrease in profitshttps://www.bbc.co.uk/news/business-47877688 after a "difficult year". The brand attributed their issues to a drop in search engine rankings which occurred after they launched over 200 microsites and significant changes to their website's navigation, among other technical changes. Yikes. +

    The purpose of the SEO chapter of the Web Almanac is to analyze on-site elements of the web that impact the crawling and indexing of content for search engines, and ultimately, website performance. In this chapter, we'll take a look at how well-equipped the top websites are to provide a great experience for users and search engines, and which ones still have work to do.

    Our analysis includes data from Lighthouse, the Chrome UX Report, and HTML element analysis. We focused on SEO fundamentals like <title> elements, the different types of on-page links, content, and loading speed, but also the more technical aspects of SEO, including indexability, structured data, internationalization, and AMP across over 5 million websites.

    Our custom metrics provide insights that, up until now, have not been exposed before. We are now able to make claims about the adoption and implementation of elements such as the hreflang tag, rich results eligibility, heading tag usage, and even anchor-based navigation for single page apps.

    @@ -4295,7 +4719,7 @@

    Word count

    We assessed the content on the pages by looking for groups of at least 3 words and counting how many were found in total. We found 2.73% of desktop pages that didn't have any word groups, meaning that they have no body content to help search engines understand what the website is about.

    - Figure 1. Distribution of the number of words per page. + Figure 1. Distribution of the number of words per page.
    Figure 1. Distribution of the number of words per page.
    @@ -4305,7 +4729,7 @@

    HeadingsWe also looked at whether pages are structured in a way that provides the right context for the content they contain. Headings (H1, H2, H3, etc.) are used to format and structure a page and make content easier to read and parse. Despite the importance of headings, 10.67% of pages have no heading tags at all.

    - Figure 2. Distribution of the number of headings per page. + Figure 2. Distribution of the number of headings per page.
    Figure 2. Distribution of the number of headings per page.
    @@ -4313,13 +4737,15 @@

    HeadingsThe median number of heading elements per page is 10. Headings contain 30 words on mobile pages and 32 words on desktop pages. This implies that the websites that utilize headings put significant effort in making sure that their pages are readable, descriptive, and clearly outline the page structure and context to search engine bots.

    - Figure 3. Distribution of H1 length per page. + Figure 3. Distribution of H1 length per page.
    Figure 3. Distribution of H1 length per page.

    In terms of specific heading length, the median length of the first H1 element found on desktop is 19 characters.

    -

    For advice on how to handle H1s and headings for SEO and accessibility, take a look at this video response by John Mueller in the Ask Google Webmasters series.

    +

    + For advice on how to handle H1s and headings for SEO and accessibility, take a look at this video response by John Muellerhttps://www.youtube.com/watch?v=zyqJJXWk0gk in the Ask Google Webmasters series. +

    Meta tags

    Meta tags allow us to give specific instructions and information to search engine bots about the different elements and content on a page. Certain meta tags can convey things like the topical focus of a page, as well as how the page should be crawled and indexed. We wanted to assess whether or not websites were making the most of these opportunities that meta tags provide.

    Page titles

    @@ -4330,22 +4756,27 @@

    Page tit

    Page titles are an important way of communicating the purpose of a page to a user or search engine. <title> tags are also used as headings in the SERPS and as the title for the browser tab when visiting a page, so it's no surprise to see that 97.1% of mobile pages have a document title.

    - Figure 5. Distribution of title length per page. + Figure 5. Distribution of title length per page.
    Figure 5. Distribution of title length per page.
    -

    Even though Google usually displays the first 50-60 characters of a page title within a SERP, the median length of the <title> tag was only 21 characters for mobile pages and 20 characters for desktop pages. Even the 75th percentile is still below the cutoff length. This suggests that some SEOs and content writers aren't making the most of the space allocated to them by search engines for describing their home pages in the SERPs.

    +

    + Even though Google usually displays the first 50-60 characters of a page titlehttps://moz.com/learn/seo/title-tag within a SERP, the median length of the <title> tag was only 21 characters for mobile pages and 20 characters for desktop pages. Even the 75th percentile is still below the cutoff length. This suggests that some SEOs and content writers aren't making the most of the space allocated to them by search engines for describing their home pages in the SERPs. +

    Meta descriptions

    Compared to the <title> tag, fewer pages were detected to have a meta description, as only 64.02% of mobile home pages have a meta description. Considering that Google often rewrites meta descriptions in the SERPs in response to the searcher's query, perhaps website owners place less importance on including a meta description at all.

    - Figure 6. Distribution of meta description length per page. + Figure 6. Distribution of meta description length per page.
    Figure 6. Distribution of meta description length per page.
    -

    The median meta description length was also lower than the recommended length of 155-160 characters, with desktop pages having descriptions of 123 characters. Interestingly, meta descriptions were consistently longer on mobile than on desktop, despite mobile SERPs traditionally having a shorter pixel limit. This limit has only been extended recently, so perhaps more website owners have been testing the impact of having longer, more descriptive meta descriptions for mobile results.

    +

    + The median meta description length was also lower than the recommended length of 155-160 charactershttps://moz.com/learn/seo/meta-description, with desktop pages having descriptions of 123 characters. Interestingly, meta descriptions were consistently longer on mobile than on desktop, despite mobile SERPs traditionally having a shorter pixel limit. This limit has only been extended recently, so perhaps more website owners have been testing the impact of having longer, more descriptive meta descriptions for mobile results. +

    Image alt tags

    Considering the importance of alt text for SEO and accessibility, it is far from ideal to see that only 46.71% of mobile pages use alt attributes on all of their images. This means that there are still improvements to be made with regard to making images across the web more accessible to users and understandable for search engines. Learn more about issues like these in the Accessibility chapter.

    Indexability

    @@ -4358,36 +4789,51 @@

    Indexa

    Status codes

    It is recommended to maintain a 200 OK status code for any important pages that you want search engines to index. The majority of pages tested were available for search engines to access, with 87.03% of initial HTML requests on desktop returning a 200 status code. The results were slightly lower for mobile pages, with only 82.95% of pages returning a 200 status code.

    -

    The next most commonly found status code on mobile was 302, a temporary redirect, which was found on 10.45% of mobile pages. This was higher than on desktop, with only 6.71% desktop home pages returning a 302 status code. This could be due to the fact that the mobile home pages were alternates to an equivalent desktop page, such as on non-responsive sites that have separate versions of the website for each device.

    +

    + The next most commonly found status code on mobile was 302, a temporary redirect, which was found on 10.45% of mobile pages. This was higher than on desktop, with only 6.71% desktop home pages returning a 302 status code. This could be due to the fact that the mobile home pages were alternateshttps://developers.google.com/search/mobile-sites/mobile-seo/separate-urls to an equivalent desktop page, such as on non-responsive sites that have separate versions of the website for each device. +

    Note: Our results didn't include 4xx or 5xx status codes.

    noindex

    A noindex directive can be served in the HTML <head> or in the HTTP headers as an X-Robots directive. A noindex directive basically tells a search engine not to include that page in its SERPs, but the page will still be accessible for users when they are navigating through the website. noindex directives are usually added to duplicate versions of pages that serve the same content, or low quality pages that provide no value to users coming to a website from organic search, such as filtered, faceted, or internal search pages.

    -

    96.93% of mobile pages passed the Lighthouse indexing audit, meaning that these pages didn't contain a noindex directive. However, this means that 3.07% of mobile home pages did have a noindex directive, which is cause for concern, meaning that Google was prevented from indexing these pages.

    +

    + 96.93% of mobile pages passed the Lighthouse indexing audithttps://developers.google.com/web/tools/lighthouse/audits/indexing, meaning that these pages didn't contain a noindex directive. However, this means that 3.07% of mobile home pages did have a noindex directive, which is cause for concern, meaning that Google was prevented from indexing these pages. +

    The websites included in our research are sourced from the Chrome UX Report dataset, which excludes websites that are not publicly discoverable. This is a significant source of bias because we're unable to analyze sites that Chrome determines to be non-public. Learn more about our methodology.

    Canonicalization

    Canonical tags are used to specify duplicate pages and their preferred alternates, so that search engines can consolidate authority which might be spread across multiple pages within the group onto one main page for improved rankings.

    -

    48.34% of mobile home pages were detected to have a canonical tag. Self-referencing canonical tags aren't essential, and canonical tags are usually required for duplicate pages. Home pages are rarely duplicated anywhere else across the site so seeing that less than half of pages have a canonical tag isn't surprising.

    +

    + 48.34% of mobile home pages were detectedhttps://developers.google.com/web/tools/lighthouse/audits/canonical to have a canonical tag. Self-referencing canonical tags aren't essential, and canonical tags are usually required for duplicate pages. Home pages are rarely duplicated anywhere else across the site so seeing that less than half of pages have a canonical tag isn't surprising. +

    robots.txt

    - One of the most effective methods for controlling search engine crawling is the robots.txt file. This is a file that sits on the root domain of a website and specifies which URLs and URL paths should be disallowed from being crawled by search engines. + One of the most effective methods for controlling search engine crawling is the robots.txt filehttps://www.deepcrawl.com/knowledge/technical-seo-library/robots-txt/. This is a file that sits on the root domain of a website and specifies which URLs and URL paths should be disallowed from being crawled by search engines. +

    +

    + It was interesting to observe that only 72.16% of mobile sites have a valid robots.txt, according to Lighthousehttps://developers.google.com/web/tools/lighthouse/audits/robots. The key issues we found are split between 22% of sites having no robots.txt file at all, and ~6% serving an invalid robots.txt file, and thus failing the audit. While there are many valid reasons to not have a robots.txt file, such as having a small website that doesn't struggle with crawl budget issueshttps://webmasters.googleblog.com/2017/01/what-crawl-budget-means-for-googlebot.html, having an invalid robots.txt is cause for concern.

    -

    It was interesting to observe that only 72.16% of mobile sites have a valid robots.txt, according to Lighthouse. The key issues we found are split between 22% of sites having no robots.txt file at all, and ~6% serving an invalid robots.txt file, and thus failing the audit. While there are many valid reasons to not have a robots.txt file, such as having a small website that doesn't struggle with crawl budget issues, having an invalid robots.txt is cause for concern.

    Linking

    One of the most important attributes of a web page is links. Links help search engines discover new, relevant pages to add to their index and navigate through websites. 96% of the web pages in our dataset contain at least one internal link, and 93% contain at least one external link to another domain. The small minority of pages that don't have any internal or external links will be missing out on the immense value that links pass through to target pages.

    The number of internal and external links included on desktop pages were consistently higher than the number found on mobile pages. Often a limited space on a smaller viewport causes fewer links to be included in the design of a mobile page compared to desktop.

    -

    It's important to bear in mind that fewer internal links on the mobile version of a page might cause an issue for your website. With mobile-first indexing, which for new websites is the default for Google, if a page is only linked from the desktop version and not present on the mobile version, search engines will have a much harder time discovering and ranking it.

    +

    + It's important to bear in mind that fewer internal links on the mobile version of a page might cause an issuehttps://moz.com/blog/internal-linking-mobile-first-crawl-paths for your website. With mobile-first indexinghttps://www.deepcrawl.com/knowledge/white-papers/mobile-first-index-guide/, which for new websites is the default for Google, if a page is only linked from the desktop version and not present on the mobile version, search engines will have a much harder time discovering and ranking it. +

    - Figure 7. Distribution of internal links per page. + Figure 7. Distribution of internal links per page.
    Figure 7. Distribution of internal links per page.
    - Figure 8. Distribution of external links per page. + Figure 8. Distribution of external links per page.
    Figure 8. Distribution of external links per page.
    @@ -4395,23 +4841,29 @@

    Linking

    The median desktop page includes 70 internal (same-site) links, whereas the median mobile page has 60 internal links. The median number of external links per page follows a similar trend, with desktop pages including 10 external links, and mobile pages including 8.

    - Figure 9. Distribution of anchor links per page. + Figure 9. Distribution of anchor links per page.
    Figure 9. Distribution of anchor links per page.

    Anchor links, which link to a certain scroll position on the same page, are not very popular. Over 65% of home pages have no anchor links. This is probably due to the fact that home pages don't usually contain any long-form content.

    -

    There is good news from our analysis of the descriptive link text metric. 89.94% of mobile pages pass Lighthouse's descriptive link text audit. This means that these pages don't have generic "click here", "go", "here" or "learn more" links, but use more meaningful link text which helps users and search engines better understand the context of pages and how they connect with one another.

    +

    + There is good news from our analysis of the descriptive link text metric. 89.94% of mobile pages pass Lighthouse's descriptive link text audithttps://developers.google.com/web/tools/lighthouse/audits/descriptive-link-text. This means that these pages don't have generic "click here", "go", "here" or "learn more" links, but use more meaningful link text which helps users and search engines better understand the context of pages and how they connect with one another. +

    Advanced

    Having descriptive, useful content on a page that isn't being blocked from search engines with a noindex or Disallow directive isn't enough for a website to succeed in organic search. Those are just the basics. There is a lot more than can be done to enhance the performance of a website and its appearance in SERPs.

    Some of the more technically complex aspects that have been gaining importance in successfully indexing and ranking websites include speed, structured data, internationalization, security, and mobile friendliness.

    Speed

    -

    Mobile loading speed was first announced as a ranking factor by Google in 2018. Speed isn't a new focus for Google though. Back in 2010 it was revealed that speed had been introduced as a ranking signal.

    +

    + Mobile loading speed was first announced as a ranking factorhttps://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html by Google in 2018. Speed isn't a new focus for Google though. Back in 2010 it was revealed that speed had been introduced as a ranking signalhttps://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.html. +

    A fast-loading website is also crucial for a good user experience. Users that have to wait even a few seconds for a site to load have the tendency to bounce and try another result from one of your SERP competitors that loads quickly and meets their expectations of website performance.

    The metrics we used for our analysis of load speed across the web is based on the Chrome UX Report (CrUX), which collects data from real-world Chrome users. This data shows that an astonishing 48% of websites are labeled as slow. A website is labeled slow if it more than 25% of FCP experiences slower than 3 seconds or 5% of FID experiences slower than 300 ms.

    - Figure 10. Distribution of the performance of user experiences by device type. + Figure 10. Distribution of the performance of user experiences by device type.
    Figure 10. Distribution of the performance of user experiences by device type.
    @@ -4419,15 +4871,30 @@

    Speed

    Split by device, this picture is even bleaker for tablet (65%) and phone (58%).

    Although the numbers are bleak for the speed of the web, the good news is that SEO experts and tools have been focusing more and more on the technical challenges of speeding up websites. You can learn more about the state of web performance in the Performance chapter.

    Structured data

    -

    Structured data allows website owners to add additional semantic data to their web pages, by adding JSON-LD snippets or Microdata, for example. Search engines parse this data to better understand these pages and sometimes use the markup to display additional relevant information in the search results. Some of the useful types of structured data are:

    +

    + Structured data allows website owners to add additional semantic data to their web pages, by adding JSON-LDhttps://en.wikipedia.org/wiki/JSON-LD snippets or Microdatahttps://developer.mozilla.org/en-US/docs/Web/HTML/Microdata, for example. Search engines parse this data to better understand these pages and sometimes use the markup to display additional relevant information in the search results. Some of the useful types of structured data are: +

    -

    The extra visibility that structured data can provide for websites is interesting for site owners, given that it can help to create more opportunities for traffic. For example, the relatively new FAQ schema will double the size of your snippet and the real estate of your site in the SERP.

    +

    + The extra visibilityhttps://developers.google.com/search/docs/guides/enhance-site that structured data can provide for websites is interesting for site owners, given that it can help to create more opportunities for traffic. For example, the relatively new FAQ schemahttps://developers.google.com/search/docs/data-types/faqpage will double the size of your snippet and the real estate of your site in the SERP. +

    During our research, we found that only 14.67% of sites are eligible for rich results on mobile. Interestingly, desktop site eligibility is slightly lower at 12.46%. This suggests that there is a lot more that site owners can be doing to optimize the way their home pages are appearing in search.

    Among the sites with structured data markup, the five most prevalent types are:

      @@ -4437,12 +4904,21 @@

    1. WebPage (11.58%)
    2. ImageObject (5.35%)

    -

    Interestingly, one of the most popular data types that triggers a search engine feature is SearchAction, which powers the sitelinks searchbox.

    +

    + Interestingly, one of the most popular data types that triggers a search engine feature is SearchAction, which powers the sitelinks searchboxhttps://developers.google.com/search/docs/data-types/sitelinks-searchbox. +

    The top five markup types all lead to more visibility in Google's search results, which might be the fuel for more widespread adoption of these types of structured data.

    Seeing as we only looked at home pages within this analysis, the results might look very different if we were to consider interior pages, too.

    -

    Review stars are only found on 1.09% of the web's home pages (via AggregateRating). Also, the newly introduced QAPage appeared only in 48 instances, and the FAQPage at a slightly higher frequency of 218 times. These last two counts are expected to increase in the future as we run more crawls and dive deeper into Web Almanac analysis.

    +

    + Review stars are only found on 1.09% of the web's home pages (via AggregateRatinghttps://schema.org/AggregateRating). Also, the newly introduced QAPagehttps://schema.org/QAPage appeared only in 48 instances, and the FAQPagehttps://schema.org/FAQPage at a slightly higher frequency of 218 times. These last two counts are expected to increase in the future as we run more crawls and dive deeper into Web Almanac analysis. +

    Internationalization

    -

    Internationalization is one of the most complex aspects of SEO, even according to some Google search employees. Internationalization in SEO focuses on serving the right content from a website with multiple language or country versions and making sure that content is being targeted towards the specific language and location of the user.

    +

    + Internationalization is one of the most complex aspects of SEO, even according to some Google search employeeshttps://twitter.com/JohnMu/status/965507331369984002. Internationalization in SEO focuses on serving the right content from a website with multiple language or country versions and making sure that content is being targeted towards the specific language and location of the user. +

    While 38.40% of desktop sites (33.79% on mobile) have the HTML lang attribute set to English, only 7.43% (6.79% on mobile) of the sites also contain an hreflang link to another language version. This suggests that the vast majority of websites that we analyzed don't offer separate versions of their home page that would require language targeting -- unless these separate versions do exist but haven't been configured correctly.

    @@ -4588,126 +5064,110 @@

    Figure 11. Top 25 most popular hreflang values.

    Next to English, the most common languages are French, Spanish, and German. These are followed by languages targeted towards specific geographies like English for Americans (en-us) or more obscure combinations like Spanish for the Irish (es-ie).

    -

    The analysis did not check for correct implementation, such as whether or not the different language versions properly link to each other. However, from looking at the low adoption of having an x-default version (only 3.77% on desktop and 1.30% on mobile), as is recommended, this is an indicator that this element is complex and not always easy to get right.

    +

    + The analysis did not check for correct implementation, such as whether or not the different language versions properly link to each other. However, from looking at the low adoption of having an x-default version (only 3.77% on desktop and 1.30% on mobile), as is recommendedhttps://www.google.com/url?q=https://support.google.com/webmasters/answer/189077?hl%3Den&sa=D&ust=1570627963630000&usg=AFQjCNFwzwglsbysT9au_I-7ZQkwa-QvrA, this is an indicator that this element is complex and not always easy to get right. +

    SPA crawlability

    -

    Single-page applications (SPAs) built with frameworks like React and Vue.js come with their own SEO complexity. Websites using a hash-based navigation, make it especially hard for search engines to properly crawl and index them. For example, Google had an "AJAX crawling scheme" workaround that turned out to be complex for search engines as well as developers, so it was deprecated in 2015.

    +

    + Single-page applications (SPAs) built with frameworks like React and Vue.js come with their own SEO complexity. Websites using a hash-based navigation, make it especially hard for search engines to properly crawl and index them. For example, Google had an "AJAX crawling scheme" workaround that turned out to be complex for search engines as well as developers, so it was deprecated in 2015https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html. +

    The number of SPAs that were tested had a relatively low number of links served via hash URLs, with 13.08% of React mobile pages using hash URLs for navigation, 8.15% of mobile Vue.js pages using them, and 2.37% of mobile Angular pages using them. These results were very similar for desktop pages too. This is positive to see from an SEO perspective, considering the impact that hash URLs can have on content discovery.

    -

    The higher number of hash URLs in React pages is surprising, especially in contrast to the lower number of hash URLs found on Angular pages. Both frameworks promote the adoption of routing packages where the History API is the default for links, instead of relying on hash URLs. Vue.js is considering moving to using the History API as the default as well in version 3 of their vue-router package.

    +

    + The higher number of hash URLs in React pages is surprising, especially in contrast to the lower number of hash URLs found on Angular pages. Both frameworks promote the adoption of routing packages where the History APIhttps://developer.mozilla.org/en-US/docs/Web/API/History is the default for links, instead of relying on hash URLs. Vue.js is considering moving to using the History API as the defaulthttps://github.com/vuejs/rfcs/pull/40 as well in version 3 of their vue-router package. +

    AMP

    -

    AMP (formerly known as "Accelerated Mobile Pages") was first introduced in 2015 by Google as an open source HTML framework. It provides components and infrastructure for websites to provide a faster experience for users, by using optimizations such as caching, lazy loading, and optimized images. Notably, Google adopted this for their search engine, where AMP pages are also served from their own CDN. This feature later became a standards proposal under the name Signed HTTP Exchanges.

    +

    + AMP (formerly known as "Accelerated Mobile Pages") was first introduced in 2015 by Google as an open source HTML framework. It provides components and infrastructure for websites to provide a faster experience for users, by using optimizations such as caching, lazy loading, and optimized images. Notably, Google adopted this for their search engine, where AMP pages are also served from their own CDN. This feature later became a standards proposal under the name Signed HTTP Exchangeshttps://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html. +

    Despite this, only 0.62% of mobile home pages contain a link to an AMP version. Given the visibility this project has had, this suggests that it has had a relatively low adoption. However, AMP can be more useful for serving article pages, so our home page-focused analysis won't reflect adoption across other page types.

    Security

    -

    A strong online shift in recent years has been for the web to move to HTTPS by default. HTTPS prevents website traffic from being intercepted on public Wi-Fi networks, for example, where user input data is then transmitted unsecurely. Google have been pushing for sites to adopt HTTPS, and even made HTTPS as a ranking signal. Chrome also supported the move to secure pages by labeling non-HTTPS pages as not secure in the browser.

    -

    For more information and guidance from Google on the importance of HTTPS and how to adopt it, please see Why HTTPS Matters.

    +

    + A strong online shift in recent years has been for the web to move to HTTPS by default. HTTPS prevents website traffic from being intercepted on public Wi-Fi networks, for example, where user input data is then transmitted unsecurely. Google have been pushing for sites to adopt HTTPS, and even made HTTPS as a ranking signalhttps://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html. Chrome also supported the move to secure pages by labeling non-HTTPS pages as not securehttps://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/ in the browser. +

    +

    + For more information and guidance from Google on the importance of HTTPS and how to adopt it, please see Why HTTPS Mattershttps://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https. +

    We found that 67.06% of websites on desktop are now served over HTTPS. Just under half of websites still haven't migrated to HTTPS and are serving non-secure pages to their users. This is a significant number. Migrations can be hard work, so this could be a reason why the adoption rate isn't higher, but an HTTPS migration usually require an SSL certificate and a simple change to the .htaccess file. There's no real reason not to switch to HTTPS.

    -

    Google's HTTPS Transparency Report reports a 90% adoption of HTTPS for the top 100 non-Google domains (representing 25% of all website traffic worldwide). The difference between this number and ours could be explained by the fact that relatively smaller sites are adopting HTTPS at a slower rate.

    +

    + Google's HTTPS Transparency Reporthttps://transparencyreport.google.com/https/overview reports a 90% adoption of HTTPS for the top 100 non-Google domains (representing 25% of all website traffic worldwide). The difference between this number and ours could be explained by the fact that relatively smaller sites are adopting HTTPS at a slower rate. +

    Learn more about the state of security in the Security chapter.

    Conclusion

    Through our analysis, we observed that the majority of websites are getting the fundamentals right, in that their home pages are crawlable, indexable, and include the key content required to rank well in search engines' results pages. Not every person who owns a website will be aware of SEO at all, let alone its best practice guidelines, so it is promising to see that so many sites have got the basics covered.

    However, more sites are missing the mark than expected when it comes to some of the more advanced aspects of SEO and accessibility. Site speed is one of these factors that many websites are struggling with, especially on mobile. This is a significant problem, as speed is one of the biggest contributors to UX, which is something that can impact rankings. The number of websites that aren't yet served over HTTPS is also problematic to see, considering the importance of security and keeping user data safe.

    There is a lot more that we can all be doing to learn about SEO best practices and industry developments. This is essential due to the evolving nature of the search industry and the rate at which changes happen. Search engines make thousands of improvements to their algorithms each year, and we need to keep up if we want our websites to reach more visitors in organic search.

    -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":11,"title":"PWA","description":"PWA chapter of the 2019 Web Almanac covering service workers (registations, installability, events and filesizes), Web App Manifests properties, and Workbox.","authors":["tomayac","jeffposnick"],"reviewers":["hyperpress","ahmadawais"],"translators":null,"discuss":"1766","results":"https://docs.google.com/spreadsheets/d/19BI3RQc_vR9bUPPZfVsF_4gpFWLNT6P0pLcAdL-A56c/","queries":"11_PWA","published":"2019-11-11","last_updated":"2020-03-01","chapter":"pwa"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 11 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - PWA +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":11,"title":"PWA","description":"PWA chapter of the 2019 Web Almanac covering service workers (registations, installability, events and filesizes), Web App Manifests properties, and Workbox.","authors":["tomayac","jeffposnick"],"reviewers":["hyperpress","ahmadawais"],"translators":null,"discuss":"1766","results":"https://docs.google.com/spreadsheets/d/19BI3RQc_vR9bUPPZfVsF_4gpFWLNT6P0pLcAdL-A56c/","queries":"11_PWA","published":"2019-11-11","last_updated":"2020-03-01","chapter":"pwa"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -4716,15 +5176,28 @@

    - + -
    {{ self.written_by_before() }} Tom Steiner, {{ self.and() }} Jeff Posnick{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} John Teague, {{ self.and() }} Ahmad Awais{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    -

    Progressive Web Apps (PWAs) are a new class of web applications, building on top of platform primitives like the Service Worker APIs. Service workers allow apps to support network-independent loading by acting as a network proxy, intercepting your web app's outgoing requests, and replying with programmatic or cached responses. Service workers can receive push notifications and synchronize data in the background even when the corresponding app is not running. Additionally, service workers, together with Web App Manifests, allow users to install PWAs to their devices' home screens.

    -

    Service workers were first implemented in Chrome 40, back in December 2014, and the term Progressive Web Apps was coined by Frances Berriman and Alex Russell in 2015. As service workers are now finally implemented in all major browsers, the goal for this chapter is to determine how many PWAs are actually out there, and how they make use of these new technologies. Certain advanced APIs like Background Sync are currently still only available on Chromium-based browsers, so as an additional question, we looked into which features these PWAs actually use.

    +

    + Progressive Web Apps (PWAs) are a new class of web applications, building on top of platform primitives like the Service Worker APIshttps://developer.mozilla.org/en/docs/Web/API/Service_Worker_API. Service workers allow apps to support network-independent loading by acting as a network proxy, intercepting your web app's outgoing requests, and replying with programmatic or cached responses. Service workers can receive push notifications and synchronize data in the background even when the corresponding app is not running. Additionally, service workers, together with Web App Manifestshttps://developer.mozilla.org/en-US/docs/Web/Manifest, allow users to install PWAs to their devices' home screens. +

    +

    + Service workers were first implemented in Chrome 40https://blog.chromium.org/2014/12/chrome-40-beta-powerful-offline-and.html, back in December 2014, and the term Progressive Web Apps was coined by Frances Berriman and Alex Russellhttps://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/ in 2015. As service workers are now finally implemented in all major browsershttps://jakearchibald.github.io/isserviceworkerready/, the goal for this chapter is to determine how many PWAs are actually out there, and how they make use of these new technologies. Certain advanced APIs like Background Synchttps://developers.google.com/web/updates/2015/12/background-sync are currently still only available on Chromium-based browsershttps://caniuse.com/#feat=background-sync, so as an additional question, we looked into which features these PWAs actually use. +

    Service workers

    Service worker registrations and installability

    @@ -4734,22 +5207,37 @@

    - Figure 2. Service Worker installation over time for desktop and mobile. + Figure 2. Service Worker installation over time for desktop and mobile.
    Figure 2. Service Worker installation over time for desktop and mobile.

    -

    Now this might not look overly impressive, but taking traffic data from Chrome Platform Status into account, we can see that a service worker controls about 15% of all page loads, which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers.

    +

    + Now this might not look overly impressive, but taking traffic data from Chrome Platform Status into account, we can see that a service worker controls about 15% of all page loadshttps://www.chromestatus.com/metrics/feature/timeline/popularity/990, which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. +

    15%
    -
    Figure 3. Percent of page views on a page that registers a service worker. (Source: Chrome Platform Status)
    +
    + Figure 3. Percent of page views on a page that registers a service worker. (Source: Chrome Platform Statushttps://www.chromestatus.com/metrics/feature/timeline/popularity/990) +
    -

    Lighthouse checks whether a page is eligible for an install prompt. 1.56% of mobile pages have an installable manifest.

    - To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the OnBeforeInstallPrompt interface. At present support is limited to Chromium-based browsers. + Lighthouse checks whether a page is eligible for an install prompthttps://developers.google.com/web/tools/lighthouse/audits/install-prompt. 1.56% of mobile pages have an installable manifesthttps://web.dev/installable-manifest/. +

    +

    + To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the OnBeforeInstallPrompt interfacehttps://w3c.github.io/manifest/#beforeinstallpromptevent-interface. At present support is limited to Chromium-based browsershttps://caniuse.com/#feat=web-app-manifest.

    Service worker events

    -

    In a service worker one can listen for a number of events:

    +

    + In a service worker one can listen for a number of eventshttps://developers.google.com/web/fundamentals/primers/service-workers/lifecycle: +

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":12,"title":"Mobile Web","description":"Mobile Web chapter of the 2019 Web Almanac covering page loading, textual content, zooming and scaling, buttons and links, and ease of filling out forms.","authors":["obto"],"reviewers":["AymenLoukil","hyperpress"],"translators":null,"discuss":"1767","results":"https://docs.google.com/spreadsheets/d/1dPBDeHigqx9FVaqzfq7CYTz4KjllkMTkfq4DG4utE_g/","queries":"12_Mobile_Web","published":"2019-11-11","last_updated":"2020-05-20","chapter":"mobile-web"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 12 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Mobile Web +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":12,"title":"Mobile Web","description":"Mobile Web chapter of the 2019 Web Almanac covering page loading, textual content, zooming and scaling, buttons and links, and ease of filling out forms.","authors":["obto"],"reviewers":["AymenLoukil","hyperpress"],"translators":null,"discuss":"1767","results":"https://docs.google.com/spreadsheets/d/1dPBDeHigqx9FVaqzfq7CYTz4KjllkMTkfq4DG4utE_g/","queries":"12_Mobile_Web","published":"2019-11-11","last_updated":"2020-05-20","chapter":"mobile-web"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -4958,19 +5455,28 @@

    - + -
    {{ self.written_by_before() }} David Fox{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Aymen Loukil, {{ self.and() }} John Teague{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Let's step back for a moment, to the year 2007. The "mobile web" is currently just a blip on the radar, and for good reason too. Why? Mobile browsers have little to no CSS support, meaning sites look nothing like they do on desktop — some browsers can only display text. Screens are incredibly small and can only display a few lines of text at a time. And the replacements for a mouse are these tiny little arrow keys you use to "tab around". Needless to say, browsing the web on a phone is truly a labor of love. However, all of this is just about to change.

    In the middle of his presentation, Steve Jobs takes the newly unveiled iPhone, sits down, and begins to surf the web in a way we had only previously dreamed of. A large screen and fully featured browser displaying websites in their full glory. And most importantly, surfing the web using the most intuitive pointer device known to man: our fingers. No more tabbing around with tiny little arrow keys.

    -

    Since 2007, the mobile web has grown at an explosive rate. And now, 13 years later, mobile accounts for 59% of all searches and 58.7% of all web traffic, according to Akamai mPulse data in July 2019. It's no longer an afterthought, but the primary way people experience the web. So given how significant mobile is, what kind of experience are we providing our visitors? Where are we falling short? Let's find out.

    +

    + Since 2007, the mobile web has grown at an explosive rate. And now, 13 years later, mobile accounts for 59% of all searcheshttps://www.merkleinc.com/thought-leadership/digital-marketing-report and 58.7% of all web traffic, according to Akamai mPulsehttps://developer.akamai.com/akamai-mpulse-real-user-monitoring-solution data in July 2019. It's no longer an afterthought, but the primary way people experience the web. So given how significant mobile is, what kind of experience are we providing our visitors? Where are we falling short? Let's find out. +

    The page loading experience

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

    -

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

    +

    + Let's start with what phone the typical mobile user has. The average Android phone is ~$250https://web.archive.org/web/20190921115844/https://www.idc.com/getdoc.jsp?containerId=prUS45115119, and one of the most popular phoneshttps://web.archive.org/web/20190812221233/https://deviceatlas.com/blog/most-popular-android-smartphones in that range is a Samsung Galaxy S6. So this is likely the kind of phone they use, which is actually 4x slower than an iPhone 8. This user doesn't have access to a fast 4G connection, but rather a 2G connection (29%https://www.gsma.com/r/mobileeconomy/ of the time) or 3G connection (28%https://www.gsma.com/r/mobileeconomy/ of the time). And this is what it all adds up to: +

    @@ -4978,7 +5484,9 @@

    2G or 3G + + 2G or 3Ghttps://www.gsma.com/r/mobileeconomy/ + Latency @@ -4990,7 +5498,9 @@

    Galaxy S6 — 4x slower than iPhone 8 (Octane V2 score) + + Galaxy S6https://www.gsmarena.com/samsung_galaxy_s6-6849.php — 4x slowerhttps://www.notebookcheck.net/A11-Bionic-vs-7420-Octa_9250_6662.247596.0.html than iPhone 8 (Octane V2 score) + @@ -5000,17 +5510,25 @@

    Pages bloated with JavaScript

    -

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

    -

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

    +

    + The state of JavaScript on the mobile web is terrifying. According to HTTP Archive's JavaScript reporthttps://httparchive.org/reports/state-of-javascript?start=2016_05_15&end=2019_07_01&view=list#bytesJs, the median mobile site requires phones to download 375 KB of JavaScript. Assuming a 70% compression ratio, this means that phones have to parse, compile, and execute 1.25 MB of JavaScript at the median. +

    +

    + Why is this a problem? Because sites loading this much JS take upwards of 10 secondshttps://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci to become consistently interactive. Or in other words, your page may appear fully loaded, but when a user clicks any of your buttons or menus, the user may experience some slowdown because the JavaScript hasn't finished executing. In the worst case scenario, users may be forced to keep clicking the button for upwards of 10 seconds, just waiting for that magical moment where something actually happens. Think about how confusing and frustrating that can be. +

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

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

    +

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

    • JavaScript is often used to both generate and change the page as it loads.
    • It's also delivered as text to the browser. So it compresses well, and should be delivered faster than just a screenshot of the page.
      • @@ -5019,25 +5537,33 @@

      The *JavaScript Bloat Score* is defined as: (total JavaScript size) / (size of PNG screenshot of viewport). Any number greater than 1.0 means it's faster to send a screenshot.

      The results of this? Of the 5+ million websites analyzed, 75.52% were bloated with JavaScript. We have a long way to go.

      Note that we were not able to capture and measure the screenshots of all 5 million+ sites we analyzed. Instead, we took a random sampling of 1000 sites to find what the median viewport screenshot size is (140 KB), and then compared each site's JavaScript download size to this number.

      -

      For a more in-depth breakdown of the effects of JavaScript, check out The Cost of JavaScript in 2018 by Addy Osmani.

      +

      + For a more in-depth breakdown of the effects of JavaScript, check out The Cost of JavaScript in 2018https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 by Addy Osmani. +

      Service Worker usage

      -

      Browsers typically load all pages the same. They prioritize the download of some resources above others, follow the same caching rules, etc. Thanks to Service Workers though, we now have a way to directly control how our resources are handled by the network layer, often times resulting in quite significant improvements to our page load times.

      +

      + Browsers typically load all pages the same. They prioritize the download of some resources above others, follow the same caching rules, etc. Thanks to Service Workershttps://developers.google.com/web/fundamentals/primers/service-workers though, we now have a way to directly control how our resources are handled by the network layer, often times resulting in quite significant improvements to our page load times. +

      Despite being available since 2016 and implemented on every major browser, only 0.64% of sites utilize them!

      Shifting content while loading

      One of the most beautiful parts of the web is how web pages load progressively by nature. Browsers download and display content as soon as they are able, so users can engage with your content as soon as possible. However, this can have a detrimental effect if you don't design your site with this in mind. Specifically, content can shift position as resources load and impede the user experience.

      - Figure 3. Example of shifting content distracting a reader. CLS total of 42.59%. Image courtesy of LookZook + Figure 3. Example of shifting content distracting a reader. CLS total of 42.59%. Image courtesy of LookZook
      Figure 3. Example of shifting content distracting a reader. CLS total of 42.59%. Image courtesy of LookZook

      Imagine you're reading an article when all of a sudden, an image loads and pushes the text you're reading way down the screen. You now have to hunt for where you were or just give up on reading the article. Or, perhaps even worse, you begin to click a link right before an ad loads in the same spot, resulting in an accidental click on the ad instead.

      -

      So, how do we measure how much our sites shift? In the past it was quite difficult (if not impossible), but thanks to the new Layout Instability API we can do this in two steps:

      +

      + So, how do we measure how much our sites shift? In the past it was quite difficult (if not impossible), but thanks to the new Layout Instability APIhttps://web.dev/layout-instability-api we can do this in two steps: +

      1. Via the Layout Instability API, track each shift's impact on the page. This is reported to you as a percentage of how much content in the viewport has shifted.

      2. -

        Take all the shifts you've tracked and add them together. The result is what we call the Cumulative Layout Shift (CLS) score.

        +

        + Take all the shifts you've tracked and add them together. The result is what we call the Cumulative Layout Shifthttps://web.dev/layout-instability-api#a-cumulative-layout-shift-score (CLS) score. +

      Because every visitor can have a different CLS, in order to analyze this metric across the web with the Chrome UX Report (CrUX), we combine every experience into three different buckets:

      @@ -5059,16 +5585,23 @@

      Textual content

      The primary goal of a web page is to deliver content users want to engage with. This content might be a YouTube video or an assortment of images, but often times, it's simply the text on the page. It goes without saying that ensuring our textual content is legible to our visitors is extremely important. Because if visitors can't read it, there's nothing left to engage with, and they'll leave. There are two key things to check when ensuring your text is legible to readers: color contrast and font sizes.

      Color contrast

      -

      When designing our sites we tend to be in more optimal conditions, and have far better eyes than many of our visitors. Visitors may be colorblind and unable to distinguish between the text and background color. 1 in every 12 men and 1 in 200 women of European descent are colorblind. Or perhaps visitors are reading the page while the sun is creating glare on their screen, which may similarly impair legibility.

      -

      To help us mitigate this problem, there are accessibility guidelines we can follow when choosing our text and background colors. So how are we doing in meeting these baselines? Only 22.04% of sites give all their text sufficient color contrast. This value is actually a lower limit, as we could only analyze text with solid backgrounds. Image and gradient backgrounds were unable to be analyzed.

      +

      + When designing our sites we tend to be in more optimal conditions, and have far better eyes than many of our visitors. Visitors may be colorblind and unable to distinguish between the text and background color. 1 in every 12 men and 1 in 200 womenhttp://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf of European descent are colorblind. Or perhaps visitors are reading the page while the sun is creating glare on their screen, which may similarly impair legibility. +

      +

      + To help us mitigate this problem, there are accessibility guidelineshttps://dequeuniversity.com/rules/axe/2.2/color-contrast we can follow when choosing our text and background colors. So how are we doing in meeting these baselines? Only 22.04% of sites give all their text sufficient color contrast. This value is actually a lower limit, as we could only analyze text with solid backgrounds. Image and gradient backgrounds were unable to be analyzed. +

      - Figure 4. Example of what text with insufficient color contrast looks like. Courtesy of LookZook + Figure 4. Example of what text with insufficient color contrast looks like. Courtesy of LookZook
      Figure 4. Example of what text with insufficient color contrast looks like. Courtesy of LookZook
      -

      For colorblindness stats for other demographics, see this paper.

      +

      + For colorblindness stats for other demographics, see this paperhttps://web.archive.org/web/20180304115406/http://www.allpsych.uni-giessen.de/karl/colbook/sharpe.pdf. +

      Font size

      The second part of legibility is ensuring that text is large enough to read easily. This is important for all users, but especially so for older age demographics. Font sizes under 12px tend to be harder to read.

      Across the web we found 80.66% of web pages meet this baseline.

      @@ -5087,21 +5620,26 @@

      - Figure 5. Percent of desktop and mobile websites that enable or disable zooming/scaling. + Figure 5. Percent of desktop and mobile websites that enable or disable zooming/scaling.
      Figure 5. Percent of desktop and mobile websites that enable or disable zooming/scaling.

    -

    However, developers have misused this so much that almost one out of every three sites (32.21%) disable this feature, and Apple (as of iOS 10) no longer allows web developers to disable zooming. Mobile Safari simply ignores the tag. All sites, no matter what, can be zoomed and scaled on newer Apple devices, which account for over 11% of all web traffic worldwide!

    +

    + However, developers have misused this so much that almost one out of every three sites (32.21%) disable this feature, and Apple (as of iOS 10) no longer allows web developers to disable zooming. Mobile Safari simply ignores the taghttps://archive.org/details/ios-10-beta-release-notes. All sites, no matter what, can be zoomed and scaled on newer Apple devices, which account for over 11%https://gs.statcounter.com/ of all web traffic worldwide! +

    Rotating pages

    Mobile devices allow users to rotate them so your website can be viewed in the format users prefer. Users do not always keep the same orientation throughout a session however. When filling out forms, users may rotate to landscape mode to use the larger keyboard. Or while browsing products, some may prefer the larger product images landscape mode gives them. Because of these types of use cases, it's very important not to rob the user of this built-in ability of mobile devices. And the good news is that we found virtually no sites that disable this. Only 87 total sites (or 0.0016%) disable this feature. This is fantastic.

    Tap targets

    We're used to having precise devices like mice while on desktop, but the story is quite different on mobile. On mobile we engage with sites through these large and imprecise tools we call fingers. Because of how imprecise they can be, we constantly "fat finger" links and buttons, tapping on things we never intended.

    -

    Designing tap targets appropriately to mitigate this issue can be difficult because of how widely fingers vary in size. However, lots of research has now been done and there are safe standards for how large buttons should be and how far apart they need to be separated.

    +

    + Designing tap targets appropriately to mitigate this issue can be difficult because of how widely fingers vary in size. However, lots of research has now been done and there are safe standardshttps://developers.google.com/web/tools/lighthouse/audits/tap-targets for how large buttons should be and how far apart they need to be separated. +

    - Figure 6. Standards for sizing and spacing tap targets. Image courtesy of LookZook + Figure 6. Standards for sizing and spacing tap targets. Image courtesy of LookZook
    Figure 6. Standards for sizing and spacing tap targets. Image courtesy of LookZook
    @@ -5115,7 +5653,9 @@

    New input types

    In the past, text and password were some of the only input types available to developers as it met almost all of our needs on desktop. This is not the case for mobile devices. Mobile keyboards are incredibly small, and a simple task, like entering an email address, may require users to switch between multiple keyboards: the standard keyboard and the special character keyboard for the "@" symbol. Simply entering a phone number can be difficult using the default keyboard's tiny numbers.

    -

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

    +

    + Many new input typeshttps://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Form_%3Cinput%3E_types have since been introduced, allowing developers to inform browsers what kind of data is expected, and enable browsers to provide customized keyboards specifically for these input types. For example, a type of email provides users with an alphanumeric keyboard including the "@" symbol, and a type of tel will display a numeric keypad. +

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

    @@ -5147,7 +5687,7 @@

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

    Enabling autocomplete for inputs

    - The autocomplete input attribute enables users to fill out form fields in a single click. Users fill out tons of forms, often with the exact same information each time. Realizing this, browsers have begun to securely store this information so it can be used on future pages. All developers need to do is use this autocomplete attribute to tell browsers what exact piece of information needs to be filled in, and the browser does the rest. + The autocompletehttps://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete input attribute enables users to fill out form fields in a single click. Users fill out tons of forms, often with the exact same information each time. Realizing this, browsers have begun to securely store this information so it can be used on future pages. All developers need to do is use this autocomplete attribute to tell browsers what exact piece of information needs to be filled in, and the browser does the rest.

    29.62%
    @@ -5163,76 +5703,109 @@

    - A 1000 hour free-trial CD for America Online + A 1000 hour free-trial CD for America Online -
    Figure 9. 1000 hours of America Online for free, from archive.org.
    +
    + Figure 9. 1000 hours of America Online for free, from archive.orghttps://archive.org/details/America_Online_1000_Hours_Free_for_45_Days_Version_7.0_Faster_Than_Ever_AM402R28. +

    Notes:

    1. We defined sites making a mobile effort as those who adjust their designs for smaller screens. Or rather, those which have at least one CSS breakpoint at 600px or less.

    2. -

      Potential users, or the total addressable market, are those who are 15+ years old: 5.7 billion people.

      +

      + Potential users, or the total addressable market, are those who are 15+ years old: 5.7 billion peoplehttps://www.prb.org/international/geography/world. +

    3. -

      Desktop search and web traffic share has been on the decline for years

      +

      + Desktop searchhttps://www.merkleinc.com/thought-leadership/digital-marketing-report and web traffic sharehttps://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-201205-201909 has been on the decline for years +

    4. -

      The total number of active smartphones was found by totaling the number of active Androids and iPhones (made public by Apple and Google), and a bit of math to account for Chinese internet-connected phones. More info here.

      +

      + The total number of active smartphones was found by totaling the number of active Androids and iPhones (made public by Apple and Google), and a bit of math to account for Chinese internet-connected phones. More info herehttps://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile. +

    5. -

      The 1.6 billion desktops is calculated by numbers made public by Microsoft and Apple. It does not include linux PC users.

      +

      + The 1.6 billion desktops is calculated by numbers made public by Microsofthttps://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices and Applehttps://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users. It does not include linux PC users. +

    -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"III","chapter_number":13,"title":"Ecommerce","description":"Ecommerce chapter of the 2019 Web Almanac covering ecommerce platforms, payloads, images, third-parties, performance, seo, and PWAs.","authors":["samdutton","alankent"],"reviewers":["voltek62"],"translators":null,"discuss":"1768","results":"https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/","queries":"13_Ecommerce","published":"2019-11-11","last_updated":"2020-05-19","chapter":"ecommerce"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} III {{ self.chapter() }} 13 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Ecommerce +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"III","chapter_number":13,"title":"Ecommerce","description":"Ecommerce chapter of the 2019 Web Almanac covering ecommerce platforms, payloads, images, third-parties, performance, seo, and PWAs.","authors":["samdutton","alankent"],"reviewers":["voltek62"],"translators":null,"discuss":"1768","results":"https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/","queries":"13_Ecommerce","published":"2019-11-11","last_updated":"2020-05-19","chapter":"ecommerce"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -5241,18 +5814,28 @@

    - + -
    {{ self.written_by_before() }} Sam Dutton, {{ self.and() }} Alan Kent{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Vincent Terrasi{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    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 platforms, for example:

      -
    • Paid-for services such as Shopify 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 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 that offer the same features as their self-hosted counterparts, except that hosting is managed as a service by a third-party.
      • +
    • + Paid-for services such as Shopifyhttps://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 Sourcehttps://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 Commercehttps://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. +
    10%
    @@ -5350,7 +5933,7 @@

    Long tail

    - Figure 4. Adoption of top ecommerce platforms. + Figure 4. Adoption of top ecommerce platforms.
    Figure 4. Adoption of top ecommerce platforms.
    @@ -5358,7 +5941,7 @@

    There are 110 ecommerce platforms that each have fewer than 0.1% of desktop or mobile websites. Around 60 of these have fewer than 0.01% of mobile or desktop websites.

    - Figure 5. Combined adoption of the top six ecommerce platforms versus the other 110 platforms. + Figure 5. Combined adoption of the top six ecommerce platforms versus the other 110 platforms.
    Figure 5. Combined adoption of the top six ecommerce platforms versus the other 110 platforms.
    @@ -5368,7 +5951,7 @@

    - Figure 6. Percent of pages using any ecommerce platform. + Figure 6. Percent of pages using any ecommerce platform.
    Figure 6. Percent of pages using any ecommerce platform.
    @@ -5378,19 +5961,21 @@

    page weight of an ecommerce platform includes all HTML, CSS, JavaScript, JSON, XML, images, audio, and video.

    - Figure 7. Distribution of ecommerce page weight. + Figure 7. Distribution of ecommerce page weight.
    Figure 7. Distribution of ecommerce page weight.
    - Figure 8. Distribution of requests per ecommerce page. + Figure 8. Distribution of requests per ecommerce page.
    Figure 8. Distribution of requests per ecommerce page.
    -

    The median desktop ecommerce platform page loads 108 requests and 2.7 MB. The median weight for all desktop pages is 74 requests and 1.9 MB. In other words, ecommerce pages make nearly 50% more requests than other web pages, with payloads around 35% larger. By comparison, the amazon.com home page makes around 300 requests on first load, for a page weight of around 5 MB, and ebay.com makes around 150 requests for a page weight of approximately 3 MB. The page weight and number of requests for home pages on ecommerce platforms is slightly smaller on mobile at every percentile, but around 10% of all ecommerce home pages load more than 7 MB and make over 200 requests.

    +

    + The median desktop ecommerce platform page loads 108 requests and 2.7 MB. The median weight for all desktop pages is 74 requests and 1.9 MB. In other words, ecommerce pages make nearly 50% more requests than other web pages, with payloads around 35% larger. By comparison, the amazon.comhttps://amazon.com home page makes around 300 requests on first load, for a page weight of around 5 MB, and ebay.comhttps://ebay.com makes around 150 requests for a page weight of approximately 3 MB. The page weight and number of requests for home pages on ecommerce platforms is slightly smaller on mobile at every percentile, but around 10% of all ecommerce home pages load more than 7 MB and make over 200 requests. +

    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 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?

    Requests and payload by type

    @@ -5602,7 +6187,7 @@

    HTML payload size

    - Figure 11. Distribution of HTML bytes (in KB) per ecommerce page. + Figure 11. Distribution of HTML bytes (in KB) per ecommerce page.
    Figure 11. Distribution of HTML bytes (in KB) per ecommerce page.
    @@ -5612,14 +6197,14 @@

    Image stats

    - Figure 12. Distribution of image bytes (in KB) per ecommerce page. + Figure 12. Distribution of image bytes (in KB) per ecommerce page.
    Figure 12. Distribution of image bytes (in KB) per ecommerce page.
    - Figure 13. Distribution of image requests per ecommerce page. + Figure 13. Distribution of image requests per ecommerce page.
    Figure 13. Distribution of image requests per ecommerce page.
    @@ -5630,24 +6215,37 @@

    1,517 KB

    Figure 14. The median number of image bytes per mobile ecommerce page.
    -

    A significant proportion of ecommerce pages have sizable image payloads and make a large number of image requests on first load. See HTTP Archive's State of Images report and the media and page weight chapters for more context.

    +

    + A significant proportion of ecommerce pages have sizable image payloads and make a large number of image requests on first load. See HTTP Archive's State of Imageshttps://httparchive.org/reports/state-of-images report and the media and page weight chapters for more context. +

    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.

    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 simultaneously providing a best-possible experience to lower-end devices and those with poor connectivity.

    - Figure 15. Popular image formats. + Figure 15. Popular image formats.
    Figure 15. Popular image formats.
    -

    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, IMG_20190113_113201.jpg returns a WebP image in Chrome. However, the way HTTP Archive detects image formats is to check for keywords in the MIME type first, then fall back to the file extension. 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.

    +

    + 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, IMG_20190113_113201.jpghttps://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg returns a WebP image in Chrome. However, the way HTTP Archive detects image formatshttps://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994 is to check for keywords in the MIME type first, then fall back to the file extension. 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. +

    PNG

    One in four images on ecommerce pages are 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 or by using user agent capability detection via an image service such as Cloudinary.

    +

    + Using WebP with a PNG fallback can be a far more efficient alternative, either via a picture elementhttp://simpl.info/picturetype or by using user agent capability detection via an image service such as Cloudinaryhttps://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg. +

    WebP

    -

    Only 1% of images on ecommerce platforms are WebP, which tallies with the authors' experience of site reviews and partner work. WebP is supported by all modern browsers other than Safari 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).

    -

    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, despite the availability of guides and tools (e.g. Squoosh and cwebp). We need to do further research into why there hasn't been more take-up of WebP, which is now nearly 10 years old.

    +

    + Only 1% of images on ecommerce platforms are WebP, which tallies with the authors' experience of site reviews and partner work. WebP is supported by all modern browsers other than Safarihttps://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). +

    +

    + 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, despite the availability of guideshttps://web.dev/serve-images-webp and tools (e.g. Squooshhttps://squoosh.app/ and cwebphttps://developers.google.com/speed/webp/docs/cwebp). We need to do further research into why there hasn't been more take-up of WebP, which is now nearly 10 years oldhttps://blog.chromium.org/2010/09/webp-new-image-format-for-web.html. +

    Image dimensions

    @@ -5713,35 +6311,41 @@

    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, or 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.

    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

    -

    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. Patrick Hulce's third-party-web tool is used to determine third-party requests for this report, and this is discussed more in the Third Parties chapter.

    +

    + 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 performancehttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript. Patrick Hulcehttps://twitter.com/patrickhulce's third-party-web toolhttps://github.com/patrickhulce/third-party-web is used to determine third-party requests for this report, and this is discussed more in the Third Parties chapter. +

    - Figure 17. Distribution of third-party requests per ecommerce page. + Figure 17. Distribution of third-party requests per ecommerce page.
    Figure 17. Distribution of third-party requests per ecommerce page.
    - Figure 18. Distribution of third-party bytes per ecommerce page. + Figure 18. Distribution of third-party bytes per ecommerce page.
    Figure 18. Distribution of third-party bytes per ecommerce page.

    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.

    -

    Other studies have 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 ecommerce pages.

    +

    + Other studieshttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/ have 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 ecommerce pages. +

    Third-party requests and payload per platform

    Note the charts and tables below show data for mobile only.

    - Figure 19. Distribution of third-party requests per mobile page for each ecommerce platform. + Figure 19. Distribution of third-party requests per mobile page for each ecommerce platform.
    Figure 19. Distribution of third-party requests per mobile page for each ecommerce platform.
    - Figure 20. Distribution of third-party bytes (KB) per mobile page for each ecommerce platform. + Figure 20. Distribution of third-party bytes (KB) per mobile page for each ecommerce platform.
    Figure 20. Distribution of third-party bytes (KB) per mobile page for each ecommerce platform.
    @@ -5751,7 +6355,7 @@

    First Contentful Paint (FCP)

    - Figure 21. Average distribution of FCP experiences per ecommerce platform. + Figure 21. Average distribution of FCP experiences per ecommerce platform.
    Figure 21. Average distribution of FCP experiences per ecommerce platform.
    @@ -5763,94 +6367,92 @@

    PWA chapter for more information on this topic beyond just ecommerce sites.

    - Figure 22. Distribution of Lighthouse PWA category scores for mobile ecommerce pages. + Figure 22. Distribution of Lighthouse PWA category scores for mobile ecommerce pages.
    Figure 22. Distribution of Lighthouse PWA category scores for mobile ecommerce pages.
    -

    More than 60% of home pages on ecommerce platforms get a Lighthouse PWA score between 0.25 and 0.35. Less than 20% of home pages on ecommerce platforms get a score of more than 0.5 and less than 1% of home pages score more than 0.6.

    -

    Lighthouse returns a Progressive Web App (PWA) score between 0 and 1. 0 is the worst possible score, and 1 is the best. The PWA audits are based on the Baseline PWA 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.

    +

    + More than 60% of home pages on ecommerce platforms get a Lighthouse PWA scorehttps://developers.google.com/web/ilt/pwa/lighthouse-pwa-analysis-tool between 0.25 and 0.35. Less than 20% of home pages on ecommerce platforms get a score of more than 0.5 and less than 1% of home pages score more than 0.6. +

    +

    + Lighthouse returns a Progressive Web App (PWA) score between 0 and 1. 0 is the worst possible score, and 1 is the best. The PWA audits are based on the Baseline PWA Checklisthttps://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. +

    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 mobile pages.

    -

    Clearly, the majority of ecommerce pages are failing most PWA checklist audits. We need to do further analysis to better understand which audits are failing and why.

    +

    + Clearly, the majority of ecommerce pages are failing most PWA checklist auditshttps://developers.google.com/web/progressive-web-apps/checklist. We need to do further analysis to better understand which audits are failing and why. +

    Conclusion

    This comprehensive study of ecommerce usage shows some interesting data and also the wide variations in ecommerce sites, even among 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 for more on that). Likewise, it would be interesting to segment these metrics by geography. This study detected 246 ad providers on home pages on ecommerce platforms. Further studies (perhaps in next year's 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.

    -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"III","chapter_number":14,"title":"CMS","description":"CMS chapter of the 2019 Web Almanac covering CMS adoption, how CMS suites are built, User experience of CMS powered websites, and CMS innovation.","authors":["ernee","amedina"],"reviewers":["sirjonathan"],"translators":null,"discuss":"1769","results":"https://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/","queries":"14_CMS","published":"2019-11-11","last_updated":"2020-03-01","chapter":"cms"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} III {{ self.chapter() }} 14 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - CMS +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"III","chapter_number":14,"title":"CMS","description":"CMS chapter of the 2019 Web Almanac covering CMS adoption, how CMS suites are built, User experience of CMS powered websites, and CMS innovation.","authors":["ernee","amedina"],"reviewers":["sirjonathan"],"translators":null,"discuss":"1769","results":"https://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/","queries":"14_CMS","published":"2019-11-11","last_updated":"2020-03-01","chapter":"cms"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -5859,12 +6461,16 @@

    - + -
    {{ self.written_by_before() }} Renee Johnson, {{ self.and() }} Alberto Medina{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Jonathan Wold{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    The general term Content Management System (CMS) refers to systems enabling individuals and organizations to create, manage, and publish content. A CMS for web content, specifically, is a system aimed at creating, managing, and publishing content to be consumed and experienced via the open web.

    Each CMS implements some subset of a wide range of content management capabilities and the corresponding mechanisms for users to build websites easily and effectively around their content. Such content is often stored in some type of database, providing users with the flexibility to reuse it wherever needed for their content strategy. CMSs also provide admin capabilities aimed at making it easy for users to upload and manage content as needed.

    @@ -5872,10 +6478,13 @@

    Introd

    When we think about CMSs, we need to account for all the components that play a role in the viability of such a system for providing a platform for publishing content on the web. All of these components form an ecosystem surrounding the CMS platform, and they include hosting providers, extension developers, development agencies, site builders, etc. Thus, when we talk about a CMS, we usually refer to both the platform itself and its surrounding ecosystem.

    Why do content creators use a CMS?

    At the beginning of (web evolution) time, the web ecosystem was powered by a simple growth loop, where users could become creators just by viewing the source of a web page, copy-pasting according to their needs, and tailoring the new version with individual elements like images.

    -

    As the web evolved, it became more powerful, but also more complicated. As a consequence, that simple growth loop was broken and it was not the case anymore that any user could become a creator. For those who could pursue the content creation path, the road became arduous and hard to achieve. The usage-capability gap, that is, the difference between what can be done in the web and what is actually done, grew steadily.

    +

    + As the web evolved, it became more powerful, but also more complicated. As a consequence, that simple growth loop was broken and it was not the case anymore that any user could become a creator. For those who could pursue the content creation path, the road became arduous and hard to achieve. The usage-capability gaphttps://medinathoughts.com/2018/05/17/progressive-wordpress/, that is, the difference between what can be done in the web and what is actually done, grew steadily. +

    - Figure 1. Chart illustrating the increase in web capabilities from 1999 to 2018. + Figure 1. Chart illustrating the increase in web capabilities from 1999 to 2018.
    Figure 1. Chart illustrating the increase in web capabilities from 1999 to 2018.
    @@ -5890,11 +6499,14 @@

    CMS ad
    Figure 2. Percent of web pages powered by a CMS.

    Today, we can observe that more than 40% of the web pages are powered by some CMS platform; 40.01% for mobile and 39.61% for desktop more precisely.

    -

    There are other datasets tracking market share of CMS platforms, such as W3Techs, and they reflect higher percentages of more than 50% of web pages powered by CMS platforms. Furthermore, they observe also that CMS platforms are growing, as fast as 12% year-over-year growth in some cases! The deviation between our analysis and W3Tech's analysis could be explained by a difference in research methodologies. You can read more about ours on the Methodology page.

    +

    + There are other datasets tracking market share of CMS platforms, such as W3Techshttps://w3techs.com/technologies/history_overview/content_management, and they reflect higher percentages of more than 50% of web pages powered by CMS platforms. Furthermore, they observe also that CMS platforms are growing, as fast as 12% year-over-year growth in some cases! The deviation between our analysis and W3Tech's analysis could be explained by a difference in research methodologies. You can read more about ours on the Methodology page. +

    In essence, this means that there are many CMS platforms available out there. The following picture shows a reduced view of the CMS landscape.

    - Figure 3. The top content management systems. + Figure 3. The top content management systems.
    Figure 3. The top content management systems.
    @@ -5906,7 +6518,7 @@

    - Figure 4. Percent of desktop and mobile websites that use a CMS. + Figure 4. Percent of desktop and mobile websites that use a CMS.
    Figure 4. Percent of desktop and mobile websites that use a CMS.
    @@ -5920,16 +6532,21 @@

    see this chapter's results spreadsheet.

    +

    + The CrUX and HTTP Archive datasets contain web pages powered by a mix of around 103 CMS platforms. Most of those platforms are very small in terms of relative market share. For the sake of our analysis, we will be focusing on the top CMS platforms in terms of their footprint on the web as reflected by the data. For a full analysis, see this chapter's results spreadsheethttps://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/edit#gid=0. +

    - Figure 5. Top CMS platforms as a percent of all CMS websites. + Figure 5. Top CMS platforms as a percent of all CMS websites.
    Figure 5. Top CMS platforms as a percent of all CMS websites.

    The most salient CMS platforms present in the datasets are shown above in Figure 5. WordPress comprises 74.19% of mobile and 73.47% of desktop CMS websites. Its dominance in the CMS landscape can be attributed to a number of factors that we'll discuss later, but it's a major player. Open source platforms like Drupal and Joomla, and closed SaaS offerings like Squarespace and Wix, round out the top 5 CMSs. The diversity of these platforms speak to the CMS ecosystem consisting of many platforms where user demographics and the website creation journey vary. What's also interesting is the long tail of small scale CMS platforms in the top 20. From enterprise offerings to proprietary applications developed in-house for industry specific use, content management systems provide the customizable infrastructure for groups to manage, publish, and do business on the web.

    -

    The WordPress project defines its mission as "democratizing publishing". Some of its main goals are ease of use and to make the software free and available for everyone to create content on the web. Another big component is the inclusive community the project fosters. In almost any major city in the world, one can find a group of people who gather regularly to connect, share, and code in an effort to understand and build on the WordPress platform. Attending local meetups and annual events as well as participating in web-based channels are some of the ways WordPress contributors, experts, businesses, and enthusiasts participate in its global community.

    +

    + The WordPress projecthttps://wordpress.org/about/ defines its mission as "democratizing publishing". Some of its main goals are ease of use and to make the software free and available for everyone to create content on the web. Another big component is the inclusive community the project fosters. In almost any major city in the world, one can find a group of people who gather regularly to connect, share, and code in an effort to understand and build on the WordPress platform. Attending local meetups and annual events as well as participating in web-based channels are some of the ways WordPress contributors, experts, businesses, and enthusiasts participate in its global community. +

    The low barrier of entry and resources to support users (online and in-person) with publishing on the platform and to develop extensions (plugins) and themes contribute to its popularity. There is also a thriving availability of and economy around WordPress plugins and themes that reduce the complexity of implementing sought after web design and functionality. Not only do these aspects drive its reach and adoption by newcomers, but also maintains its long-standing use over time.

    The open source WordPress platform is powered and supported by volunteers, the WordPress Foundation, and major players in the web ecosystem. With these factors in mind, WordPress as the leading CMS makes sense.

    How are CMS-powered sites built

    @@ -5939,14 +6556,14 @@

    HTML, CSS, JavaScript, and media (images and video). CMS platforms give users powerfully streamlined administrative capabilities to integrate these resources to create web experiences. While this is one of the most inclusive aspects of these applications, it could have some adverse effects on the wider web.

    - Figure 6. Distribution of CMS page weight. + Figure 6. Distribution of CMS page weight.
    Figure 6. Distribution of CMS page weight.
    - Figure 7. Distribution of CMS requests per page. + Figure 7. Distribution of CMS requests per page.
    Figure 7. Distribution of CMS requests per page.
    @@ -6062,20 +6679,23 @@

    another layer of complexity. Later in this chapter, we'll use data from CrUX to assess user experience in the CMS space.

    +

    + With our CMS experiences saturated with these resources, we must consider the impact this has on website visitors on the frontend- is their experience fast or slow? Additionally, when comparing mobile and desktop resource usage, the amount of requests and weight show little difference. This means that the same amount and weight of resources are powering both mobile and desktop CMS experiences. Variation in connection speed and mobile device quality adds another layer of complexityhttps://medinathoughts.com/2017/12/03/the-perils-of-mobile-web-performance-part-iii/. Later in this chapter, we'll use data from CrUX to assess user experience in the CMS space. +

    Third-party resources

    Let's highlight a particular subset of resources to assess their impact in the CMS landscape. Third-party resources are those from origins not belonging to the destination site's domain name or servers. They can be images, videos, scripts, or other resource types. Sometimes these resources are packaged in combination such as with embedding an iframe for example. Our data reveals that the median amount of 3rd party resources for both desktop and mobile are close.

    The median amount of 3rd party requests on mobile CMS pages is 15 and weigh 264.72 KB, while the median for these requests on desktop CMS pages is 16 and weigh 271.56 KB. (Note that this excludes 3P resources considered part of "hosting").

    - Figure 10. Distribution of third-party weight (KB) on CMS pages. + Figure 10. Distribution of third-party weight (KB) on CMS pages.
    Figure 10. Distribution of third-party weight (KB) on CMS pages.
    - Figure 11. Distribution of the number of third-party requests on CMS pages. + Figure 11. Distribution of the number of third-party requests on CMS pages.
    Figure 11. Distribution of the number of third-party requests on CMS pages.
    @@ -6085,7 +6705,7 @@

    Image stats

    - Figure 12. Distribution of image weight (KB) on CMS pages. + Figure 12. Distribution of image weight (KB) on CMS pages.
    Figure 12. Distribution of image weight (KB) on CMS pages.
    @@ -6098,15 +6718,22 @@

    Image st

    Which are the common formats found on mobile and desktop CMS pages? From our data JPG images on average are the most popular image format. PNG and GIF formats follow, while formats like SVG, ICO, and WebP trail significantly comprising approximately a little over 2% and 1%.

    - Figure 14. Adoption of image formats on CMS pages. + Figure 14. Adoption of image formats on CMS pages.
    Figure 14. Adoption of image formats on CMS pages.
    -

    Perhaps this segmentation isn't surprising given the common use cases for these image types. SVGs for logos and icons are common as are JPEGs ubiquitous. WebP is still a relatively new optimized format with growing browser adoption. It will be interesting to see how this impacts its use in the CMS space in the years to come.

    +

    + Perhaps this segmentation isn't surprising given the common use cases for these image types. SVGs for logos and icons are common as are JPEGs ubiquitous. WebP is still a relatively new optimized format with growing browser adoptionhttps://caniuse.com/#search=webp. It will be interesting to see how this impacts its use in the CMS space in the years to come. +

    User experience on CMS-powered websites

    Success as a web content creator is all about user experience. Factors such as resource usage and other statistics regarding how web pages are composed are important indicators of the quality of a given site in terms of the best practices followed while building it. However, we are ultimately interested in shedding some light on how are users actually experiencing the web when consuming and engaging with content generated by these platforms.

    -

    To achieve this, we turn our analysis towards some user-perceived performance metrics, which are captured in the CrUX dataset. These metrics relate in some ways to how we, as humans, perceive time.

    +

    + To achieve this, we turn our analysis towards some user-perceived performance metricshttps://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics, which are captured in the CrUX dataset. These metrics relate in some ways to how we, as humans, perceive timehttps://paulbakaus.com/tutorials/performance/the-illusion-of-speed/. +

    @@ -6144,10 +6771,12 @@

    First Contentful Paint

    -

    First Contentful Paint measures the time it takes from navigation until content such as text or an image is first displayed. A successful FCP experience, or one that can be qualified as "fast," entails how quickly elements in the DOM are loaded to assure the user that the website is loading successfully. Although a good FCP score is not a guarantee that the corresponding site offers a good UX, a bad FCP almost certainly does guarantee the opposite.

    +

    + First Contentful Painthttps://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. A successful FCP experience, or one that can be qualified as "fast," entails how quickly elements in the DOM are loaded to assure the user that the website is loading successfully. Although a good FCP score is not a guarantee that the corresponding site offers a good UX, a bad FCP almost certainly does guarantee the opposite. +

    - Figure 16. Average distribution of FCP experiences across CMSs. + Figure 16. Average distribution of FCP experiences across CMSs.
    Figure 16. Average distribution of FCP experiences across CMSs.
    @@ -6204,11 +6833,13 @@

    FCP in the CMS landscape trends mostly in the moderate range. The need for CMS platforms to query content from a database, send, and subsequently render it in the browser, could be a contributing factor to the delay that users experience. The resource loads we discussed in the previous sections could also play a role. In addition, some of these instances are on shared hosting or in environments that may not be optimized for performance, which could also impact the experience in the browser.

    WordPress shows notably moderate and slow FCP experiences on mobile and desktop. Wix sits strongly in moderate FCP experiences on its closed platform. TYPO3, an enterprise open-source CMS platform, has consistently fast experiences on both mobile and desktop. TYPO3 advertises built-in performance and scalability features that may have a positive impact for website visitors on the frontend.

    First Input Delay

    -

    First Input Delay (FID) measures the time from when a user first interacts with your site (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction. A "fast" FID from a user's perspective would be immediate feedback from their actions on a site rather than a stalled experience. This delay (a pain point) could correlate with interference from other aspects of the site loading when the user tries to interact with the site.

    +

    + First Input Delayhttps://developers.google.com/web/updates/2018/05/first-input-delay (FID) measures the time from when a user first interacts with your site (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction. A "fast" FID from a user's perspective would be immediate feedback from their actions on a site rather than a stalled experience. This delay (a pain point) could correlate with interference from other aspects of the site loading when the user tries to interact with the site. +

    FID in the CMS space generally trends on fast experiences for both desktop and mobile on average. However, what's notable is the significant difference between mobile and desktop experiences.

    - Figure 18. Average distribution of FID experiences across CMSs. + Figure 18. Average distribution of FID experiences across CMSs.
    Figure 18. Average distribution of FID experiences across CMSs.
    @@ -6266,34 +6897,42 @@

    Lighthouse scores

    Lighthouse is an open-source, automated tool designed to help developers assess and improve the quality of their websites. One key aspect of the tool is that it provides a set of audits to assess the status of a website in terms of performance, accessibility, progressive web apps, and more. For the purposes of this chapter, we are interested in two specific audits categories: PWA and accessibility.

    PWA

    -

    The term Progressive Web App (PWA) refers to web-based user experiences that are considered as being reliable, fast, and engaging. Lighthouse provides a set of audits which returns a PWA score between 0 (worst) and 1 (best). These audits are based on the Baseline PWA 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.

    +

    + The term Progressive Web App (PWA) refers to web-based user experiences that are considered as being reliablehttps://developers.google.com/web/progressive-web-apps#reliable, fasthttps://developers.google.com/web/progressive-web-apps#fast, and engaginghttps://developers.google.com/web/progressive-web-apps#engaging. Lighthouse provides a set of audits which returns a PWA score between 0 (worst) and 1 (best). These audits are based on the Baseline PWA Checklisthttps://developers.google.com/web/progressive-web-apps/checklist#baseline, 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. +

    - Figure 20. Distribution of Lighthouse PWA category scores for CMS pages. + Figure 20. Distribution of Lighthouse PWA category scores for CMS pages.
    Figure 20. Distribution of Lighthouse PWA category scores for CMS pages.
    - Figure 21. Median Lighthouse PWA category scores per CMS. + Figure 21. Median Lighthouse PWA category scores per CMS.
    Figure 21. Median Lighthouse PWA category scores per CMS.

    Accessibility

    -

    An accessible website is a site designed and developed so that people with disabilities can use them. Lighthouse provides a set of accessibility audits and it returns a weighted average of all of them (see Scoring Details for a full list of how each audit is weighted).

    +

    + An accessible website is a site designed and developed so that people with disabilities can use them. Lighthouse provides a set of accessibility audits and it returns a weighted average of all of them (see Scoring Detailshttps://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=1567011065 for a full list of how each audit is weighted). +

    Each accessibility audit is pass or fail, but unlike other Lighthouse audits, a page doesn't get points for partially passing an accessibility audit. For example, if some elements have screenreader-friendly names, but others don't, that page gets a 0 for the screenreader-friendly-names audit.

    - Figure 22. Distribution of Lighthouse accessibility category scores for CMS pages. + Figure 22. Distribution of Lighthouse accessibility category scores for CMS pages.
    Figure 22. Distribution of Lighthouse accessibility category scores for CMS pages.
    - Figure 23. Median Lighthouse accessibility category scores per CMS. + Figure 23. Median Lighthouse accessibility category scores per CMS.
    Figure 23. Median Lighthouse accessibility category scores per CMS.
    @@ -6436,88 +7075,82 @@

    CM - - -

    -
    -
    Figure 24. Adoption (number of mobile websites) of React and companion frameworks per CMS.
    -
    -

    We also see hosting providers and agencies offering Digital Experience Platforms (DXP) as holistic solutions using CMSs and other integrated technologies as a toolbox for enterprise customer-focused strategies. These innovations show an effort to create turn-key, CMS-based solutions that make it possible, simple, and easy by default for the users (and their end users) to get the best UX when creating and consuming the content of these platforms. The aim: good performance by default, feature richness, and excellent hosting environments.

    -

    Conclusions

    -

    The CMS space is of paramount importance. The large portion of the web these applications power and the critical mass of users both creating and encountering its pages on a variety of devices and connections should not be trivialized. We hope this chapter and the others found here in the Web Almanac inspire more research and innovation to help make the space better. Deep investigations would provide us better context about the strengths, weaknesses, and opportunities these platforms provide the web as a whole. Content management systems can make an impact on preserving the integrity of the open web. Let's keep moving them forward!

    -

    - -
    -

    Authors

    -
      -
    • - Renee Johnson avatar -
      - Renee Johnson - - - -
      - {{ localizedContributors['ernee'] | safe if localizedContributors['ernee']|length }} -
      + +
      -
      • + +
      Figure 24. Adoption (number of mobile websites) of React and companion frameworks per CMS.
      + +

      We also see hosting providers and agencies offering Digital Experience Platforms (DXP) as holistic solutions using CMSs and other integrated technologies as a toolbox for enterprise customer-focused strategies. These innovations show an effort to create turn-key, CMS-based solutions that make it possible, simple, and easy by default for the users (and their end users) to get the best UX when creating and consuming the content of these platforms. The aim: good performance by default, feature richness, and excellent hosting environments.

      +

      Conclusions

      +

      The CMS space is of paramount importance. The large portion of the web these applications power and the critical mass of users both creating and encountering its pages on a variety of devices and connections should not be trivialized. We hope this chapter and the others found here in the Web Almanac inspire more research and innovation to help make the space better. Deep investigations would provide us better context about the strengths, weaknesses, and opportunities these platforms provide the web as a whole. Content management systems can make an impact on preserving the integrity of the open web. Let's keep moving them forward!

      + +
      + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

      + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

      + -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":15,"title":"Compression","description":"Compression chapter of the 2019 Web Almanac covering HTTP compression, algorithms, content types, 1st party and 3rd party compression and opportunities.","authors":["paulcalvano"],"reviewers":["obto","yoavweiss"],"translators":null,"discuss":"1770","results":"https://docs.google.com/spreadsheets/d/1IK9kaScQr_sJUwZnWMiJcmHEYJV292C9DwCfXH6a50o/","queries":"15_Compression","published":"2019-11-11","last_updated":"2020-05-19","chapter":"compression"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 15 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Compression +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":15,"title":"Compression","description":"Compression chapter of the 2019 Web Almanac covering HTTP compression, algorithms, content types, 1st party and 3rd party compression and opportunities.","authors":["paulcalvano"],"reviewers":["obto","yoavweiss"],"translators":null,"discuss":"1770","results":"https://docs.google.com/spreadsheets/d/1IK9kaScQr_sJUwZnWMiJcmHEYJV292C9DwCfXH6a50o/","queries":"15_Compression","published":"2019-11-11","last_updated":"2020-05-19","chapter":"compression"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -6526,12 +7159,16 @@

    - + -
    {{ self.written_by_before() }} Paul Calvano{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} David Fox, {{ self.and() }} Yoav Weiss{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    HTTP compression is a technique that allows you to encode information using fewer bits than the original representation. When used for delivering web content, it enables web servers to reduce the amount of data transmitted to clients. This increases the efficiency of the client's available bandwidth, reduces page weight, and improves web performance.

    Compression algorithms are often categorized as lossy or lossless:

    @@ -6542,7 +7179,7 @@

    Media chapter.

    How HTTP compression works

    - When a client makes an HTTP request, it often includes an Accept-Encoding header to advertise the compression algorithms it is capable of decoding. The server can then select from one of the advertised encodings it supports and serve a compressed response. The compressed response would include a Content-Encoding header so that the client is aware of which compression was used. Additionally, a Content-Type header is often used to indicate the MIME type of the resource being served. + When a client makes an HTTP request, it often includes an Accept-Encodinghttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding header to advertise the compression algorithms it is capable of decoding. The server can then select from one of the advertised encodings it supports and serve a compressed response. The compressed response would include a Content-Encodinghttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding header so that the client is aware of which compression was used. Additionally, a Content-Typehttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type header is often used to indicate the MIME typehttps://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types of the resource being served.

    In the example below, the client advertised support for gzip, brotli, and deflate compression. The server decided to return a gzip compressed response containing a text/html document.

        > GET / HTTP/1.1
@@ -6554,11 +7191,21 @@ 
    Compression algorithms
    
-    
    IANA maintains a list of valid HTTP content encodings that can be used with the Accept-Encoding and Content-Encoding headers. These include gzip, deflate, br (brotli), as well as a few others. Brief descriptions of these algorithms are given below:
    
+    
    
+      IANA maintains a list of valid HTTP content encodingshttps://www.iana.org/assignments/http-parameters/http-parameters.xml#content-coding that can be used with the Accept-Encoding and Content-Encoding headers. These include gzip, deflate, br (brotli), as well as a few others. Brief descriptions of these algorithms are given below:
+    
    
     
     
    Approximately 38% of HTTP responses are delivered with text-based compression. This may seem like a surprising statistic, but keep in mind that it is based on all HTTP requests in the dataset. Some content, such as images, will not benefit from these compression algorithms. The table below summarizes the percentage of requests served with each content encoding.
    
     
    
@@ -6652,7 +7299,7 @@ 
    
       
-        Figure 2. Adoption of compression algorithms on desktop pages.
+        Figure 2. Adoption of compression algorithms on desktop pages.
       
       
       
    Figure 2. Adoption of compression algorithms on desktop pages.
    
@@ -6660,7 +7307,11 @@ 
    
     
    We can't determine the compression levels from any of the diagnostics collected by the HTTP Archive, but the best practice for compressing content is:
    
         
@@ -6669,7 +7320,7 @@ 
    
       
-        Figure 3. Top 25 compressed content types.
+        Figure 3. Top 25 compressed content types.
       
       
       
    Figure 3. Top 25 compressed content types.
    
@@ -6677,7 +7328,7 @@ 
    
       
-        Figure 4. Compressed content types, excluding top 8.
+        Figure 4. Compressed content types, excluding top 8.
       
       
       
    Figure 4. Compressed content types, excluding top 8.
    
@@ -6687,14 +7338,14 @@ 
    
       
-        Figure 5. Compression by content type for desktop.
+        Figure 5. Compression by content type for desktop.
       
       
       
    Figure 5. Compression by content type for desktop.
    
     
    
     
    
       
-        Figure 6. Compression by content type for mobile.
+        Figure 6. Compression by content type for mobile.
       
       
       
    Figure 6. Compression by content type for mobile.
    
@@ -6702,14 +7353,14 @@ 
    
       
-        Figure 7. Compression by content type as a percent for desktop.
+        Figure 7. Compression by content type as a percent for desktop.
       
       
       
    Figure 7. Compression by content type as a percent for desktop.
    
     
    
     
    
       
-        Figure 8. Compression by content type as a percent for mobile.
+        Figure 8. Compression by content type as a percent for mobile.
       
       
       
    Figure 8. Compression by content type as a percent for mobile.
    
@@ -6779,10 +7430,12 @@ 
    Figure 9. First-party versus third-party compression by device type.
     
    
     
    Identifying compression opportunities
    
-    
    Google's Lighthouse tool enables users to run a series of audits against web pages. The text compression audit evaluates whether a site can benefit from additional text-based compression. It does this by attempting to compress resources and evaluate whether an object's size can be reduced by at least 10% and 1,400 bytes. Depending on the score, you may see a compression recommendation in the results, with a list of specific resources that could be compressed.
    
+    
    
+      Google's Lighthousehttps://developers.google.com/web/tools/lighthouse tool enables users to run a series of audits against web pages. The text compression audithttps://developers.google.com/web/tools/lighthouse/audits/text-compression evaluates whether a site can benefit from additional text-based compression. It does this by attempting to compress resources and evaluate whether an object's size can be reduced by at least 10% and 1,400 bytes. Depending on the score, you may see a compression recommendation in the results, with a list of specific resources that could be compressed.
+    
    
     
    
       
-        Figure 10. Lighthouse compression suggestions
+        Figure 10. Lighthouse compression suggestions
       
       
       
    Figure 10. Lighthouse compression suggestions.
    
@@ -6790,7 +7443,7 @@ 
    HTTP Archive runs Lighthouse audits for each mobile page, we can aggregate the scores across all sites to learn how much opportunity there is to compress more content. Overall, 62% of websites are passing this audit and almost 23% of websites have scored below a 40. This means that over 1.2 million websites could benefit from enabling additional text based compression.
    
     
    
       
-        Figure 11. Lighthouse 'enable text compression' audit scores.
+        Figure 11. Lighthouse 'enable text compression' audit scores.
       
       
       
    Figure 11. Lighthouse "enable text compression" audit scores.
    
@@ -6798,7 +7451,7 @@ 
    
       
-        Figure 12. Lighthouse 'enable text compression' audit potential byte savings.
+        Figure 12. Lighthouse 'enable text compression' audit potential byte savings.
       
       
       
    Figure 12. Lighthouse "enable text compression" audit potential byte savings.
    
@@ -6807,50 +7460,73 @@ 
    
+        {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %}
+      
+    
    
     
-
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":16,"title":"Caching","description":"Caching chapter of the 2019 Web Almanac covering cache-control, expires, TTLs, validitaty, vary, set-cookies, AppCache, Service Workers and opportunities.","authors":["paulcalvano"],"reviewers":["obto","bkardell"],"translators":null,"discuss":"1771","results":"https://docs.google.com/spreadsheets/d/1mnq03DqrRBwxfDV05uEFETK0_hPbYOynWxZkV3tFgNk/","queries":"16_Caching","published":"2019-11-11","last_updated":"2020-05-19","chapter":"caching"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 16 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Caching +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":16,"title":"Caching","description":"Caching chapter of the 2019 Web Almanac covering cache-control, expires, TTLs, validitaty, vary, set-cookies, AppCache, Service Workers and opportunities.","authors":["paulcalvano"],"reviewers":["obto","bkardell"],"translators":null,"discuss":"1771","results":"https://docs.google.com/spreadsheets/d/1mnq03DqrRBwxfDV05uEFETK0_hPbYOynWxZkV3tFgNk/","queries":"16_Caching","published":"2019-11-11","last_updated":"2020-05-19","chapter":"caching"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -6859,19 +7535,26 @@

    - + -
    {{ self.written_by_before() }} Paul Calvano{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} David Fox, {{ self.and() }} Brian Kardell{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    Caching is a technique that enables the reuse of previously downloaded content. It provides a significant performance benefit by avoiding costly network requests and it also helps scale an application by reducing the traffic to a website's origin infrastructure. There's an old saying, "the fastest request is the one that you don't have to make," and caching is one of the key ways to avoid having to make requests.

    There are three guiding principles to caching web content: cache as much as you can, for as long as you can, as close as you can to end users.

    Cache as much as you can. When considering how much can be cached, it is important to understand whether a response is static or dynamic. Requests that are served as a static response are typically cacheable, as they have a one-to-many relationship between the resource and the users requesting it. Dynamically generated content can be more nuanced and require careful consideration.

    Cache for as long as you can. The length of time you would cache a resource is highly dependent on the sensitivity of the content being cached. A versioned JavaScript resource could be cached for a very long time, while a non-versioned resource may need a shorter cache duration to ensure users get a fresh version.

    Cache as close to end users as you can. Caching content close to the end user reduces download times by removing latency. For example, if a resource is cached on an end user's browser, then the request never goes out to the network and the download time is as fast as the machine's I/O. For first time visitors, or visitors that don't have entries in their cache, a CDN would typically be the next place a cached resource is returned from. In most cases, it will be faster to fetch a resource from a local cache or a CDN compared to an origin server.

    -

    Web architectures typically involve multiple tiers of caching. For example, an HTTP request may have the opportunity to be cached in:

    +

    + Web architectures typically involve multiple tiers of cachinghttps://blog.yoav.ws/tale-of-four-caches/. For example, an HTTP request may have the opportunity to be cached in: +

    -

    When a web browser sends a response to a client, it typically includes headers that indicate whether the resource is cacheable, how long to cache it for, and how old the resource is. RFC 7234 covers this in more detail in section 4.2 (Freshness) and 4.3 (Validation).

    +

    + When a web browser sends a response to a client, it typically includes headers that indicate whether the resource is cacheable, how long to cache it for, and how old the resource is. RFC 7234 covers this in more detail in section 4.2 (Freshness)https://tools.ietf.org/html/rfc7234#section-4.2 and 4.3 (Validation)https://tools.ietf.org/html/rfc7234#section-4.3. +

    The HTTP response headers typically used for conveying freshness lifetime are:

    • Cache-Control allows you to configure a cache lifetime duration (i.e. how long this is valid for).
      • @@ -6916,19 +7602,24 @@

      -

      The tool RedBot.org allows you to input a URL and see a detailed explanation of how the response would be cached based on these headers. For example, a test for the URL above would output the following:

      +

      + The tool RedBot.orghttps://redbot.org/ allows you to input a URL and see a detailed explanation of how the response would be cached based on these headers. For example, a test for the URL abovehttps://redbot.org/?uri=https%3A%2F%2Fhttparchive.org%2Fstatic%2Fjs%2Fmain.js would output the following: +

      - Figure 1. Cache-Control information from RedBot. + Figure 1. Cache-Control information from RedBot.
      Figure 1. Cache-Control information from RedBot.
      -

      If no caching headers are present in a response, then the client is permitted to heuristically cache the response. Most clients implement a variation of the RFC's suggested heuristic, which is 10% of the time since Last-Modified. However, some may cache the response indefinitely. So, it is important to set specific caching rules to ensure that you are in control of the cacheability.

      +

      + If no caching headers are present in a response, then the client is permitted to heuristically cache the responsehttps://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/. Most clients implement a variation of the RFC's suggested heuristic, which is 10% of the time since Last-Modified. However, some may cache the response indefinitely. So, it is important to set specific caching rules to ensure that you are in control of the cacheability. +

      72% of responses are served with a Cache-Control header, and 56% of responses are served with an Expires header. However, 27% of responses did not use either header, and therefore are subject to heuristic caching. This is consistent across both desktop and mobile sites.

      - Figure 2. Presence of HTTP Cache-Control and Expires headers. + Figure 2. Presence of HTTP Cache-Control and Expires headers.
      Figure 2. Presence of HTTP Cache-Control and Expires headers.
      @@ -6943,7 +7634,7 @@

      - Figure 3. Distribution of cacheable responses. + Figure 3. Distribution of cacheable responses.
      Figure 3. Distribution of cacheable responses.
      @@ -7058,7 +7749,7 @@

      - Figure 5. Distribution of cacheability by content type for desktop. + Figure 5. Distribution of cacheability by content type for desktop.
      Figure 5. Distribution of cacheability by content type for desktop.
      @@ -7066,7 +7757,7 @@

      - Figure 6. Distribution of cacheability by content type for mobile. + Figure 6. Distribution of cacheability by content type for mobile.
      Figure 6. Distribution of cacheability by content type for mobile.
      @@ -7084,13 +7775,15 @@

      - Figure 7. Usage of Cache-Control versus Expires headers. + Figure 7. Usage of Cache-Control versus Expires headers.
      Figure 7. Usage of Cache-Control versus Expires headers.

      Cache-Control directives

      -

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

      +

      + The HTTP/1.1 specificationhttps://tools.ietf.org/html/rfc7234#section-5.2.1 includes multiple directives that can be used in the Cache-Control response header and are detailed below. Note that multiple can be used in a single response. +

      @@ -7157,7 +7850,7 @@

      - Figure 9. Usage of Cache-Control directives on mobile. + Figure 9. Usage of Cache-Control directives on mobile.
      Figure 9. Usage of Cache-Control directives on mobile.
      @@ -7166,9 +7859,15 @@

      introduced in 2017 and is supported on Firefox and Safari. Its usage has grown to 3.4%, and it is widely used in Facebook and Google third-party responses. +
    • + The immutable directive is relatively new, introduced in 2017https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook and is supported on Firefox and Safarihttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility. Its usage has grown to 3.4%, and it is widely used in Facebook and Google third-party responseshttps://discuss.httparchive.org/t/cache-control-immutable-a-year-later/1195. +

    -

    Another interesting set of directives to show up in this list are pre-check and post-check, which are used in 2.2% of Cache-Control response headers (approximately 7.8 million responses). This pair of headers was introduced in Internet Explorer 5 to provide a background validation and was rarely implemented correctly by websites. 99.2% of responses using these headers had used the combination of pre-check=0 and post-check=0. When both of these directives are set to 0, then both directives are ignored. So, it seems these directives were never used correctly!

    +

    + Another interesting set of directives to show up in this list are pre-check and post-check, which are used in 2.2% of Cache-Control response headers (approximately 7.8 million responses). This pair of headers was introduced in Internet Explorer 5 to provide a background validationhttps://blogs.msdn.microsoft.com/ieinternals/2009/07/20/internet-explorers-cache-control-extensions/ and was rarely implemented correctly by websites. 99.2% of responses using these headers had used the combination of pre-check=0 and post-check=0. When both of these directives are set to 0, then both directives are ignored. So, it seems these directives were never used correctly! +

    In the long tail, there are more than 1,500 erroneous directives in use across 0.28% of responses. These are ignored by clients, and include misspellings such as "nocache", "s-max-age", "smax-age", and "maxage". There are also numerous non-existent directives such as "max-stale", "proxy-public", "surrogate-control", etc.

    Cache-Control: no-store, no-cache and max-age=0

    When a response is not cacheable, the Cache-Control no-store directive should be used. If this directive is not used, then the response is cacheable.

    @@ -7184,10 +7883,13 @@

    How do cache TTLs compare to resource age?

    So far we've talked about how web servers tell a client what is cacheable, and how long it has been cached for. When designing cache rules, it is also important to understand how old the content you are serving is.

    When you are selecting a cache TTL, ask yourself: "how often are you updating these assets?" and "what is their content sensitivity?". For example, if a hero image is going to be modified infrequently, then cache it with a very long TTL. If you expect a JavaScript resource to change frequently, then version it and cache it with a long TTL or cache it with a shorter TTL.

    -

    The graph below illustrates the relative age of resources by content type, and you can read a more detailed analysis here. HTML tends to be the content type with the shortest age, and a very large % of traditionally cacheable resources (scripts, CSS, and fonts) are older than one year!

    +

    + The graph below illustrates the relative age of resources by content type, and you can read a more detailed analysis herehttps://discuss.httparchive.org/t/analyzing-resource-age-by-content-type/1659. HTML tends to be the content type with the shortest age, and a very large % of traditionally cacheable resources (scripts, CSS, and fonts) are older than one year! +

    - Figure 10. Resource age distribution by content type. + Figure 10. Resource age distribution by content type.
    Figure 10. Resource age distribution by content type.
    @@ -7265,7 +7967,7 @@

    Overall, 65% of responses are served with a Last-Modified header, 42% are served with an ETag, and 38% use both. However, 30% of responses include neither a Last-Modified or ETag header.

    - Figure 12. Adoption of validating freshness via Last-Modified and ETa` headers for desktop websites. + Figure 12. Adoption of validating freshness via Last-Modified and ETa` headers for desktop websites.
    Figure 12. Adoption of validating freshness via Last-Modified and ETag headers for desktop websites.
    @@ -7293,7 +7995,7 @@

    - Figure 13. Invalid date formats in response headers. + Figure 13. Invalid date formats in response headers.
    Figure 13. Invalid date formats in response headers.
    @@ -7315,7 +8017,7 @@

    The graph below details the popularity for the top 10 Vary header values. Accept-Encoding accounts for 90% of Vary's use, with User-Agent (11%), Origin (9%), and Accept (3%) making up much of the rest.

    - Figure 14. Vary header usage. + Figure 14. Vary header usage.
    Figure 14. Vary header usage.
    @@ -7324,30 +8026,43 @@

    - Figure 15. Chrome Dev Tools for a cached resource. + Figure 15. Chrome Dev Tools for a cached resource.
    Figure 15. Chrome Dev Tools for a cached resource.

    -

    But what happens if you have a Set-Cookie on a response? According to RFC 7234 Section 8, the presence of a Set-Cookie response header does not inhibit caching. This means that a cached entry might contain a Set-Cookie if it was cached with one. The RFC goes on to recommend that you should configure appropriate Cache-Control headers to control how responses are cached.

    +

    + But what happens if you have a Set-Cookie on a response? According to RFC 7234 Section 8https://tools.ietf.org/html/rfc7234#section-8, the presence of a Set-Cookie response header does not inhibit caching. This means that a cached entry might contain a Set-Cookie if it was cached with one. The RFC goes on to recommend that you should configure appropriate Cache-Control headers to control how responses are cached. +

    One of the risks of caching responses with Set-Cookie is that the cookie values can be stored and served to subsequent requests. Depending on the cookie's purpose, this could have worrying results. For example, if a login cookie or a session cookie is present in a shared cache, then that cookie might be reused by another client. One way to avoid this is to use the Cache-Control private directive, which only permits the response to be cached by the client browser.

    3% of cacheable responses contain a Set-Cookie header. Of those responses, only 18% use the private directive. The remaining 82% include 5.3 million HTTP responses that include a Set-Cookie which can be cached by public and private cache servers.

    - Figure 16. Cacheable responses of Set-Cookie responses. + Figure 16. Cacheable responses of Set-Cookie responses.
    Figure 16. Cacheable responses of Set-Cookie responses.

    AppCache and service workers

    -

    The Application Cache or AppCache is a feature of HTML5 that allows developers to specify resources the browser should cache and make available to offline users. This feature was deprecated and removed from web standards, and browser support has been diminishing. In fact, when its use is detected, Firefox v44+ recommends that developers should use service workers instead. Chrome 70 restricts the Application Cache to secure context only. The industry has moved more towards implementing this type of functionality with service workers - and browser support has been rapidly growing for it.

    -

    In fact, one of the HTTP Archive trend reports shows the adoption of service workers shown below:

    +

    + The Application Cache or AppCache is a feature of HTML5 that allows developers to specify resources the browser should cache and make available to offline users. This feature was deprecated and removed from web standardshttps://html.spec.whatwg.org/multipage/offline.html#offline, and browser support has been diminishing. In fact, when its use is detected, Firefox v44+ recommends that developers should use service workers insteadhttps://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers. Chrome 70 restricts the Application Cache to secure context onlyhttps://www.chromestatus.com/feature/5714236168732672. The industry has moved more towards implementing this type of functionality with service workers - and browser supporthttps://caniuse.com/#feat=serviceworkers has been rapidly growing for it. +

    +

    + In fact, one of the HTTP Archive trend reports shows the adoption of service workershttps://httparchive.org/reports/progressive-web-apps#swControlledPages shown below: +

    - Figure 17. Timeseries of service worker controlled pages. + Figure 17. Timeseries of service worker controlled pages. -
    Figure 17. Timeseries of service worker controlled pages. (Source: HTTP Archive)
    +
    + Figure 17. Timeseries of service worker controlled pages. (Source: HTTP Archivehttps://httparchive.org/reports/progressive-web-apps#swControlledPages) +

    Adoption is still below 1% of websites, but it has been steadily increasing since January 2017. The Progressive Web App chapter discusses this more, including the fact that it is used a lot more than this graph suggests due to its usage on popular sites, which are only counted once in above graph.

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

    @@ -7431,18 +8146,22 @@

    Figure 19. Number of websites using AppCache versus service worker usage by HTTP/HTTPS.

    Identifying caching opportunities

    -

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

    +

    + Google's Lighthousehttps://developers.google.com/web/tools/lighthouse tool enables users to run a series of audits against web pages, and the cache policy audithttps://developers.google.com/web/tools/lighthouse/audits/cache-policy evaluates whether a site can benefit from additional caching. It does this by comparing the content age (via the Last-Modified header) to the cache TTL and estimating the probability that the resource would be served from cache. Depending on the score, you may see a caching recommendation in the results, with a list of specific resources that could be cached. +

    - Figure 20. Lighthouse report highlighting potential cache policy improvements. + Figure 20. Lighthouse report highlighting potential cache policy improvements.
    Figure 20. Lighthouse report highlighting potential cache policy improvements.
    -

    Lighthouse computes a score for each audit, ranging from 0% to 100%, and those scores are then factored into the overall scores. The caching score is based on potential byte savings. When we examine the Lighthouse results, we can get a perspective of how many sites are doing well with their cache policies.

    +

    + Lighthouse computes a score for each audit, ranging from 0% to 100%, and those scores are then factored into the overall scores. The caching scorehttps://developers.google.com/web/tools/lighthouse/audits/cache-policy is based on potential byte savings. When we examine the Lighthouse results, we can get a perspective of how many sites are doing well with their cache policies. +

    - Figure 21. Distribution of Lighthouse scores for the 'Uses Long Cache TTL' audit for mobile web pages. + Figure 21. Distribution of Lighthouse scores for the 'Uses Long Cache TTL' audit for mobile web pages.
    Figure 21. Distribution of Lighthouse scores for the "Uses Long Cache TTL" audit for mobile web pages.
    @@ -7451,58 +8170,83 @@

    - Figure 22. Distribution of potential byte savings from the Lighthouse caching audit. + Figure 22. Distribution of potential byte savings from the Lighthouse caching audit.
    Figure 22. Distribution of potential byte savings from the Lighthouse caching audit.

    Conclusion

    Caching is an incredibly powerful feature that allows browsers, proxies and other intermediaries (such as CDNs) to store web content and serve it to end users. The performance benefits of this are significant, since it reduces round trip times and minimizes costly network requests.

    -

    Caching is also a very complex topic. There are numerous HTTP response headers that can convey freshness as well as validate cached entries, and Cache-Control directives provide a tremendous amount of flexibility and control. However, developers should be cautious about the additional opportunities for mistakes that it comes with. Regularly auditing your site to ensure that cacheable resources are cached appropriately is recommended, and tools like Lighthouse and REDbot do an excellent job of helping to simplify the analysis.

    -
    +

    + Caching is also a very complex topic. There are numerous HTTP response headers that can convey freshness as well as validate cached entries, and Cache-Control directives provide a tremendous amount of flexibility and control. However, developers should be cautious about the additional opportunities for mistakes that it comes with. Regularly auditing your site to ensure that cacheable resources are cached appropriately is recommended, and tools like Lighthousehttps://developers.google.com/web/tools/lighthouse and REDbothttps://redbot.org/ do an excellent job of helping to simplify the analysis. +

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":17,"title":"CDN","description":"CDN chapter of the 2019 Web Almanac covering CDN adoption and usage, RTT & TLS management, HTTP/2 adoption, caching and common library and content CDNs.","authors":["andydavies","colinbendell"],"reviewers":["yoavweiss","paulcalvano","pmeenan","enygren"],"translators":null,"discuss":"1772","results":"https://docs.google.com/spreadsheets/d/1Y7kAxjxUl8puuTToe6rL3kqJLX1ftOb0nCcD8m3lZBw/","queries":"17_CDN","published":"2019-11-11","last_updated":"2020-05-19","chapter":"cdn"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 17 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - CDN +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":17,"title":"CDN","description":"CDN chapter of the 2019 Web Almanac covering CDN adoption and usage, RTT & TLS management, HTTP/2 adoption, caching and common library and content CDNs.","authors":["andydavies","colinbendell"],"reviewers":["yoavweiss","paulcalvano","pmeenan","enygren"],"translators":null,"discuss":"1772","results":"https://docs.google.com/spreadsheets/d/1Y7kAxjxUl8puuTToe6rL3kqJLX1ftOb0nCcD8m3lZBw/","queries":"17_CDN","published":"2019-11-11","last_updated":"2020-05-19","chapter":"cdn"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -7511,14 +8255,20 @@

    - + -
    {{ self.written_by_before() }} Andy Davies, {{ self.and() }} Colin Bendell{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Yoav Weiss, Paul Calvano, Patrick Meenan, {{ self.and() }} Erik Nygren{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    -

    "Use a Content Delivery Network" was one of Steve Souders original recommendations for making web sites load faster. It's advice that remains valid today, and in this chapter of the Web Almanac we're going to explore how widely Steve's recommendation has been adopted, how sites are using Content Delivery Networks (CDNs), and some of the features they're using.

    +

    + "Use a Content Delivery Network" was one of Steve Souders original recommendationshttp://stevesouders.com/examples/rules.php for making web sites load faster. It's advice that remains valid today, and in this chapter of the Web Almanac we're going to explore how widely Steve's recommendation has been adopted, how sites are using Content Delivery Networks (CDNs), and some of the features they're using. +

    Fundamentally, CDNs reduce latency—the time it takes for packets to travel between two points on a network, say from a visitor's device to a server—and latency is a key factor in how quickly pages load.

    A CDN reduces latency in two ways: by serving content from locations that are closer to the user and second, by terminating the TCP connection closer to the end user.

    Historically, CDNs were used to cache, or copy, bytes so that the logical path from the user to the bytes becomes shorter. A file that is requested by many people can be retrieved once from the origin (your server) and then stored on a server closer to the user, thus saving transfer time.

    @@ -7528,7 +8278,9 @@

    Introd
  • Using a CDN to proxy dynamic content (base HTML page, API responses, etc.) can take advantage of both the reduced latency between the browser and the CDN's own network back to the origin.
  • Some CDNs offer transformations that optimize pages so they download and render more quickly, or optimize images so they're the appropriate size (both dimensions and file size) for the device on which they're going to be viewed.
  • From a security perspective, malicious traffic and bots can be filtered out by a CDN before the requests even reach the origin, and their wide customer base means CDNs can often see and react to new threats sooner.
    • -
  • The rise of edge computing allows sites to run their own code close to their visitors, both improving performance and reducing the load on the origin.
    • +
  • + The rise of edge computinghttps://en.wikipedia.org/wiki/Edge_computing allows sites to run their own code close to their visitors, both improving performance and reducing the load on the origin. +

    • Finally, CDNs also help sites to adopt new technologies without requiring changes at the origin, for example HTTP/2, TLS 1.3, and/or IPv6 can be enabled from the edge to the browser, even if the origin servers don't support it yet.

    Caveats and disclaimers

    @@ -7536,10 +8288,14 @@

    There are many limits to the testing methodology used for the Web Almanac. These include:

    • Simulated network latency: The Web Almanac uses a dedicated network connection that synthetically shapes traffic.
      • -
    • Single geographic location: Tests are run from a single datacenter and cannot test the geographic distribution of many CDN vendors.
      • +
    • + Single geographic location: Tests are run from a single datacenterhttps://httparchive.org/faq#how-is-the-data-gathered and cannot test the geographic distribution of many CDN vendors. +
    • Cache effectiveness: Each CDN uses proprietary technology and many, for security reasons, do not expose cache performance.
    • Localization and internationalization: Just like geographic distribution, the effects of language and geo-specific domains are also opaque to the testing.
      • -
    • CDN detection is primarily done through DNS resolution and HTTP headers. Most CDNs use a DNS CNAME to map a user to an optimal datacenter. However, some CDNs use AnyCast IPs or direct A+AAAA responses from a delegated domain which hide the DNS chain. In other cases, websites use multiple CDNs to balance between vendors which is hidden from the single-request pass of WebPageTest. All of this limits the effectiveness in the measurements.
      • +
    • + CDN detectionhttps://github.com/WPO-Foundation/wptagent/blob/master/internal/optimization_checks.py#L51 is primarily done through DNS resolution and HTTP headers. Most CDNs use a DNS CNAME to map a user to an optimal datacenter. However, some CDNs use AnyCast IPs or direct A+AAAA responses from a delegated domain which hide the DNS chain. In other cases, websites use multiple CDNs to balance between vendors which is hidden from the single-request pass of WebPageTest. All of this limits the effectiveness in the measurements. +

    Most importantly, these results reflect a potential utilization but do not reflect actual impact. YouTube is more popular than "ShoesByColin" yet both will appear as equal value when comparing utilization.

    With this in mind, there are a few intentional statistics that were not measured with the context of a CDN:

    @@ -7556,7 +8312,7 @@

    Historically, CDNs were used exclusively for static resources like CSS, JavaScript, and images. These resources would likely be versioned (include a unique number in the path) and cached long-term. In this way we should expect to see higher adoption of CDNs on sub-domains or sibling domains compared to the base HTML domains. The traditional design pattern would expect that www.shoesbycolin.com would serve HTML directly from a datacenter (or origin) while static.shoesbycolin.com would use a CDN.

    - Figure 1. CDN usage vs. origin-hosted resources. + Figure 1. CDN usage vs. origin-hosted resources.
    Figure 1. CDN usage vs. origin-hosted resources.
    @@ -7570,7 +8326,7 @@

    Note: This does not reflect traffic or usage, only the number of sites using them.

    - Most popular CDNs used to serve base HTML pages + Most popular CDNs used to serve base HTML pages
    Figure 2: HTML CDN usage.
    @@ -7695,7 +8451,7 @@

    - Most popular CDNs used for resources served from a sub-domain + Most popular CDNs used for resources served from a sub-domain
    Figure 4. Sub-domain resource CDN usage.
    @@ -7820,7 +8576,7 @@

    - Most popular CDNs used by third-party resources + Most popular CDNs used by third-party resources
    Figure 6. Third-party resource CDN usage.
    @@ -7943,7 +8699,10 @@

    Figure 7. Top 25 resource CDNs for third-party requests.

    RTT and TLS management

    -

    CDNs can offer more than simple caching for website performance. Many CDNs also support a pass-through mode for dynamic or personalized content when an organization has a legal or other business requirement prohibiting the content from being cached. Utilizing a CDN's physical distribution enables increased performance for TCP RTT for end users. As others have noted, reducing RTT is the most effective means to improve web page performance compared to increasing bandwidth.

    +

    + CDNs can offer more than simple caching for website performance. Many CDNs also support a pass-through mode for dynamic or personalized content when an organization has a legal or other business requirement prohibiting the content from being cached. Utilizing a CDN's physical distribution enables increased performance for TCP RTT for end users. As others have notedhttps://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/, reducing RTT is the most effective means to improve web page performancehttps://hpbn.co/primer-on-latency-and-bandwidth/ compared to increasing bandwidth. +

    Using a CDN in this way can improve page performance in two ways:

    1. @@ -7958,7 +8717,7 @@

      A word of caution when interpreting these charts: it is important to focus on orders of magnitude when comparing vendors as there are many factors that impact the actual TLS negotiation performance. These tests were completed from a single datacenter under controlled conditions and do not reflect the variability of the internet and user experiences.

      - Distribution of TLS negotiation time for initial HTML request broken down by CDN + Distribution of TLS negotiation time for initial HTML request broken down by CDN
      Figure 8. HTML TLS negotiation time.
      @@ -8131,25 +8890,36 @@

      - Distribution of TLS negotiation time for site resources broken down by CDN + Distribution of TLS negotiation time for site resources broken down by CDN
      Figure 10. Resource TLS negotiation time.

      TLS handshake performance is impacted by a number of factors. These include RTT, TLS record size, and TLS certificate size. While RTT has the biggest impact on the TLS handshake, the second largest driver for TLS performance is the TLS certificate size.

      -

      During the first round trip of the TLS handshake, the server attaches its certificate. This certificate is then verified by the client before proceeding. In this certificate exchange, the server might include the certificate chain by which it can be verified. After this certificate exchange, additional keys are established to encrypt the communication. However, the length and size of the certificate can negatively impact the TLS negotiation performance, and in some cases, crash client libraries.

      - The certificate exchange is at the foundation of the TLS handshake and is usually handled by isolated code paths so as to minimize the attack surface for exploits. Because of its low level nature, buffers are usually not dynamically allocated, but fixed. In this way, we cannot simply assume that the client can handle an unlimited-sized certificate. For example, OpenSSL CLI tools and Safari can successfully negotiate against https://10000-sans.badssl.comTLS handshakehttps://hpbn.co/transport-layer-security-tls/#tls-handshake, the server attaches its certificate. This certificate is then verified by the client before proceeding. In this certificate exchange, the server might include the certificate chain by which it can be verified. After this certificate exchange, additional keys are established to encrypt the communication. However, the length and size of the certificate can negatively impact the TLS negotiation performance, and in some cases, crash client libraries. +

      +

      + The certificate exchange is at the foundation of the TLS handshake and is usually handled by isolated code paths so as to minimize the attack surface for exploits. Because of its low level nature, buffers are usually not dynamically allocated, but fixed. In this way, we cannot simply assume that the client can handle an unlimited-sized certificate. For example, OpenSSL CLI tools and Safari can successfully negotiate against https://10000-sans.badssl.comhttps://10000-sans.badssl.com. Yet, Chrome and Firefox fail because of the size of the certificate.

      While extreme sizes of certificates can cause failures, even sending moderately large certificates has a performance impact. A certificate can be valid for one or more hostnames which are are listed in the Subject-Alternative-Name (SAN). The more SANs, the larger the certificate. It is the processing of these SANs during verification that causes performance to degrade. To be clear, performance of certificate size is not about TCP overhead, rather it is about processing performance of the client.

      Technically, TCP slow start can impact this negotiation but it is very improbable. TLS record length is limited to 16 KB, which fits into a typical initial congestion window of 10. While some ISPs might employ packet splicers, and other tools fragment congestion windows to artificially throttle bandwidth, this isn't something that a website owner can change or manipulate.

      Many CDNs, however, depend on shared TLS certificates and will list many customers in the SAN of a certificate. This is often necessary because of the scarcity of IPv4 addresses. Prior to the adoption of Server-Name-Indicator (SNI) by end users, the client would connect to a server, and only after inspecting the certificate, would the client hint which hostname the user user was looking for (using the Host header in HTTP). This results in a 1:1 association of an IP address and a certificate. If you are a CDN with many physical locations, each location may require a dedicated IP, further aggravating the exhaustion of IPv4 addresses. Therefore, the simplest and most efficient way for CDNs to offer TLS certificates for websites that still have users that don't support SNI is to offer a shared certificate.

      -

      According to Akamai, the adoption of SNI is still not 100% globally. Fortunately there has been a rapid shift in recent years. The biggest culprits are no longer Windows XP and Vista, but now Android apps, bots, and corporate applications. Even at 99% adoption, the remaining 1% of 3.5 billion users on the internet can create a very compelling motivation for website owners to require a non-SNI certificate. Put another way, a pure play website can enjoy a virtually 100% SNI adoption among standard web browsers. Yet, if the website is also used to support APIs or WebViews in apps, particularly Android apps, this distribution can drop rapidly.

      -

      Most CDNs balance the need for shared certificates and performance. Most cap the number of SANs between 100 and 150. This limit often derives from the certificate providers. For example, LetsEncrypt, DigiCert, and GoDaddy all limit SAN certificates to 100 hostnames while Comodo's limit is 2,000. This, in turn, allows some CDNs to push this limit, cresting over 800 SANs on a single certificate. There is a strong negative correlation of TLS performance and the number of SANs on a certificate.

      +

      + According to Akamai, the adoption of SNI is still not 100% globallyhttps://datatracker.ietf.org/meeting/101/materials/slides-101-maprg-update-on-tls-sni-and-ipv6-client-adoption-00. Fortunately there has been a rapid shift in recent years. The biggest culprits are no longer Windows XP and Vista, but now Android apps, bots, and corporate applications. Even at 99% adoption, the remaining 1% of 3.5 billion users on the internet can create a very compelling motivation for website owners to require a non-SNI certificate. Put another way, a pure play website can enjoy a virtually 100% SNI adoption among standard web browsers. Yet, if the website is also used to support APIs or WebViews in apps, particularly Android apps, this distribution can drop rapidly. +

      +

      + Most CDNs balance the need for shared certificates and performance. Most cap the number of SANs between 100 and 150. This limit often derives from the certificate providers. For example, LetsEncrypthttps://letsencrypt.org/docs/rate-limits/, DigiCerthttps://www.websecurity.digicert.com/security-topics/san-ssl-certificates, and GoDaddyhttps://www.godaddy.com/web-security/multi-domain-san-ssl-certificate all limit SAN certificates to 100 hostnames while Comodohttps://comodosslstore.com/comodo-mdc-ssl.aspx's limit is 2,000. This, in turn, allows some CDNs to push this limit, cresting over 800 SANs on a single certificate. There is a strong negative correlation of TLS performance and the number of SANs on a certificate. +

      - Figure 11. TLS SAN count for HTML. + Figure 11. TLS SAN count for HTML.
      Figure 11. TLS SAN count for HTML.
      @@ -8321,7 +9091,7 @@

      - Figure 13. Resource SAN count (p50). + Figure 13. Resource SAN count (p50).
      Figure 13. Resource SAN count (p50).
      @@ -8503,7 +9273,7 @@

      TLS ad

      In addition to using a CDN for TLS and RTT performance, CDNs are often used to ensure patching and adoption of TLS ciphers and TLS versions. In general, the adoption of TLS on the main HTML page is much higher for websites that use a CDN. Over 76% of HTML pages are served with TLS compared to the 62% from origin-hosted pages.

      - Figure 15. HTML TLS version adoption (CDN vs. origin). + Figure 15. HTML TLS version adoption (CDN vs. origin).
      Figure 15. HTML TLS version adoption (CDN vs. origin).
      @@ -8511,14 +9281,14 @@

      TLS ad

      Each CDN offers different rates of adoption for both TLS and the relative ciphers and versions offered. Some CDNs are more aggressive and roll out these changes to all customers whereas other CDNs require website owners to opt-in to the latest changes and offer change-management to facilitate these ciphers and versions.

      - Figure 16. HTML TLS adoption by CDN. + Figure 16. HTML TLS adoption by CDN.
      Figure 16. HTML TLS adoption by CDN.
      - Figure 17. Third-party TLS adoption by CDN. + Figure 17. Third-party TLS adoption by CDN.
      Figure 17. Third-party TLS adoption by CDN.
      @@ -8528,7 +9298,7 @@

      TLS ad

      It is important to emphasize that Chrome used in the Web Almanac will bias to the latest TLS versions and ciphers offered by the host. Also, these web pages were crawled in July 2019 and reflect the adoption of websites that have enabled the newer versions.

      - Figure 18. HTML TLS version by CDN. + Figure 18. HTML TLS version by CDN.
      Figure 18. HTML TLS version by CDN.
      @@ -8540,14 +9310,14 @@

      HT

      Note: All requests were made with the latest version of Chrome which supports HTTP/2. When only HTTP/1.1 is reported, this would indicate either unencrypted (non-TLS) servers or servers that don't support HTTP/2.

      - Figure 19. HTTP/2 adoption (CDN vs. origin). + Figure 19. HTTP/2 adoption (CDN vs. origin).
      Figure 19. HTTP/2 adoption (CDN vs. origin).
      - Figure 20. HTML adoption of HTTP/2. + Figure 20. HTML adoption of HTTP/2.
      Figure 20. HTML adoption of HTTP/2.
      @@ -8749,7 +9519,7 @@

      HT

      - Figure 22. HTML/2 adoption: third-party resources. + Figure 22. HTML/2 adoption: third-party resources.
      Figure 22. HTML/2 adoption: third-party resources.
      @@ -8957,7 +9727,7 @@

      Another useful tool is the use of the Vary HTTP header. This header instructs both CDNs and browsers how to fragment a cache. The Vary header allows an origin to indicate that there are multiple representations of a resource, and the CDN should cache each variation separately. The most common example is compression. Declaring a resource as Vary: Accept-Encoding allows the CDN to cache the same content, but in different forms like uncompressed, with gzip, or Brotli. Some CDNs even do this compression on the fly so as to keep only one copy available. This Vary header likewise also instructs the browser how to cache the content and when to request new content.

      - Breakdown of Vary header values for HTML content served from a CDN + Breakdown of Vary header values for HTML content served from a CDN
      Figure 24. Usage of Vary for HTML served from CDNs.
      @@ -8967,7 +9737,7 @@

      In a similar way, Vary: Cookie usually indicates that content that will change based on the logged-in state of the user or other personalization.

      - Figure 25. Comparison of Vary usage for HTML and resources served from origin and CDN. + Figure 25. Comparison of Vary usage for HTML and resources served from origin and CDN.
      Figure 25. Comparison of Vary usage for HTML and resources served from origin and CDN.
      @@ -8984,7 +9754,7 @@

      The s-maxage directive informs proxies for how long they may cache a response. Across the Web Almanac dataset, jsDelivr is the only CDN where a high level of usage was seen across multiple resources—this isn't surprising given jsDelivr's role as a public CDN for libraries. Usage across other CDNs seems to be driven by individual customers, for example third-party scripts or SaaS providers using that particular CDN.

      - Figure 26. Adoption of s-maxage across CDN responses. + Figure 26. Adoption of s-maxage across CDN responses.
      Figure 26. Adoption of s-maxage across CDN responses.
      @@ -8997,7 +9767,7 @@

      - Figure 27. Usage of public content CDNs. + Figure 27. Usage of public content CDNs.
      Figure 27. Usage of public content CDNs.
      @@ -9008,79 +9778,73 @@

      Conclusion

      Steve Souders' recommendation to use a CDN remains as valid today as it was 12 years ago, yet only 20% of sites serve their HTML content via a CDN, and only 40% are using a CDN for resources, so there's plenty of opportunity for their usage to grow further.

      There are some aspects of CDN adoption that aren't included in this analysis, sometimes this was due to the limitations of the dataset and how it's collected, in other cases new research questions emerged during the analysis.

      As the web continues to evolve, CDN vendors innovate, and sites use new practices CDN adoption remains an area rich for further research in future editions of the Web Almanac.

      -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":18,"title":"Page Weight","description":"Page Weight chapter of the 2019 Web Almanac covering why page weight matters, bandwidth, complex pages, page weight over time, page requests, and file formats.","authors":["tammyeverts","khempenius"],"reviewers":["paulcalvano"],"translators":null,"discuss":"1773","results":"https://docs.google.com/spreadsheets/d/1nWOo8efqDgzmA0wt1ipplziKhlReAxnVCW1HkjuFAxU/","queries":"18_PageWeight","published":"2019-11-11","last_updated":"2020-03-01","chapter":"page-weight"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 18 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Page Weight +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":18,"title":"Page Weight","description":"Page Weight chapter of the 2019 Web Almanac covering why page weight matters, bandwidth, complex pages, page weight over time, page requests, and file formats.","authors":["tammyeverts","khempenius"],"reviewers":["paulcalvano"],"translators":null,"discuss":"1773","results":"https://docs.google.com/spreadsheets/d/1nWOo8efqDgzmA0wt1ipplziKhlReAxnVCW1HkjuFAxU/","queries":"18_PageWeight","published":"2019-11-11","last_updated":"2020-03-01","chapter":"page-weight"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -9089,12 +9853,16 @@

    - + -
    {{ self.written_by_before() }} Tammy Everts, {{ self.and() }} Katie Hempenius{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Paul Calvano{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    The median web page is around 1900KB in size and contains 74 requests. That doesn't sound too bad, right?

    Here's the issue with medians: they mask problems. By definition, they focus only on the middle of the distribution. We need to consider percentiles at both extremes to get an understanding of the bigger picture.

    @@ -9103,9 +9871,14 @@

    -

    Check out Tim Kadlec's fascinating online calculator, What Does My Site Cost?, which calculates the cost—in dollars and Gross National Income per capita—of your pages in countries around the world. It's an eye-opener. For instance, Amazon's home page, which at the time of writing weighs 2.79MB, costs 1.89% of the daily per capita GNI of Mauritania. How global is the world wide web when people in some parts of the world would have to give up a day's wages just to visit a few dozen pages?

    +

    + Check out Tim Kadlec's fascinating online calculator, What Does My Site Cost?https://whatdoesmysitecost.com/, which calculates the cost—in dollars and Gross National Income per capita—of your pages in countries around the world. It's an eye-opener. For instance, Amazon's home page, which at the time of writing weighs 2.79MB, costs 1.89% of the daily per capita GNI of Mauritania. How global is the world wide web when people in some parts of the world would have to give up a day's wages just to visit a few dozen pages? +

    More bandwidth isn't a magic bullet for web performance

    -

    Even if more people had access to better devices and cheaper connections, that wouldn't be a complete solution. Double the bandwidth doesn't mean twice as fast. In fact, it has been demonstrated that increasing bandwidth by up to 1,233% only made pages 55% faster.

    +

    + Even if more people had access to better devices and cheaper connections, that wouldn't be a complete solution. Double the bandwidth doesn't mean twice as fast. In fact, it has been demonstratedhttps://developer.akamai.com/blog/2015/06/09/heres-why-more-bandwidth-isnt-magic-bullet-web-performance that increasing bandwidth by up to 1,233% only made pages 55% faster. +

    The problem is latency. Most of our networking protocols require a lot of round-trips, and each of those round trips imposes a latency penalty. For as long as latency continues to be a performance problem (which is to say, for the foreseeable future), the major performance culprit will continue to be that a typical web page today contains a hundred or so assets hosted on dozens of different servers. Many of these assets are unoptimized, unmeasured, unmonitored—and therefore unpredictable.

    What types of assets does the HTTP Archive track, and how much do they matter?

    Here's a quick glossary of the page composition metrics that the HTTP Archive tracks, and how much they matter in terms of performance and user experience:

    @@ -9128,7 +9901,9 @@

    Bigger, complex pages can be bad for your business

    -

    Let's assume you're not a heartless monster who doesn't care about your site's visitors. But if you are, you should know that serving bigger, more complex pages hurts you, too. That was one of the findings of a Google-led machine learning study that gathered over a million beacons' worth of real user data from retail sites.

    +

    + Let's assume you're not a heartless monster who doesn't care about your site's visitors. But if you are, you should know that serving bigger, more complex pages hurts you, too. That was one of the findings of a Google-led machine learning studyhttps://www.thinkwithgoogle.com/marketing-resources/experience-design/mobile-page-speed-load-time/ that gathered over a million beacons' worth of real user data from retail sites. +

    There were three really important takeaways from this research:

    1. @@ -9140,7 +9915,7 @@

      - Figure 1. Converted sessions vs non-converted sessions. + Figure 1. Converted sessions vs non-converted sessions.
      Figure 1. Converted sessions vs non-converted sessions.
      @@ -9150,7 +9925,7 @@

      - Figure 2. Conversion rate dropping off as scripts increase. + Figure 2. Conversion rate dropping off as scripts increase.
      Figure 2. Conversion rate dropping off as scripts increase.
      @@ -9426,7 +10201,9 @@

      Figure 6. Change in desktop page weight since 2018. -

      For a longer-term perspective on how page weight has changed over time, check out this timeseries graph from HTTP Archive. Median page size has grown at a fairly constant rate since the HTTP Archive started tracking this metric in November 2010 and the increase in page weight observed over the past year is consistent with this.

      +

      + For a longer-term perspective on how page weight has changed over time, check out this timeseries graphhttps://httparchive.org/reports/page-weight#bytesTotal from HTTP Archive. Median page size has grown at a fairly constant rate since the HTTP Archive started tracking this metric in November 2010 and the increase in page weight observed over the past year is consistent with this. +

      Page requests

      The median desktop page makes 74 requests, and the median mobile page makes 69. Images and JavaScript account for the majority of these requests. There was no significant change in the quantity or distribution of requests over the last year.

      Mobile

      @@ -9634,7 +10411,7 @@

      - Figure 10. Cumulative distribution function of GIF file sizes. + Figure 10. Cumulative distribution function of GIF file sizes.
      Figure 10. Cumulative distribution function of GIF file sizes.
      @@ -9772,7 +10549,11 @@

      Figure 12. File size by image format for images > 1024 bytes. -

      The low file size of PNG images compared to JPEG images may seem surprising. JPEG uses lossy compression. Lossy compression results in data loss, which makes it possible to achieve smaller file sizes. Meanwhile, PNG uses lossless compression. This does not result in data loss, which this produces higher-quality, but larger images. However, this difference in file sizes is probably a reflection of the popularity of PNGs for iconography due to their transparency support, rather than differences in their encoding and compression.

      +

      + The low file size of PNG images compared to JPEG images may seem surprising. JPEG uses lossy compressionhttps://en.wikipedia.org/wiki/Lossy_compression. Lossy compression results in data loss, which makes it possible to achieve smaller file sizes. Meanwhile, PNG uses lossless compressionhttps://en.wikipedia.org/wiki/Lossless_compression. This does not result in data loss, which this produces higher-quality, but larger images. However, this difference in file sizes is probably a reflection of the popularity of PNGs for iconography due to their transparency support, rather than differences in their encoding and compression. +

      File size by media format

      MP4 is overwhelmingly the most popular video format on the web today. In terms of popularity, it is followed by WebM and MPEG-TS respectively.

      Unlike some of the other tables in this data set, this one has mostly happy takeaways. Videos are consistently smaller on mobile, which is great to see. In addition, the median size of an MP4 video is a very reasonable 18 KB on mobile and 39 KB on desktop. The median numbers for WebM are even better but they should be taken with a grain of salt: the duplicate measurement of 0.29 KB across multiple clients and percentiles is a little bit suspicious. One possible explanation is that identical copies of one very tiny WebM video is included on many pages. Of the three formats, MPEG-TS consistently has the highest file size across all percentiles. This may be related to the fact that it was released in 1995, making it the oldest of these three media formats.

      @@ -9874,79 +10655,73 @@
      Conclusion

      Over the past year, pages increased in size by roughly 10%. Brotli, performance budgets, and basic image optimization best practices are probably the three techniques which show the most promise for maintaining or improving page weight while also being widely applicable and fairly easy to implement. That being said, in recent years, improvements in page weight have been more constrained by the low adoption of best practices than by the technology itself. In other words, although there are many existing techniques for improving page weight, they won't make a difference if they aren't put to use.

      -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":19,"title":"Resource Hints","description":"Resource Hints chapter of the 2019 Web Almanac covering usage of dns-prefetch, preconnect, preload, prefetch, priority hints, and native lazy loading.","authors":["khempenius"],"reviewers":["andydavies","bazzadp","yoavweiss"],"translators":null,"discuss":"1774","results":"https://docs.google.com/spreadsheets/d/14QBP8XGkMRfWRBbWsoHm6oDVPkYhAIIpfxRn4iOkbUU/","queries":"19_Resource_Hints","published":"2019-11-11","last_updated":"2020-03-02","chapter":"resource-hints"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 19 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Resource Hints +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":19,"title":"Resource Hints","description":"Resource Hints chapter of the 2019 Web Almanac covering usage of dns-prefetch, preconnect, preload, prefetch, priority hints, and native lazy loading.","authors":["khempenius"],"reviewers":["andydavies","bazzadp","yoavweiss"],"translators":null,"discuss":"1774","results":"https://docs.google.com/spreadsheets/d/14QBP8XGkMRfWRBbWsoHm6oDVPkYhAIIpfxRn4iOkbUU/","queries":"19_Resource_Hints","published":"2019-11-11","last_updated":"2020-03-02","chapter":"resource-hints"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -9955,15 +10730,23 @@

    - + -
    {{ self.written_by_before() }} Katie Hempenius{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Andy Davies, Barry Pollard, {{ self.and() }} Yoav Weiss{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    -

    Resource hints provide "hints" to the browser about what resources will be needed soon. The action that the browser takes as a result of receiving this hint will vary depending on the type of resource hint; different resource hints kick off different actions. When used correctly, they can improve page performance by giving a head start to important anticipated actions.

    -

    Examples of performance improvements as a result of resource hints include:

    +

    + Resource hintshttps://www.w3.org/TR/resource-hints/ provide "hints" to the browser about what resources will be needed soon. The action that the browser takes as a result of receiving this hint will vary depending on the type of resource hint; different resource hints kick off different actions. When used correctly, they can improve page performance by giving a head start to important anticipated actions. +

    +

    + Exampleshttps://youtu.be/YJGCZCaIZkQ?t=1956 of performance improvements as a result of resource hints include: +

    • Jabong decreased Time to Interactive by 1.5 seconds by preloading critical scripts.
    • Barefoot Wine decreased Time to Interactive of future pages by 2.7 seconds by prefetching visible links.
      • @@ -9974,32 +10757,34 @@

      dns-prefetch

      - The role of dns-prefetch is to initiate an early DNS lookup. It's useful for completing the DNS lookup for third-parties. For example, the DNS lookup of a CDN, font provider, or third-party API. + The role of dns-prefetchhttps://developer.mozilla.org/en-US/docs/Learn/Performance/dns-prefetch is to initiate an early DNS lookup. It's useful for completing the DNS lookup for third-parties. For example, the DNS lookup of a CDN, font provider, or third-party API.

      preconnect

      - preconnect initiates an early connection, including DNS lookup, TCP handshake, and TLS negotiation. This hint is useful for setting up a connection with a third party. The uses of preconnect are very similar to those of dns-prefetch, but preconnect has less browser support. However, if you don't need IE 11 support, preconnect is probably a better choice. + preconnecthttps://web.dev/uses-rel-preconnect initiates an early connection, including DNS lookup, TCP handshake, and TLS negotiation. This hint is useful for setting up a connection with a third party. The uses of preconnect are very similar to those of dns-prefetch, but preconnect has less browser support. However, if you don't need IE 11 support, preconnect is probably a better choice.

      preload

      - The preload hint initiates an early request. This is useful for loading important resources that would otherwise be discovered late by the parser. For example, if an important image is only discoverable once the browser has received and parsed the stylesheet, it may make sense to preload the image. + The preloadhttps://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf hint initiates an early request. This is useful for loading important resources that would otherwise be discovered late by the parser. For example, if an important image is only discoverable once the browser has received and parsed the stylesheet, it may make sense to preload the image.

      prefetch

      - prefetch initiates a low-priority request. It's useful for loading resources that will be used on the subsequent (rather than current) page load. A common use of prefetch is loading resources that the application "predicts" will be used on the next page load. These predictions could be based on signals like user mouse movement or common user flows/journeys. + prefetchhttps://calendar.perfplanet.com/2018/all-about-prefetching/ initiates a low-priority request. It's useful for loading resources that will be used on the subsequent (rather than current) page load. A common use of prefetch is loading resources that the application "predicts" will be used on the next page load. These predictions could be based on signals like user mouse movement or common user flows/journeys.

      Syntax

      - 97% of resource hint usage relied on using the <link> tag to specify a resource hint. For example: + 97% of resource hint usage relied on using the <link>https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link tag to specify a resource hint. For example: 

      <link rel="prefetch" href="shopping-cart.js">
      -

      Only 3% of resource hint usage used HTTP headers to specify resource hints. For example:

      +

      + Only 3% of resource hint usage used HTTP headershttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link to specify resource hints. For example: + 

      Link: <https://example.com/shopping-cart.js>; rel=prefetch

      Because the usage of resource hints in HTTP headers is so low, the remainder of this chapter will focus solely on analyzing the usage of resource hints in conjunction with the <link> tag. However, it's worth noting that in future years, usage of resource hints in HTTP headers may increase as HTTP/2 Push is adopted. This is due to the fact that HTTP/2 Push has repurposed the HTTP preload Link header as a signal to push resources.

      Resource hints

      @@ -10039,8 +10824,13 @@

      Figure 1. Adoption of resource hints.
      -

      The relative popularity of dns-prefetch is unsurprising; it's a well-established API (it first appeared in 2009), it is supported by all major browsers, and it is the most "inexpensive" of all resource hints. Because dns-prefetch only performs DNS lookups, it consumes very little data, and therefore there is very little downside to using it. dns-prefetch is most useful in high-latency situations.

      -

      That being said, if a site does not need to support IE11 and below, switching from dns-prefetch to preconnect is probably a good idea. In an era where HTTPS is ubiquitous, preconnect yields greater performance improvements while still being inexpensive. Note that unlike dns-prefetch, preconnect not only initiates the DNS lookup, but also the TCP handshake and TLS negotiation. The certificate chain is downloaded during TLS negotiation and this typically costs a couple of kilobytes.

      +

      + The relative popularity of dns-prefetch is unsurprising; it's a well-established API (it first appeared in 2009https://caniuse.com/#feat=link-rel-dns-prefetch), it is supported by all major browsers, and it is the most "inexpensive" of all resource hints. Because dns-prefetch only performs DNS lookups, it consumes very little data, and therefore there is very little downside to using it. dns-prefetch is most useful in high-latency situations. +

      +

      + That being said, if a site does not need to support IE11 and below, switching from dns-prefetch to preconnect is probably a good idea. In an era where HTTPS is ubiquitous, preconnect yields greater performance improvements while still being inexpensive. Note that unlike dns-prefetch, preconnect not only initiates the DNS lookup, but also the TCP handshake and TLS negotiation. The certificate chainhttps://knowledge.digicert.com/solution/SO16297.html is downloaded during TLS negotiation and this typically costs a couple of kilobytes. +

      prefetch is used by 3% of sites, making it the least widely used resource hint. This low usage may be explained by the fact that prefetch is useful for improving subsequent—rather than current—page loads. Thus, it will be overlooked if a site is only focused on improving their landing page, or the performance of the first page viewed.

      @@ -10087,7 +10877,10 @@

      The crossorigin attribute

      -

      Most "traditional" resources fetched on the web (images, stylesheets, and scripts) are fetched without opting in to Cross-Origin Resource Sharing (CORS). That means that if those resources are fetched from a cross-origin server, by default their contents cannot be read back by the page, due to the same-origin policy.

      +

      + Most "traditional" resources fetched on the web (images, stylesheets, and scripts) are fetched without opting in to Cross-Origin Resource Sharing (CORShttps://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). That means that if those resources are fetched from a cross-origin server, by default their contents cannot be read back by the page, due to the same-origin policy. +

      In some cases, the page can opt-in to fetch the resource using CORS if it needs to read its content. CORS enables the browser to "ask permission" and get access to those cross-origin resources.

      For newer resource types (e.g. fonts, fetch() requests, ES modules), the browser defaults to requesting those resources using CORS, failing the requests entirely if the server does not grant it permission to access them.

      @@ -10127,7 +10920,10 @@

      The as attribute

      -

      as is an attribute that should be used with the preload resource hint to inform the browser of the type (e.g. image, script, style, etc.) of the requested resource. This helps the browser correctly prioritize the request and apply the correct Content Security Policy (CSP). CSP is a security mechanism, expressed via HTTP header, that helps mitigate the impact of XSS and other malicious attacks by declaring a safelist of trusted sources; only content from these sources can be rendered or executed.

      +

      + as is an attribute that should be used with the preload resource hint to inform the browser of the type (e.g. image, script, style, etc.) of the requested resource. This helps the browser correctly prioritize the request and apply the correct Content Security Policy (CSPhttps://developers.google.com/web/fundamentals/security/csp). CSP is a security mechanism, expressed via HTTP header, that helps mitigate the impact of XSS and other malicious attacks by declaring a safelist of trusted sources; only content from these sources can be rendered or executed. +

      88%
      Figure 4. The percent of resource hint instances using the as attribute.
      @@ -10136,7 +10932,9 @@

      The future

      At the moment, there are no proposals to expand the current set of resource hints. However, priority hints and native lazy loading are two proposed technologies that are similar in spirit to resource hints in that they provide APIs for optimizing the loading process.

      Priority Hints

      -

      Priority hints are an API for expressing the fetch priority of a resource: high, low, or auto. They can be used with a wide range of HTML tags: specifically <image>, <link>, <script>, and <iframe>.

      +

      + Priority hintshttps://wicg.github.io/priority-hints/ are an API for expressing the fetch priority of a resource: high, low, or auto. They can be used with a wide range of HTML tags: specifically <image>, <link>, <script>, and <iframe>. + 

      <carousel>
@@ -10152,58 +10950,85 @@ 
      0.04%
      Figure 6. The rate of priority hint adoption.
      -

      Priority hints are implemented and can be tested via a feature flag in Chromium browsers versions 70 and up. Given that it is still an experimental technology, it is unsurprising that it is only used by 0.04% of sites.

      +

      + Priority hints are implementedhttps://www.chromestatus.com/feature/5273474901737472 and can be tested via a feature flag in Chromium browsers versions 70 and up. Given that it is still an experimental technology, it is unsurprising that it is only used by 0.04% of sites. +

      85% of priority hint usage is with <img> tags. Priority hints are mostly used to deprioritize resources: 72% of usage is importance="low"; 28% of usage is importance="high".

      Native lazy loading

      -

      Native lazy loading is a native API for deferring the load of off-screen images and iframes. This frees up resources during the initial page load and avoids loading assets that are never used. Previously, this technique could only be achieved through third-party JavaScript libraries.

      -

      The API for native lazy loading looks like this: <img src="cat.jpg" loading="lazy">.

      +

      + Native lazy loadinghttps://web.dev/native-lazy-loading is a native API for deferring the load of off-screen images and iframes. This frees up resources during the initial page load and avoids loading assets that are never used. Previously, this technique could only be achieved through third-party JavaScript libraries. +

      +

      The API for native lazy loading looks like this: <img src="cat.jpg">.

      Native lazy loading is available in browsers based on Chromium 76 and up. The API was announced too late for it to be included in the dataset for this year's Web Almanac, but it is something to keep an eye out for in the coming year.

      Conclusion

      Overall, this data seems to suggest that there is still room for further adoption of resource hints. Most sites would benefit from adopting and/or switching to preconnect from dns-prefetch. A much smaller subset of sites would benefit from adopting prefetch and/or preload. There is greater nuance in successfully using prefetch and preload, which constrains its adoption to a certain extent, but the potential payoff is also greater. HTTP/2 Push and the maturation of machine learning technologies is also likely to increase the adoption of preload and prefetch.

      -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":20,"title":"HTTP/2","description":"HTTP/2 chapter of the 2019 Web Almanac covering adoption and impact of HTTP/2, HTTP/2 Push, HTTP/2 Issues, and HTTP/3.","authors":["bazzadp"],"reviewers":["bagder","rmarx","dotjs"],"translators":null,"discuss":"1775","results":"https://docs.google.com/spreadsheets/d/1z1gdS3YVpe8J9K3g2UdrtdSPhRywVQRBz5kgBeqCnbw/","queries":"20_HTTP_2","published":"2019-11-11","last_updated":"2020-05-05","chapter":"http2"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 20 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - HTTP/2 +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":20,"title":"HTTP/2","description":"HTTP/2 chapter of the 2019 Web Almanac covering adoption and impact of HTTP/2, HTTP/2 Push, HTTP/2 Issues, and HTTP/3.","authors":["bazzadp"],"reviewers":["bagder","rmarx","dotjs"],"translators":null,"discuss":"1775","results":"https://docs.google.com/spreadsheets/d/1z1gdS3YVpe8J9K3g2UdrtdSPhRywVQRBz5kgBeqCnbw/","queries":"20_HTTP_2","published":"2019-11-11","last_updated":"2020-05-05","chapter":"http2"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -10212,15 +11037,22 @@

    - + -
    {{ self.written_by_before() }} Barry Pollard{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Daniel Stenberg, Robin Marx, {{ self.and() }} Andrew Galloni{{ self.reviewed_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    Introduction

    HTTP/2 was the first major update to the main transport protocol of the web in nearly 20 years. It arrived with a wealth of expectations: it promised a free performance boost with no downsides. More than that, we could stop doing all the hacks and work arounds that HTTP/1.1 forced us into, due to its inefficiencies. Bundling, spriting, inlining, and even sharding domains would all become anti-patterns in an HTTP/2 world, as improved performance would be provided by default.

    -

    This meant that even those without the skills and resources to concentrate on web performance would suddenly have performant websites. However, the reality has been, as ever, a little more nuanced than that. It has been over four years since the formal approval of HTTP/2 as a standard in May 2015 as RFC 7540, so now is a good time to look over how this relatively new technology has fared in the real world.

    +

    + This meant that even those without the skills and resources to concentrate on web performance would suddenly have performant websites. However, the reality has been, as ever, a little more nuanced than that. It has been over four years since the formal approval of HTTP/2 as a standard in May 2015 as RFC 7540https://tools.ietf.org/html/rfc7540, so now is a good time to look over how this relatively new technology has fared in the real world. +

    What is HTTP/2?

    For those not familiar with the technology, a bit of background is helpful to make the most of the metrics and findings in this chapter. Up until recently, HTTP has always been a text-based protocol. An HTTP client like a web browser opened a TCP connection to a server, and then sent an HTTP command like GET /index.html to ask for a resource.

    This was enhanced in HTTP/1.0 to add HTTP headers, so various pieces of metadata could be included in addition to the request, such as what browser it is, the formats it understands, etc. These HTTP headers were also text-based and separated by newline characters. Servers parsed the incoming requests by reading the request and any HTTP headers line by line, and then the server responded with its own HTTP response headers in addition to the actual resource being requested.

    @@ -10228,7 +11060,10 @@

    That in itself brings its own issues as TCP connections take time and resources to set up and get to full efficiency, especially when using HTTPS, which requires additional steps to set up the encryption. HTTP/1.1 improved this somewhat, allowing reuse of TCP connections for subsequent requests, but still did not solve the parallelization issue.

    Despite HTTP being text-based, the reality is that it was rarely used to transport text, at least in its raw format. While it was true that HTTP headers were still text, the payloads themselves often were not. Text files like HTML, JS, and CSS are usually compressed for transport into a binary format using gzip, brotli, or similar. Non-text files like images and videos are served in their own formats. The whole HTTP message is then often wrapped in HTTPS to encrypt the messages for security reasons.

    So, the web had basically moved on from text-based transport a long time ago, but HTTP had not. One reason for this stagnation was because it was so difficult to introduce any breaking changes to such a ubiquitous protocol like HTTP (previous efforts had tried and failed). Many routers, firewalls, and other middleboxes understood HTTP and would react badly to major changes to it. Upgrading them all to support a new version was simply not possible.

    -

    In 2009, Google announced that they were working on an alternative to the text-based HTTP called SPDY, which has since been deprecated. This would take advantage of the fact that HTTP messages were often encrypted in HTTPS, which prevents them being read and interfered with en route.

    +

    + In 2009, Google announced that they were working on an alternative to the text-based HTTP called SPDYhttps://www.chromium.org/spdy, which has since been deprecated. This would take advantage of the fact that HTTP messages were often encrypted in HTTPS, which prevents them being read and interfered with en route. +

    Google controlled one of the most popular browsers (Chrome) and some of the most popular websites (Google, YouTube, Gmail…etc.) - so both ends of the connection when both were used together. Google's idea was to pack HTTP messages into a proprietary format, send them across the internet, and then unpack them on the other side. The proprietary format, SPDY, was binary-based rather than text-based. This solved some of the main performance problems with HTTP/1.1 by allowing more efficient use of a single TCP connection, negating the need to open the six connections that had become the norm under HTTP/1.1.

    By using SPDY in the real world, they were able to prove that it was more performant for real users, and not just because of some lab-based experimental results. After rolling out SPDY to all Google websites, other servers and browser started implementing it, and then it was time to standardize this proprietary format into an internet standard, and thus HTTP/2 was born.

    HTTP/2 has the following key concepts:

    @@ -10240,24 +11075,41 @@

  • Header compression
  • Push
    • -

    Binary format means that HTTP/2 messages are wrapped into frames of a pre-defined format, making HTTP messages easier to parse and would no longer require scanning for newline characters. This is better for security as there were a number of exploits for previous versions of HTTP. It also means HTTP/2 connections can be multiplexed. Different frames for different streams can be sent on the same connection without interfering with each other as each frame includes a stream identifier and its length. Multiplexing allows much more efficient use of a single TCP connection without the overhead of opening additional connections. Ideally we would open a single connection per domain—or even for multiple domains!

    +

    + Binary format means that HTTP/2 messages are wrapped into frames of a pre-defined format, making HTTP messages easier to parse and would no longer require scanning for newline characters. This is better for security as there were a number of exploitshttps://www.owasp.org/index.php/HTTP_Response_Splitting for previous versions of HTTP. It also means HTTP/2 connections can be multiplexed. Different frames for different streams can be sent on the same connection without interfering with each other as each frame includes a stream identifier and its length. Multiplexing allows much more efficient use of a single TCP connection without the overhead of opening additional connections. Ideally we would open a single connection per domain—or even for multiple domainshttps://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/! +

    Having separate streams does introduce some complexities along with some potential benefits. HTTP/2 needs the concept of flow control to allow the different streams to send data at different rates, whereas previously, with only one response in flight at any one time, this was controlled at a connection level by TCP flow control. Similarly, prioritization allows multiple requests to be sent together, but with the most important requests getting more of the bandwidth.

    -

    Finally, HTTP/2 introduced two new concepts: header compression and HTTP/2 push. Header compression allowed those text-based HTTP headers to be sent more efficiently, using an HTTP/2-specific HPACK format for security reasons. HTTP/2 push allowed more than one response to be sent in answer to a request, enabling the server to "push" resources before a client was even aware it needed them. Push was supposed to solve the performance workaround of having to inline resources like CSS and JavaScript directly into HTML to prevent holding up the page while those resources were requested. With HTTP/2 the CSS and JavaScript could remain as external files but be pushed along with the initial HTML, so they were available immediately. Subsequent page requests would not push these resources, since they would now be cached, and so would not waste bandwidth.

    -

    This whistle-stop tour of HTTP/2 gives the main history and concepts of the newish protocol. As should be apparent from this explanation, the main benefit of HTTP/2 is to address performance limitations of the HTTP/1.1 protocol. There were also security improvements as well - perhaps most importantly in being to address performance issues of using HTTPS since HTTP/2, even over HTTPS, is often much faster than plain HTTP. Other than the web browser packing the HTTP messages into the new binary format, and the web server unpacking it at the other side, the core basics of HTTP itself stayed roughly the same. This means web applications do not need to make any changes to support HTTP/2 as the browser and server take care of this. Turning it on should be a free performance boost, therefore adoption should be relatively easy. Of course, there are ways web developers can optimize for HTTP/2 to take full advantage of how it differs.

    +

    + Finally, HTTP/2 introduced two new concepts: header compression and HTTP/2 push. Header compression allowed those text-based HTTP headers to be sent more efficiently, using an HTTP/2-specific HPACKhttps://tools.ietf.org/html/rfc7541 format for security reasons. HTTP/2 push allowed more than one response to be sent in answer to a request, enabling the server to "push" resources before a client was even aware it needed them. Push was supposed to solve the performance workaround of having to inline resources like CSS and JavaScript directly into HTML to prevent holding up the page while those resources were requested. With HTTP/2 the CSS and JavaScript could remain as external files but be pushed along with the initial HTML, so they were available immediately. Subsequent page requests would not push these resources, since they would now be cached, and so would not waste bandwidth. +

    +

    + This whistle-stop tour of HTTP/2 gives the main history and concepts of the newish protocol. As should be apparent from this explanation, the main benefit of HTTP/2 is to address performance limitations of the HTTP/1.1 protocol. There were also security improvements as well - perhaps most importantly in being to address performance issues of using HTTPS since HTTP/2, even over HTTPS, is often much faster than plain HTTPhttps://www.httpvshttps.com/. Other than the web browser packing the HTTP messages into the new binary format, and the web server unpacking it at the other side, the core basics of HTTP itself stayed roughly the same. This means web applications do not need to make any changes to support HTTP/2 as the browser and server take care of this. Turning it on should be a free performance boost, therefore adoption should be relatively easy. Of course, there are ways web developers can optimize for HTTP/2 to take full advantage of how it differs. +

    Adoption of HTTP/2

    -

    As mentioned above, internet protocols are often difficult to adopt since they are ingrained into so much of the infrastructure that makes up the internet. This makes introducing any changes slow and difficult. IPv6 for example has been around for 20 years but has struggled to be adopted.

    +

    + As mentioned above, internet protocols are often difficult to adopt since they are ingrained into so much of the infrastructure that makes up the internet. This makes introducing any changes slow and difficult. IPv6 for example has been around for 20 years but has struggled to be adoptedhttps://www.google.com/intl/en/ipv6/statistics.html. +

    95%
    Figure 1. The percent of global users who can use HTTP/2.
    -

    HTTP/2 however, was different as it was effectively hidden in HTTPS (at least for the browser uses cases), removing barriers to adoption as long as both the browser and server supported it. Browser support has been very strong for some time and the advent of auto updating evergreen browsers has meant that an estimated 95% of global users now support HTTP/2.

    +

    + HTTP/2 however, was different as it was effectively hidden in HTTPS (at least for the browser uses cases), removing barriers to adoption as long as both the browser and server supported it. Browser support has been very strong for some time and the advent of auto updating evergreen browsers has meant that an estimated 95% of global users now support HTTP/2https://caniuse.com/#feat=http2. +

    Our analysis is sourced from the HTTP Archive, which tests approximately 5 million of the top desktop and mobile websites in the Chrome browser. (Learn more about our methodology.)

    - Figure 2. HTTP/2 usage by request. + Figure 2. HTTP/2 usage by request. -
    Figure 2. HTTP/2 usage by request. (Source: HTTP Archive)
    +
    + Figure 2. HTTP/2 usage by request. (Source: HTTP Archivehttps://httparchive.org/reports/state-of-the-web#h2) +

    The results show that HTTP/2 usage is now the majority protocol-an impressive feat just 4 short years after formal standardization! Looking at the breakdown of all HTTP versions by request we see the following:

    @@ -10311,9 +11163,14 @@

    QUIC (soon to be standardized as HTTP/3 separately, so these requests are currently listed under HTTP/2, but we'll look at other ways of measuring that later in this chapter.

    +

    + At present, HTTP Archive does not track HTTP over QUIChttps://www.chromium.org/quic (soon to be standardized as HTTP/3 separately, so these requests are currently listed under HTTP/2, but we'll look at other ways of measuring that later in this chapter. +

    Looking at the number of requests will skew the results somewhat due to popular requests. For example, many sites load Google Analytics, which does support HTTP/2, and so would show as an HTTP/2 request, even if the embedding site itself does not support HTTP/2. On the other hand, popular websites tend to support HTTP/2 are also underrepresented in the above stats as they are only measured once (e.g. "google.com" and "obscuresite.com" are given equal weighting). There are lies, damn lies, and statistics.

    -

    However, our findings are corroborated by other sources, like Mozilla's telemetry, which looks at real-world usage through the Firefox browser.

    +

    + However, our findings are corroborated by other sources, like Mozilla's telemetryhttps://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&measure=HTTP_RESPONSE_VERSION, which looks at real-world usage through the Firefox browser. +

    @@ -10478,7 +11335,9 @@

    Figure 6. Servers used for HTTP/2.

    -

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

    +

    + Nginx provides package repositories that allow ease of installing or upgrading to the latest version, so it is no surprise to see it leading the way here. Cloudflare is the most popular CDN and enables HTTP/2 by default, so again it is not surprising to see it hosts a large percentage of HTTP/2 sites. Incidently, Cloudflare uses a heavily customizedhttps://blog.cloudflare.com/nginx-structural-enhancements-for-http-2-performance/ version of nginx as their web server. After those, we see Apache at around 20% of usage, followed by some servers who choose to hide what they are, and then the smaller players such as LiteSpeed, IIS, Google Servlet Engine, and openresty, which is nginx based. +

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

    @@ -10621,33 +11480,50 @@

    Figure 8. Percentage installs of each server used to provide HTTP/2.

    It's clear that Apache and IIS fall way behind with 18% and 14% of their installed based supporting HTTP/2, which has to be (at least in part) a consequence of it being more difficult to upgrade them. A full operating system upgrade is often required for many servers to get this support easily. Hopefully this will get easier as new versions of operating systems become the norm.

    -

    None of this is a comment on the HTTP/2 implementations here (I happen to think Apache has one of the best implementations), but more about the ease of enabling HTTP/2 in each of these servers-or lack thereof.

    +

    + None of this is a comment on the HTTP/2 implementations here (I happen to think Apache has one of the best implementationshttps://twitter.com/tunetheweb/status/988196156697169920?s=20), but more about the ease of enabling HTTP/2 in each of these servers-or lack thereof. +

    Impact of HTTP/2

    The impact of HTTP/2 is much more difficult to measure, especially using the HTTP Archive methodology. Ideally, sites should be crawled with both HTTP/1.1 and HTTP/2 and the difference measured, but that is not possible with the statistics we are investigating here. Additionally, measuring whether the average HTTP/2 site is faster than the average HTTP/1.1 site introduces too many other variables that require a more exhaustive study than we can cover here.

    One impact that can be measured is in the changing use of HTTP now that we are in an HTTP/2 world. Multiple connections were a workaround with HTTP/1.1 to allow a limited form of parallelization, but this is in fact the opposite of what usually works best with HTTP/2. A single connection reduces the overhead of TCP setup, TCP slow start, and HTTPS negotiation, and it also allows the potential of cross-request prioritization.

    - Figure 9. TCP connections per page. + Figure 9. TCP connections per page. -
    Figure 9. TCP connections per page. (Source: HTTP Archive)
    +
    + Figure 9. TCP connections per page. (Source: HTTP Archivehttps://httparchive.org/reports/state-of-the-web#tcp) +

    HTTP Archive measures the number of TCP connections per page, and that is dropping steadily as more sites support HTTP/2 and use its single connection instead of six separate connections.

    - Figure 10. Total requests per page. + Figure 10. Total requests per page. -
    Figure 10. Total requests per page. (Source: HTTP Archive)
    +
    + Figure 10. Total requests per page. (Source: HTTP Archivehttps://httparchive.org/reports/state-of-the-web#reqTotal) +
    -

    Bundling assets to obtain fewer requests was another HTTP/1.1 workaround that went by many names: bundling, concatenation, packaging, spriting, etc. This is less necessary when using HTTP/2 as there is less overhead with requests, but it should be noted that requests are not free in HTTP/2, and those that experimented with removing bundling completely have noticed a loss in performance. Looking at the number of requests loaded per page over time, we do see a slight decrease in requests, rather than the expected increase.

    +

    + Bundling assets to obtain fewer requests was another HTTP/1.1 workaround that went by many names: bundling, concatenation, packaging, spriting, etc. This is less necessary when using HTTP/2 as there is less overhead with requests, but it should be noted that requests are not free in HTTP/2, and those that experimented with removing bundling completely have noticed a loss in performancehttps://engineering.khanacademy.org/posts/js-packaging-http2.htm. Looking at the number of requests loaded per page over time, we do see a slight decrease in requests, rather than the expected increase. +

    This low rate of change can perhaps be attributed to the aforementioned observations that bundling cannot be removed (at least, not completely) without a negative performance impact and that many build tools currently bundle for historical reasons based on HTTP/1.1 recommendations. It is also likely that many sites may not be willing to penalize HTTP/1.1 users by undoing their HTTP/1.1 performance hacks just yet, or at least that they do not have the confidence (or time!) to feel that this is worthwhile.

    The fact that the number of requests is staying roughly static is interesting, given the ever-increasing page weight, though perhaps this is not entirely related to HTTP/2.

    HTTP/2 Push

    HTTP/2 push has a mixed history despite being a much-hyped new feature of HTTP/2. The other features were basically performance improvements under the hood, but push was a brand new concept that completely broke the single request to single response nature of HTTP. It allowed extra responses to be returned; when you asked for the web page, the server could respond with the HTML page as usual, but then also send you the critical CSS and JavaScript, thus avoiding any additional round trips for certain resources. It would, in theory, allow us to stop inlining CSS and JavaScript into our HTML, and still get the same performance gains of doing so. After solving that, it could potentially lead to all sorts of new and interesting use cases.

    -

    The reality has been, well, a bit disappointing. HTTP/2 push has proved much harder to use effectively than originally envisaged. Some of this has been due to the complexity of how HTTP/2 push works, and the implementation issues due to that.

    +

    + The reality has been, well, a bit disappointing. HTTP/2 push has proved much harder to use effectively than originally envisaged. Some of this has been due to the complexity of how HTTP/2 push workshttps://jakearchibald.com/2017/h2-push-tougher-than-i-thought/, and the implementation issues due to that. +

    A bigger concern is that push can quite easily cause, rather than solve, performance issues. Over-pushing is a real risk. Often the browser is in the best place to decide what to request, and just as crucially when to request it but HTTP/2 push puts that responsibility on the server. Pushing resources that a browser already has in its cache, is a waste of bandwidth (though in my opinion so is inlining CSS but that gets must less of a hard time about that than HTTP/2 push!).

    -

    Proposals to inform the server about the status of the browser cache have stalled especially on privacy concerns. Even without that problem, there are other potential issues if push is not used correctly. For example, pushing large images and therefore holding up the sending of critical CSS and JavaScript will lead to slower websites than if you'd not pushed at all!

    +

    + Proposals to inform the server about the status of the browser cache have stalledhttps://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0033.html especially on privacy concerns. Even without that problem, there are other potential issues if push is not used correctly. For example, pushing large images and therefore holding up the sending of critical CSS and JavaScript will lead to slower websites than if you'd not pushed at all! +

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

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

    @@ -10707,10 +11583,13 @@

    HTTP/2
    Figure 12. How much is pushed when it is used.

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

    -

    This is a concern as previous advice has been to be conservative with push and to "push just enough resources to fill idle network time, and no more". The above statistics suggest many resources of a significant combined size are pushed.

    +

    + This is a concern as previous advice has been to be conservative with push and to "push just enough resources to fill idle network time, and no more"https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0/edit. The above statistics suggest many resources of a significant combined size are pushed. +

    - Figure 13. What asset types is push used for? + Figure 13. What asset types is push used for?
    Figure 13. What asset types is push used for?
    @@ -10724,9 +11603,16 @@

    HTTP/2

    5% of preload HTTP headers do make use of this attribute, which is higher than I would have expected as I would have considered this a niche optimization. Then again, so is the use of preload HTTP headers and/or HTTP/2 push itself!

    HTTP/2 Issues

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

    -

    One cause of issues in HTTP/2 is the poor support of HTTP/2 prioritization. This feature allows multiple requests in progress to make the appropriate use of the connection. This is especially important since HTTP/2 has massively increased the number of requests that can be running on the same connection. 100 or 128 parallel request limits are common in server implementations. Previously, the browser had a max of six connections per domain, and so used its skill and judgement to decide how best to use those connections. Now, it rarely needs to queue and can send all requests as soon as it knows about them. This can then lead to the bandwidth being "wasted" on lower priority requests while critical requests are delayed (and incidentally can also lead to swamping your backend server with more requests than it is used to!).

    +

    + One cause of issues in HTTP/2 is the poor support of HTTP/2 prioritization. This feature allows multiple requests in progress to make the appropriate use of the connection. This is especially important since HTTP/2 has massively increased the number of requests that can be running on the same connection. 100 or 128 parallel request limits are common in server implementations. Previously, the browser had a max of six connections per domain, and so used its skill and judgement to decide how best to use those connections. Now, it rarely needs to queue and can send all requests as soon as it knows about them. This can then lead to the bandwidth being "wasted" on lower priority requests while critical requests are delayed (and incidentally can also lead to swamping your backend server with more requests than it is used to!https://www.lucidchart.com/techblog/2019/04/10/why-turning-on-http2-was-a-mistake/). +

    HTTP/2 has a complex prioritization model (too complex many say - hence why it is being reconsidered for HTTP/3!) but few servers honor that properly. This can be because their HTTP/2 implementations are not up to scratch, or because of so-called bufferbloat, where the responses are already en route before the server realizes there is a higher priority request. Due to the varying nature of servers, TCP stacks, and locations, it is difficult to measure this for most sites, but with CDNs this should be more consistent.

    -

    Patrick Meenan created an example test page, which deliberately tries to download a load of low priority, off-screen images, before requesting some high priority on-screen images. A good HTTP/2 server should be able to recognize this and send the high priority images shortly after requested, at the expense of the lower priority images. A poor HTTP/2 server will just respond in the request order and ignore any priority signals. Andy Davies has a page tracking the status of various CDNs for Patrick's test. The HTTP Archive identifies when a CDN is used as part of its crawl, and merging these two datasets can tell us the percent of pages using a passing or failing CDN.

    +

    + Patrick Meenanhttps://twitter.com/patmeenan created an example test pagehttps://github.com/pmeenan/http2priorities/tree/master/stand-alone, which deliberately tries to download a load of low priority, off-screen images, before requesting some high priority on-screen images. A good HTTP/2 server should be able to recognize this and send the high priority images shortly after requested, at the expense of the lower priority images. A poor HTTP/2 server will just respond in the request order and ignore any priority signals. Andy Davies has a page tracking the status of various CDNs for Patrick's testhttps://github.com/andydavies/http2-prioritization-issues. The HTTP Archive identifies when a CDN is used as part of its crawl, and merging these two datasets can tell us the percent of pages using a passing or failing CDN. +

    @@ -10840,11 +11726,21 @@

    HT

    Worse than that, is when a server sends an upgrade header in error. This could be because a backend server supporting HTTP/2 is sending the header and then an HTTP/1.1-only edge server is blindly forwarding it to the client. Apache emits the upgrade header when mod_http2 is enabled but HTTP/2 is not being used, and an nginx instance sitting in front of such an Apache instance happily forwards this header even when nginx does not support HTTP/2. This false advertising then leads to clients trying (and failing!) to use HTTP/2 as they are advised to.

    108 sites use HTTP/2 while they also suggest upgrading to HTTP/2 in the upgrade header. A further 12,767 sites on desktop (15,235 on mobile) suggest upgrading an HTTP/1.1 connection delivered over HTTPS to HTTP/2 when it's clear this was not available, or it would have been used already. These are a small minority of the 4.3 million sites crawled on desktop and 5.3 million sites crawled on mobile, but it shows that this is still an issue affecting a number of sites out there. Browsers handle this inconsistently, with Safari in particular attempting to upgrade and then getting itself in a mess and refusing to display the site at all.

    All of this is before we get into the few sites that recommend upgrading to http1.0, http://1.1, or even -all,+TLSv1.3,+TLSv1.2. There are clearly some typos in web server configurations going on here!

    -

    There are further implementation issues we could look at. For example, HTTP/2 is much stricter about HTTP header names, rejecting the whole request if you respond with spaces, colons, or other invalid HTTP header names. The header names are also converted to lowercase, which catches some by surprise if their application assumes a certain capitalization. This was never guaranteed previously, as HTTP/1.1 specifically states the header names are case insensitive, but still some have depended on this. The HTTP Archive could potentially be used to identify these issues as well, though some of them will not be apparent on the home page, but we did not delve into that this year.

    +

    + There are further implementation issues we could look at. For example, HTTP/2 is much stricter about HTTP header names, rejecting the whole request if you respond with spaces, colons, or other invalid HTTP header names. The header names are also converted to lowercase, which catches some by surprise if their application assumes a certain capitalization. This was never guaranteed previously, as HTTP/1.1 specifically states the header names are case insensitivehttps://tools.ietf.org/html/rfc7230#section-3.2, but still some have depended on this. The HTTP Archive could potentially be used to identify these issues as well, though some of them will not be apparent on the home page, but we did not delve into that this year. +

    HTTP/3

    -

    The world does not stand still, and despite HTTP/2 not having even reached its fifth birthday, people are already seeing it as old news and getting more excited about its successor, HTTP/3. HTTP/3 builds on the concepts of HTTP/2, but moves from working over TCP connections that HTTP has always used, to a UDP-based protocol called QUIC. This allows us to fix one case where HTTP/2 is slower then HTTP/1.1, when there is high packet loss and the guaranteed nature of TCP holds up all streams and throttles back all streams. It also allows us to address some TCP and HTTPS inefficiencies, such as consolidating in one handshake for both, and supporting many ideas for TCP that have proven hard to implement in real life (TCP fast open, 0-RTT, etc.).

    +

    + The world does not stand still, and despite HTTP/2 not having even reached its fifth birthday, people are already seeing it as old news and getting more excited about its successor, HTTP/3https://tools.ietf.org/html/draft-ietf-quic-http. HTTP/3 builds on the concepts of HTTP/2, but moves from working over TCP connections that HTTP has always used, to a UDP-based protocol called QUIChttps://datatracker.ietf.org/wg/quic/about/. This allows us to fix one case where HTTP/2 is slower then HTTP/1.1, when there is high packet loss and the guaranteed nature of TCP holds up all streams and throttles back all streams. It also allows us to address some TCP and HTTPS inefficiencies, such as consolidating in one handshake for both, and supporting many ideas for TCP that have proven hard to implement in real life (TCP fast open, 0-RTT, etc.). +

    HTTP/3 also cleans up some overlap between TCP and HTTP/2 (e.g. flow control being implemented in both layers) but conceptually it is very similar to HTTP/2. Web developers who understand and have optimized for HTTP/2 should have to make no further changes for HTTP/3. Server operators will have more work to do, however, as the differences between TCP and QUIC are much more groundbreaking. They will make implementation harder so the rollout of HTTP/3 may take considerably longer than HTTP/2, and initially be limited to those with certain expertise in the field like CDNs.

    -

    QUIC has been implemented by Google for a number of years and it is now undergoing a similar standardization process that SPDY did on its way to HTTP/2. QUIC has ambitions beyond just HTTP, but for the moment it is the use case being worked on currently. Just as this chapter was being written, Cloudflare, Chrome, and Firefox all announced HTTP/3 support, despite the fact that HTTP/3 is still not formally complete or approved as a standard yet. This is welcome as QUIC support has been somewhat lacking outside of Google until recently, and definitely lags behind SPDY and HTTP/2 support from a similar stage of standardization.

    +

    + QUIC has been implemented by Google for a number of years and it is now undergoing a similar standardization process that SPDY did on its way to HTTP/2. QUIC has ambitions beyond just HTTP, but for the moment it is the use case being worked on currently. Just as this chapter was being written, Cloudflare, Chrome, and Firefox all announced HTTP/3 supporthttps://blog.cloudflare.com/http3-the-past-present-and-future/, despite the fact that HTTP/3 is still not formally complete or approved as a standard yet. This is welcome as QUIC support has been somewhat lacking outside of Google until recently, and definitely lags behind SPDY and HTTP/2 support from a similar stage of standardization. +

    Because HTTP/3 uses QUIC over UDP rather than TCP, it makes the discovery of HTTP/3 support a bigger challenge than HTTP/2 discovery. With HTTP/2 we can mostly use the HTTPS handshake, but as HTTP/3 is on a completely different connection, that is not an option here. HTTP/2 also used the upgrade HTTP header to inform the browser of HTTP/2 support, and although that was not that useful for HTTP/2, a similar mechanism has been put in place for QUIC that is more useful. The alternative services HTTP header (alt-svc) advertises alternative protocols that can be used on completely different connections, as opposed to alternative protocols that can be used on this connection, which is what the upgrade HTTP header is used for.

    8.38%
    @@ -10854,44 +11750,65 @@

    HTTP/3

    Conclusion

    This analysis of the available statistics in the HTTP Archive project has shown what many of us in the HTTP community were already aware of: HTTP/2 is here and proving to be very popular. It is already the dominant protocol in terms of number of requests, but has not quite overtaken HTTP/1.1 in terms of number of sites that support it. The long tail of the internet means that it often takes an exponentially longer time to make noticeable gains on the less well-maintained sites than on the high profile, high volume sites.

    We've also talked about how it is (still!) not easy to get HTTP/2 support in some installations. Server developers, operating system distributors, and end customers all have a part to play in pushing to make that easier. Tying software to operating systems always lengthens deployment time. In fact, one of the very reasons for QUIC is to break a similar barrier with deploying TCP changes. In many instances, there is no real reason to tie web server versions to operating systems. Apache (to use one of the more popular examples) will run with HTTP/2 support in older operating systems, but getting an up-to-date version on to the server should not require the expertise or risk it currently does. Nginx does very well here, hosting repositories for the common Linux flavors to make installation easier, and if the Apache team (or the Linux distribution vendors) do not offer something similar, then I can only see Apache's usage continuing to shrink as it struggles to hold relevance and shake its reputation as old and slow (based on older installs) even though up-to-date versions have one of the best HTTP/2 implementations. I see that as less of an issue for IIS, since it is usually the preferred web server on the Windows side.

    -

    Other than that, HTTP/2 has been a relatively easy upgrade path, which is why it has had the strong uptake it has already seen. For the most part, it is a painless switch-on and, therefore, for most, it has turned out to be a hassle-free performance increase that requires little thought once your server supports it. The devil is in the details though (as always), and small differences between server implementations can result in better or worse HTTP/2 usage and, ultimately, end user experience. There has also been a number of bugs and even security issues, as is to be expected with any new protocol.

    +

    + Other than that, HTTP/2 has been a relatively easy upgrade path, which is why it has had the strong uptake it has already seen. For the most part, it is a painless switch-on and, therefore, for most, it has turned out to be a hassle-free performance increase that requires little thought once your server supports it. The devil is in the details though (as always), and small differences between server implementations can result in better or worse HTTP/2 usage and, ultimately, end user experience. There has also been a number of bugs and even security issueshttps://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md, as is to be expected with any new protocol. +

    Ensuring you are using a strong, up-to-date, well-maintained implementation of any newish protocol like HTTP/2 will ensure you stay on top of these issues. However, that can take expertise and managing. The roll out of QUIC and HTTP/3 will likely be even more complicated and require more expertise. Perhaps this is best left to third-party service providers like CDNs who have this expertise and can give your site easy access to these features? However, even when left to the experts, this is not a sure thing (as the prioritization statistics show), but if you choose your server provider wisely and engage with them on what your priorities are, then it should be an easier implementation.

    On that note it would be great if the CDNs prioritized these issues (pun definitely intended!), though I suspect with the advent of a new prioritization method in HTTP/3, many will hold tight. The next year will prove yet more interesting times in the HTTP world.

    -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    {% endblock %} diff --git a/src/templates/es/2019/base.html b/src/templates/es/2019/base.html index e4887d576c5..eac414fe1c8 100644 --- a/src/templates/es/2019/base.html +++ b/src/templates/es/2019/base.html @@ -109,8 +109,10 @@ {% endblock %} {% block appendix %}Apéndice{% endblock %} +{% block appendices %}Apéndices{% endblock %} {% block ebook_download %}Download the entire {{ year }} Web Almanac in PDF format{% endblock %} +{% block ebook_download_note %}(generated with www.princexml.com){% endblock %} {% set localizedPartTitles = { diff --git a/src/templates/fr/2019/base.html b/src/templates/fr/2019/base.html index 926532bc2fb..ecf9874bc32 100644 --- a/src/templates/fr/2019/base.html +++ b/src/templates/fr/2019/base.html @@ -108,9 +108,11 @@

    — Rick Viscomi, créateur du Web Almanac

    {% endblock %} -{% block appendix %}Annexes{% endblock %} +{% block appendix %}Annexe{% endblock %} +{% block appendices %}Annexes{% endblock %} {% block ebook_download %}Download the entire {{ year }} Web Almanac in PDF format{% endblock %} +{% block ebook_download_note %}(generated with www.princexml.com){% endblock %} {% set localizedPartTitles = { diff --git a/src/templates/ja/2019/base.html b/src/templates/ja/2019/base.html index 13c4d65446e..0f8bcf3c2e6 100644 --- a/src/templates/ja/2019/base.html +++ b/src/templates/ja/2019/base.html @@ -109,8 +109,10 @@ {% endblock %} {% block appendix %}付属資料{% endblock %} +{% block appendices %}付属資料{% endblock %} {% block ebook_download %} {{ year }} Web AlmanacのPDFファイルをダウンロードする{% endblock %} +{% block ebook_download_note %}(generated with www.princexml.com){% endblock %} {% set localizedPartTitles = { diff --git a/src/templates/ja/2019/base_ebook.html b/src/templates/ja/2019/base_ebook.html index 694f41c5457..10c6f89b0e4 100644 --- a/src/templates/ja/2019/base_ebook.html +++ b/src/templates/ja/2019/base_ebook.html @@ -5,10 +5,10 @@ {% block date_published %}2020-05-10T12:00:00.000Z{% endblock %} {% block date_modified %}2020-05-16T00:00:00.000Z{% endblock %} -{% block intro_title %}{{ year }} Web Almanac{% endblock %} -{% block intro_sub_title %}HTTP Archiveの年次報告書ウェブの状態レポート{% endblock %} +{% block intro_title %}{{ year }}
    Web Almanac{% endblock %} +{% block intro_sub_title %}HTTP Archiveの年次報告書
    ウェブの状態レポート{% endblock %} -{% block about_title %}Web Alamancについて{% endblock %} +{% block about_title %}Web Almanacについて{% endblock %} {% block description %}{{ year }} Web Almanacの電子書籍版{% endblock %} diff --git a/src/templates/ja/2019/ebook.html b/src/templates/ja/2019/ebook.html index 17b0b0e4399..0e8f24acf9c 100644 --- a/src/templates/ja/2019/ebook.html +++ b/src/templates/ja/2019/ebook.html @@ -1,16 +1,15 @@ -{% extends "%s/2019/base_ebook.html" % lang %} {% set metadata = {} %} {% block chapters %} - -
    -
    +{% extends "%s/2019/base_ebook.html" % lang %} {% set metadata = {} %} {% block chapters %} {% set metadata = {"part_number":"I","chapter_number":1,"title":"JavaScript","description":"2019年のWeb AlmanacのJavaScriptの章では、Web上でどれだけJavaScriptを使用しているか、圧縮、ライブラリとフレームワーク、読み込み、ソースマップを網羅しています。","authors":["housseindjirdeh"],"reviewers":["obto","paulcalvano","mathiasbynens"],"translators":["ksakae"],"discuss":"1756","results":"https://docs.google.com/spreadsheets/d/1kBTglETN_V9UjKqK_EFmFjRexJnQOmLLr-I2Tkotvic/","queries":"01_JavaScript","published":"2019-11-11","last_updated":"2020-05-20","chapter":"javascript"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 1 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - JavaScript +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":1,"title":"JavaScript","description":"2019年のWeb AlmanacのJavaScriptの章では、Web上でどれだけJavaScriptを使用しているか、圧縮、ライブラリとフレームワーク、読み込み、ソースマップを網羅しています。","authors":["housseindjirdeh"],"reviewers":["obto","paulcalvano","mathiasbynens"],"translators":["ksakae"],"discuss":"1756","results":"https://docs.google.com/spreadsheets/d/1kBTglETN_V9UjKqK_EFmFjRexJnQOmLLr-I2Tkotvic/","queries":"01_JavaScript","published":"2019-11-11","last_updated":"2020-05-20","chapter":"javascript"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -19,23 +18,33 @@

    - + -
    {{ self.written_by_before() }} Houssein Djirdeh{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} David Fox, Paul Calvano, {{ self.and() }} Mathias Bynens{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    JavaScriptはウェブ上で、対話可能で複雑な体験を構築することを可能にするスクリプト言語です。これには、ユーザーの会話への応答、ページ上の動的コンテンツの更新などが含まれます。イベントが発生したときにウェブページがどのように振る舞うべきかに関係するものはすべて、JavaScriptが使用されています。

    言語の仕様自体は、世界中の開発者が利用している多くのコミュニティビルドのライブラリやフレームワークとともに、1995年に言語が作成されて以来、変化と進化を続けてきました。JavaScriptの実装やインタプリタも進歩を続けており、ブラウザだけでなく多くの環境で利用できるようになっています。

    -

    HTTP Archiveは毎月数百万ページをクロールし、WebPageTest のプライベートインスタンスを通して実行し、各ページのキー情報を保存しています（これについての詳細は方法論 で学べます）。JavaScriptのコンテキストでは、HTTP Archiveはウェブ全体の言語の使用法に関する広範な情報を提供しています。この章では、これらの傾向の多くを集約して分析します。

    +

    + HTTP Archivehttps://httparchive.org/は毎月数百万ページhttps://httparchive.org/reports/state-of-the-web#numUrlsをクロールし、WebPageTesthttps://webpagetest.org/ のプライベートインスタンスを通して実行し、各ページのキー情報を保存しています（これについての詳細は方法論 で学べます）。JavaScriptのコンテキストでは、HTTP Archiveはウェブ全体の言語の使用法に関する広範な情報を提供しています。この章では、これらの傾向の多くを集約して分析します。 +

    どのくらいのJavaScriptを使っているのか？

    -

    JavaScriptは、私たちがブラウザに送るリソースの中で最もコストのかかるものでダウンロード、解析、コンパイル、そして最終的に実行されなければなりません。ブラウザはスクリプトの解析とコンパイルにかかる時間を大幅に短縮しましたが、WebページでJavaScriptが処理される際には、ダウンロードと実行が最もコストのかかる段階になっています。

    +

    + JavaScriptは、私たちがブラウザに送るリソースの中で最もコストのかかるものでダウンロード、解析、コンパイル、そして最終的に実行されなければなりません。ブラウザはスクリプトの解析とコンパイルにかかる時間を大幅に短縮しましたが、WebページでJavaScriptが処理される際には、ダウンロードと実行が最もコストのかかる段階になっていますhttps://v8.dev/blog/cost-of-javascript-2019。 +

    ブラウザに小さなJavaScriptのバンドルを送ることは、ダウンロード時間を短縮し、ひいてはページパフォーマンスを向上させるための最良の方法です。しかし、実際にどのくらいのJavaScriptを使っているのでしょうか？

    - 図1. ページあたりのJavaScriptバイト数の分布 + 図1. ページあたりのJavaScriptバイト数の分布
    図 1. ページあたりのJavaScriptバイト数の分布
    @@ -44,7 +53,7 @@

    この数字を見ると、これはJavaScriptの使いすぎではないかと思うのは当然のことです。しかし、ページのパフォーマンスに関しては、その影響はネットワーク接続や使用するデバイスに完全に依存します。モバイルクライアントとデスクトップクライアントを比較した場合、どのくらいのJavaScriptを提供しているのでしょうか？

    - 図2. デバイス別のページあたりのJavaScriptの分布。 + 図2. デバイス別のページあたりのJavaScriptの分布。
    図 2. デバイス別のページあたりのJavaScriptの分布。
    @@ -55,7 +64,7 @@

    - 図3. デバイス別のV8メインスレッド処理時間。 + 図3. デバイス別のV8メインスレッド処理時間。
    図 3. デバイス別のV8メインスレッド処理時間。
    @@ -64,16 +73,19 @@

    - Reddit.comのJavaScript処理時間 + Reddit.comのJavaScript処理時間 -
    図 4. reddit.comのJavaScript処理時間。2019年のJavaScriptのコストより。
    +
    + 図 4. reddit.comのJavaScript処理時間。2019年のJavaScriptのコストhttps://v8.dev/blog/cost-of-javascript-2019より。 +

    リクエスト数

    Webページで使用されているJavaScriptの量を分析しようとする場合、1つの方法として、送信されたリクエスト数を調べる価値があります。HTTP/2では、複数の小さなチャンクを送信することで、より大きなモノリシックなバンドルを送信するよりもページの負荷を改善できます。また、デバイスクライアント別に分解してみると、どのくらいのリクエストがフェッチされているのでしょうか。

    - 図5. 総JavaScriptリクエスト数の分布。 + 図5. 総JavaScriptリクエスト数の分布。
    図 5. 総JavaScriptリクエスト数の分布。
    @@ -84,14 +96,14 @@

    サードパーティのJavaScriptは、外部のサードパーティのソースから取得できます。広告、分析、ソーシャルメディアの埋め込みなどは、サードパーティのスクリプトを取得するための一般的なユースケースです。そこで当然のことながら、次の質問に移ります。

    - 図6. デスクトップ上のファーストスクリプトとサードパーティスクリプトの分布。 + 図6. デスクトップ上のファーストスクリプトとサードパーティスクリプトの分布。
    図 6. デスクトップ上のファーストスクリプトとサードパーティスクリプトの分布。
    - 図7. モバイル上のファーストパーティとサードパーティのスクリプトの分布。 + 図7. モバイル上のファーストパーティとサードパーティのスクリプトの分布。
    図 7. モバイル上のファーストパーティとサードパーティのスクリプトの分布。
    @@ -99,14 +111,14 @@

    モバイルクライアントとデスクトップクライアントの両方において、すべてのパーセンタイルにおいて、ファーストパーティよりもサードパーティのリクエストの方が多く送信されています。これが意外に思える場合は、実際に提供されるコードのうち、サードパーティのベンダーからのものがどれくらいあるのかを調べてみましょう。

    - 図8. デスクトップ上でダウンロードされたJavaScriptの総ダウンロード数の分布。 + 図8. デスクトップ上でダウンロードされたJavaScriptの総ダウンロード数の分布。
    図 8. デスクトップ上でダウンロードされたJavaScriptの総ダウンロード数の分布。
    - 図9. モバイルでダウンロードされたJavaScriptの総ダウンロード数の分布。 + 図9. モバイルでダウンロードされたJavaScriptの総ダウンロード数の分布。
    図 9. モバイルでダウンロードされたJavaScriptの総ダウンロード数の分布。
    @@ -116,14 +128,19 @@

    ブラウザとサーバの会話のコンテキストで、リソース圧縮とは、データ圧縮アルゴリズムを使用して変更されたコードを指します。リソースは事前に静的に圧縮することも、ブラウザからの要求に応じて急ぎ圧縮することもでき、どちらの方法でも転送されるリソースサイズが大幅に削減されページパフォーマンスが向上します。

    テキスト圧縮アルゴリズムは複数ありますが、HTTPネットワークリクエストの圧縮（および解凍）に使われることが多いのはこの2つだけです。

      -
    • Gzip (gzip): サーバーとクライアントの相互作用のために最も広く使われている圧縮フォーマット。
      • -
    • Brotli (br): 圧縮率のさらなる向上を目指した新しい圧縮アルゴリズム。90%のブラウザがBrotliエンコーディングをサポートしています。
      • +
    • + Gziphttps://www.gzip.org/ (gzip): サーバーとクライアントの相互作用のために最も広く使われている圧縮フォーマット。 +
      • +
    • + Brotlihttps://github.com/google/brotli (br): 圧縮率のさらなる向上を目指した新しい圧縮アルゴリズム。90%のブラウザhttps://caniuse.com/#feat=brotliがBrotliエンコーディングをサポートしています。 +

    圧縮されたスクリプトは、一度転送されるとブラウザによって常に解凍される必要があります。これは、コンテンツの内容が変わらないことを意味し、実行時間が最適化されないことを意味します。しかし、リソース圧縮は常にダウンロード時間を改善しますが、これはJavaScriptの処理で最もコストのかかる段階の1つでもあります。JavaScriptファイルが正しく圧縮されていることを確認することは、サイトのパフォーマンスを向上させるための最も重要な要因の1つとなります。

    JavaScriptのリソースを圧縮しているサイトはどれくらいあるのでしょうか？

    - 図10. JavaScript リソースをgzipまたはbrotliで圧縮しているサイトの割合。 + 図10. JavaScript リソースをgzipまたはbrotliで圧縮しているサイトの割合。
    図 10. JavaScript リソースをgzipまたはbrotliで圧縮しているサイトの割合。
    @@ -131,7 +148,11 @@

    大多数のサイトではJavaScriptのリソースを圧縮しています。Gzipエンコーディングはサイトの〜64-67％で、Brotliは〜14％で使用されています。圧縮率はデスクトップとモバイルの両方でほぼ同じです。

    圧縮に関するより深い分析については、"圧縮"の章を参照してください。

    オープンソースのライブラリとフレームワーク

    -

    オープンソースコード、または誰でもアクセス、閲覧、修正が可能な寛容なライセンスを持つコード。小さなライブラリから、ChromiumやFirefoxのようなブラウザ全体に至るまで、オープンソースコードはウェブ開発の世界で重要な役割を果たしています。JavaScriptの文脈では、開発者はオープンソースのツールに依存して、あらゆるタイプの機能をWebページに組み込んでいます。開発者が小さなユーティリティライブラリを使用するか、アプリケーション全体のアーキテクチャを決定する大規模なフレームワークを使用するかにかかわらずオープンソースのパッケージに依存することで、機能開発をより簡単かつ迅速にできます。では、どのJavaScriptオープンソースライブラリが最もよく使われているのでしょうか？

    +

    + オープンソースコード、または誰でもアクセス、閲覧、修正が可能な寛容なライセンスを持つコード。小さなライブラリから、Chromiumhttps://www.chromium.org/HomeやFirefoxhttps://www.openhub.net/p/firefoxのようなブラウザ全体に至るまで、オープンソースコードはウェブ開発の世界で重要な役割を果たしています。JavaScriptの文脈では、開発者はオープンソースのツールに依存して、あらゆるタイプの機能をWebページに組み込んでいます。開発者が小さなユーティリティライブラリを使用するか、アプリケーション全体のアーキテクチャを決定する大規模なフレームワークを使用するかにかかわらずオープンソースのパッケージに依存することで、機能開発をより簡単かつ迅速にできます。では、どのJavaScriptオープンソースライブラリが最もよく使われているのでしょうか？ +

    @@ -255,55 +276,97 @@

    図 11. デスクトップとモバイルでのトップ JavaScript ライブラリ

    -

    これまでに作成された中で最も人気のあるJavaScriptライブラリであるjQueryは、デスクトップページの85.03％、モバイルページの83.46％で使用されています。FetchやquerySelectorなど、多くのブラウザAPIやメソッドの出現により、ライブラリが提供する機能の多くがネイティブ形式に標準化されました。jQueryの人気は衰退しているように見えるかもしれませんが、なぜ今でもウェブの大部分で使われているのでしょうか？

    +

    + これまでに作成された中で最も人気のあるJavaScriptライブラリであるjQueryhttps://jquery.com/は、デスクトップページの85.03％、モバイルページの83.46％で使用されています。Fetchhttps://developer.mozilla.org/ja/docs/Web/API/Fetch_APIやquerySelectorhttps://developer.mozilla.org/ja/docs/Web/API/Document/querySelectorなど、多くのブラウザAPIやメソッドの出現により、ライブラリが提供する機能の多くがネイティブ形式に標準化されました。jQueryの人気は衰退しているように見えるかもしれませんが、なぜ今でもウェブの大部分で使われているのでしょうか？ +

    理由はいくつか考えられます。

      -
    • WordPressは、30％以上のサイトで使用されているため、デフォルトでjQueryが含まれています。
      • +
    • + WordPresshttps://wordpress.org/は、30％以上のサイトで使用されているため、デフォルトでjQueryが含まれています。 +
    • アプリケーションの規模によってはjQueryから新しいクライアントサイドライブラリへの切り替えに時間を要する場合があり、多くのサイトでは新しいクライアントサイドライブラリに加えてjQueryで構成されている場合があります。
    -

    他にもjQueryの亜種（jQuery migrate、jQuery UI）、Modernizr、Moment.js、Underscore.jsなどがトップで使用されているJavaScriptライブラリです。

    +

    + 他にもjQueryの亜種（jQuery migrate、jQuery UI）、Modernizrhttps://modernizr.com/、Moment.jshttps://momentjs.com/、Underscore.jshttps://underscorejs.org/などがトップで使用されているJavaScriptライブラリです。 +

    フレームワークとUIライブラリ

    -

    方法論で述べたように、HTTP Archive(Wappalyzer)で使用されているサードパーティ製の検出ライブラリには、特定のツールを検出する方法に関して多くの制限があります。JavaScriptライブラリやフレームワークの検出を改善するための未解決の問題があります、それがここで紹介した結果に影響を与えています。

    +

    + 方法論で述べたように、HTTP Archive(Wappalyzer)で使用されているサードパーティ製の検出ライブラリには、特定のツールを検出する方法に関して多くの制限があります。JavaScriptライブラリやフレームワークの検出を改善するための未解決の問題がありますhttps://github.com/AliasIO/wappalyzer/issues/2450、それがここで紹介した結果に影響を与えています。 +

    過去数年の間に、JavaScriptのエコシステムでは、シングルページアプリケーション (SPA) の構築を容易にするオープンソースのライブラリやフレームワークが増えてきました。シングルページアプリケーションとは、単一のHTMLページを読み込み、サーバーから新しいページを取得する代わりにJavaScriptを使用してユーザーの対話に応じてページを修正するWebページのことを指します。これはシングルページアプリケーションの大前提であることに変わりはありませんが、このようなサイトの体験を向上させるために、異なるサーバーレンダリングアプローチを使用できます。これらのタイプのフレームワークを使用しているサイトはどれくらいあるのでしょうか？

    - 図12. デスクトップで最もよく使われるフレームワーク + 図12. デスクトップで最もよく使われるフレームワーク
    図 12. デスクトップで最もよく使われるフレームワーク

    ここでは人気のあるフレームワークのサブセットのみを分析していますが、これらのフレームワークはすべて、これら2つのアプローチのいずれかに従っていることに注意することが重要です。

    -

    コンポーネントベースモデルへの移行が進んでいるとはいえ、MVCパラダイムを踏襲した古いフレームワーク（AngularJS、Backbone.js、Ember）は、いまだに何千ページにもわたって使われています。しかし、React、Vue、Angularはコンポーネントベースのフレームワークが主流です（Zone.jsは現在Angular coreの一部となっているパッケージです）。

    +

    + コンポーネントベースモデルへの移行が進んでいるとはいえ、MVCパラダイムを踏襲した古いフレームワーク（AngularJShttps://angularjs.org/、Backbone.jshttps://backbonejs.org/、Emberhttps://emberjs.com/）は、いまだに何千ページにもわたって使われています。しかし、Reacthttps://reactjs.org/、Vuehttps://vuejs.org/、Angularhttps://angular.io/はコンポーネントベースのフレームワークが主流です（Zone.jshttps://github.com/angular/zone.jsは現在Angular coreの一部となっているパッケージです）。 +

    差分ロード

    -

    JavaScriptモジュール、またはESモジュールは、すべての主要ブラウザでサポートされています。モジュールは、他のモジュールからインポートおよびエクスポートできるスクリプトを作成する機能を提供します。これにより、サードパーティのモジュールローダーに頼ることなく、必要に応じてインポートとエクスポートを行い、モジュールパターンで構築されたアプリケーションを誰でも構築できます。

    +

    + JavaScriptモジュールhttps://v8.dev/features/modules、またはESモジュールは、すべての主要ブラウザhttps://caniuse.com/#feat=es6-moduleでサポートされています。モジュールは、他のモジュールからインポートおよびエクスポートできるスクリプトを作成する機能を提供します。これにより、サードパーティのモジュールローダーに頼ることなく、必要に応じてインポートとエクスポートを行い、モジュールパターンで構築されたアプリケーションを誰でも構築できます。 +

    スクリプトをモジュールとして宣言するには、スクリプトタグがtype="module"属性を取得しなければなりません。

    <script type="module" src="main.mjs"></script>

    ページ上のスクリプトにtype="module'を使用しているサイトはどれくらいあるでしょうか？

    - 図13. type=moduleを利用しているサイトの割合。 + 図13. type=moduleを利用しているサイトの割合。
    図 13. type=moduleを利用しているサイトの割合。
    -

    ブラウザレベルでのモジュールのサポートはまだ比較的新しく、ここでの数字は、現在スクリプトにtype="module"を使用しているサイトが非常に少ないことを示しています。多くのサイトでは、コードベース内でモジュールを定義するためにモジュールローダー（全デスクトップサイトの2.37％がRequireJSを使用しています）やバンドラー（webpackを使用しています）にまだ依存しています。

    +

    + ブラウザレベルでのモジュールのサポートはまだ比較的新しく、ここでの数字は、現在スクリプトにtype="module"を使用しているサイトが非常に少ないことを示しています。多くのサイトでは、コードベース内でモジュールを定義するためにモジュールローダー（全デスクトップサイトの2.37％がRequireJShttps://github.com/requirejs/requirejsを使用しています）やバンドラー（webpackhttps://webpack.js.org/を使用しています）にまだ依存しています。 +

    ネイティブモジュールを使用する場合は、モジュールをサポートしていないブラウザに対して適切なフォールバックスクリプトを使用することが重要です。これは、nomodule属性を持つ追加スクリプトを含めることで実現できます。

    <script nomodule src="fallback.js"></script>
    -

    併用すると、モジュールをサポートしているブラウザはnomodule属性を含むスクリプトを完全に無視します。一方、モジュールをサポートしていないブラウザは ¥type="module"属性を持つスクリプトをダウンロードしません。ブラウザはnomoduleも認識しないので、type="module"属性を持つスクリプトを普通にダウンロードします。このアプローチを使うことで、開発者は最新のコードを最新のブラウザに送信してページ読み込みを高速化するできます。では、ページ上のスクリプトにnomoduleを使っているサイトはどれくらいあるのだろうか。

    +

    + 併用すると、モジュールをサポートしているブラウザはnomodule属性を含むスクリプトを完全に無視します。一方、モジュールをサポートしていないブラウザは ¥type="module"属性を持つスクリプトをダウンロードしません。ブラウザはnomoduleも認識しないので、type="module"属性を持つスクリプトを普通にダウンロードします。このアプローチを使うことで、開発者は最新のコードを最新のブラウザに送信してページ読み込みを高速化するhttps://web.dev/serve-modern-code-to-modern-browsers/できます。では、ページ上のスクリプトにnomoduleを使っているサイトはどれくらいあるのだろうか。 +

    - 図14. nomoduleを使用しているサイトの割合。 + 図14. nomoduleを使用しているサイトの割合。
    図 14. nomoduleを使用しているサイトの割合。

    同様に、スクリプトにnomodule属性を使用しているサイトはほとんどありません（0.50％-0.80％）。

    プリロードとプリフェッチ

    -

    プリロード と プリフェッチはリソースヒントであり、どのリソースをダウンロードする必要があるかを判断する際にブラウザを助けることができます。

    +

    + プリロードhttps://developer.mozilla.org/ja/docs/Web/HTML/Preloading_content と プリフェッチhttps://developer.mozilla.org/ja/docs/Web/HTTP/Link_prefetching_FAQはリソースヒントであり、どのリソースをダウンロードする必要があるかを判断する際にブラウザを助けることができます。 +

    - 図17. 新しいJavaScript APIの利用法 + 図17. 新しいJavaScript APIの利用法
    図 17. 新しいJavaScript APIの利用法

    Atomics(0.38％)とSharedArrayBuffer(0.20％)は、使用されているページが少ないので、このチャートではほとんど見えません。

    -

    ここでの数値は概算であり、機能の使用状況を測定するためのUseCounter を活用していないことに注意してください。

    +

    + ここでの数値は概算であり、機能の使用状況を測定するためのUseCounterhttps://chromium.googlesource.com/chromium/src.git/+/master/docs/use_counter_wiki.md を活用していないことに注意してください。 +

    ソースマップ

    -

    多くのビルドシステムでは、JavaScriptファイルはサイズを最小化し、多くのブラウザではまだサポートされていない新しい言語機能のためにトランスパイルされるようにミニ化されています。さらに、TypeScriptのような言語スーパーセットは、元のソースコードとは明らかに異なる出力へコンパイルされます。これらの理由から、ブラウザに提供される最終的なコードは読めず、解読が困難なものになることがあります。

    +

    + 多くのビルドシステムでは、JavaScriptファイルはサイズを最小化し、多くのブラウザではまだサポートされていない新しい言語機能のためにトランスパイルされるようにミニ化されています。さらに、TypeScripthttps://www.typescriptlang.org/のような言語スーパーセットは、元のソースコードとは明らかに異なる出力へコンパイルされます。これらの理由から、ブラウザに提供される最終的なコードは読めず、解読が困難なものになることがあります。 +

    ソースマップとは、JavaScriptファイルに付随する追加ファイルで、ブラウザが最終的な出力を元のソースにマップできます。これにより、プロダクションバンドルのデバッグや分析をより簡単にできます。

    便利ではありますが多くのサイトが最終的な制作サイトにソースマップを入れたくない理由は、完全なソースコードを公開しないことを選択するなど、いくつかあります。では、実際にどれくらいのサイトがソースマップを含んでいるのでしょうか？

    - 図18. ソースマップを使用しているサイトの割合。 + 図18. ソースマップを使用しているサイトの割合。
    図 18. ソースマップを使用しているサイトの割合。
    @@ -362,54 +442,73 @@

    結論

    JavaScriptのエコシステムは毎年変化し続け、進化し続けています。新しいAPI、改良されたブラウザエンジン、新しいライブラリやフレームワークなど、私たちが期待していることは尽きることがありません。HTTP Archiveは、実際のサイトがどのようにJavaScriptを使用しているかについての貴重な洞察を提供してくれます。

    JavaScriptがなければ、ウェブは現在の場所にはなく、この記事のために集められたすべてのデータがそれを証明しているに過ぎません。

    -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":2,"title":"CSS","description":"色、単位、セレクター、レイアウト、タイポグラフィとフォント、間隔、装飾、アニメーション、およびメディアクエリをカバーする2019 Web AlmanacのCSS章。","authors":["una","argyleink"],"reviewers":["meyerweb","huijing"],"translators":["ksakae"],"discuss":"1757","results":"https://docs.google.com/spreadsheets/d/1uFlkuSRetjBNEhGKWpkrXo4eEIsgYelxY-qR9Pd7QpM/","queries":"02_CSS","published":"2019-11-11","last_updated":"2020-03-02","chapter":"css"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 2 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - CSS +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":2,"title":"CSS","description":"色、単位、セレクター、レイアウト、タイポグラフィとフォント、間隔、装飾、アニメーション、およびメディアクエリをカバーする2019 Web AlmanacのCSS章。","authors":["una","argyleink"],"reviewers":["meyerweb","huijing"],"translators":["ksakae"],"discuss":"1757","results":"https://docs.google.com/spreadsheets/d/1uFlkuSRetjBNEhGKWpkrXo4eEIsgYelxY-qR9Pd7QpM/","queries":"02_CSS","published":"2019-11-11","last_updated":"2020-03-02","chapter":"css"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -418,13 +517,16 @@

    - + -
    {{ self.written_by_before() }} Una Kravets, {{ self.and() }} Adam Argyle{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Eric A. Meyer, {{ self.and() }} Chen Hui Jing{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    カスケードスタイルシート（CSS）は、Webページの描画、書式設定、およびレイアウトに使用されます。それらの機能は、テキストの色から3Dパースペクティブまでの単純な概念に及びます。また、さまざまな画面サイズ、コンテキストの表示、印刷を処理する開発者を支援するフックもあります。 CSSは、開発者がコンテンツを絞り込み、ユーザーに適切に適合させることを支援します。

    CSSをWebテクノロジーに慣れていない人に説明するときは、CSSを家の壁にペイントする言語と考える事が役立ちます。窓やドアのサイズと位置、および壁紙や植物などが栄える装飾と説明できる。そのストーリーの面白いひねりは、ユーザーが家の中を歩いているかどうかに応じて、開発者はその特定のユーザーの好みやコンテキストに家を作り替えることができるということです！

    @@ -433,29 +535,38 @@

    導入

    色

    色は、Webのテーマとスタイリングに不可欠な部分です。ウェブサイトが色を使用する傾向を見てみましょう。

    色の種類

    -

    16進数は、色を説明する最も一般的な方法であり93％の使用率、RGB、HSLが続きます。興味深いことに、開発者はこれらの色の種類に関してアルファ透明度の引数を最大限に活用しています。HSLAとRGBAは、HSLとRGBよりもはるかに人気があり、使用量はほぼ2倍です。アルファ透明度は後でWeb仕様に追加されましたが、HSLAとRGBAはIE9までさかのぼってサポートされているため、先に進んで使用することもできます！

    +

    + 16進数は、色を説明する最も一般的な方法であり93％の使用率、RGB、HSLが続きます。興味深いことに、開発者はこれらの色の種類に関してアルファ透明度の引数を最大限に活用しています。HSLAとRGBAは、HSLとRGBよりもはるかに人気があり、使用量はほぼ2倍です。アルファ透明度は後でWeb仕様に追加されましたが、HSLAとRGBAはIE9までさかのぼってhttps://caniuse.com/#feat=css3-colorsサポートされているため、先に進んで使用することもできます！ +

    - 図1.カラー形式の人気。 + 図1.カラー形式の人気。
    図 1.カラー形式の人気。

    色の選択

    -

    CSSの名前付きカラーは148個あり、transparentおよびcurrentcolorの特別な値は含まれていません。これらを文字列名で使用して、読みやすくできます。最も人気がある名前の付いた色は黒と白であり、当然のことながら赤と青が続きます。

    +

    + CSSの名前付きカラーは148個https://www.w3.org/TR/css-color-4/#named-colorsあり、transparentおよびcurrentcolorの特別な値は含まれていません。これらを文字列名で使用して、読みやすくできます。最も人気がある名前の付いた色は黒と白であり、当然のことながら赤と青が続きます。 +

    - 図2.上位の名前付き色。 + 図2.上位の名前付き色。
    図 2.上位の名前付き色。
    -

    言語は色によっても興味深いことに推測されます。イギリス式の「grey」よりもアメリカ式の「gray」の例が多くあります。グレー色（グレー、ライトグレー、ダークグレー、スレートグレーなど）のほぼすべてのインスタンスは、「e」ではなく「a」で綴ると、使用率がほぼ2倍になりました。 gr [a/e] ysが組み合わされた場合、それらは青よりも上位にランクされ、＃4スポットで固まります。これが、チャートで銀がグレーよりも高いランクになっている理由です。

    +

    + 言語は色によっても興味深いことに推測されます。イギリス式の「grey」よりもアメリカ式の「gray」の例が多くあります。グレー色https://www.rapidtables.com/web/color/gray-color.html（グレー、ライトグレー、ダークグレー、スレートグレーなど）のほぼすべてのインスタンスは、「e」ではなく「a」で綴ると、使用率がほぼ2倍になりました。 gr [a/e] ysが組み合わされた場合、それらは青よりも上位にランクされ、＃4スポットで固まります。これが、チャートで銀がグレーよりも高いランクになっている理由です。 +

    色の数

    ウェブ全体でいくつの異なるフォントの色が使用されていますか？　これは一意の色の総数ではありません。むしろ、テキストに使用される色の数です。このグラフの数値は非常に高く、経験からCSS変数なしでは間隔、サイズ、色がすぐに離れて、スタイル全体で多くの小さな値に断片化することがわかります。これらの数値はスタイル管理の難しさを反映しており、あなたがチームやプロジェクトに持ち帰るための何らかの視点を作り出すのに役立つことを願っています。この数を管理可能かつ合理的な量に減らすにはどうすればよいですか？

    - 図3.ページごとの色の分布。 + 図3.ページごとの色の分布。
    図 3.ページごとの色の分布。
    @@ -464,7 +575,7 @@

    色の

    さて、私たちはここで興味を持ち、ページにいくつの重複色が存在するかを調べたいと思いました。しっかり管理された再利用可能なクラスCSSシステムがなければ、複製はものすごく簡単に作成できます。中央値には十分な重複があるため、パスを実行してそれらをカスタムプロパティと統合する価値があるかもしれません。

    - 図4.ページごとの複製色の分布。 + 図4.ページごとの複製色の分布。
    図 4.ページごとの複製色の分布。
    @@ -473,7 +584,7 @@

    ユニ

    CSSには、異なるユニットタイプ（rem、px、em、ch、またはcm）を使用して同じ視覚的結果を達成するためのさまざまな方法があります！　それで、どのユニットタイプが最も人気ですか？

    - 図5.ユニットタイプの人気。 + 図5.ユニットタイプの人気。
    図 5.ユニットタイプの人気。
    @@ -481,7 +592,10 @@

    ユニ

    長さとサイズ

    当然のことながら、上の図5では、pxが最もよく使用されるユニットタイプであり、Webページの約95％が何らかの形式のピクセルを使用しています（これは要素のサイズ、フォントサイズなどです）。ただし、emユニットの使用率はほぼ同じで約90％です。これは、Webページで40％の頻度しかないremユニットよりも2倍以上人気があります。違いを知りたい場合は、emは親フォントサイズに基づいており、remはページに設定されている基本フォントサイズに基づいています。 em のようにコンポーネントごとに変更されることはないため、すべての間隔を均等に調整できます。

    物理的な空間に基づいた単位となると、cm（またはセンチメートル）ユニットが最も人気であり、次にin（インチ）、Qが続きます。これらのタイプのユニットは、印刷スタイルシートに特に役立つことがわかっていますが、この調査までQユニットが存在することさえ知りませんでした！　知ってましたか？

    -

    この章の以前のバージョンでは、Qユニットの予想外の人気について説明しました。この章を取り巻くコミュニティの議論のおかげで、これは分析のバグであることがわかり、それに応じて図5を更新しました。

    +

    + この章の以前のバージョンでは、Qユニットの予想外の人気について説明しました。この章を取り巻くコミュニティの議論https://discuss.httparchive.org/t/chapter-2-css/1757/6のおかげで、これは分析のバグであることがわかり、それに応じて図5を更新しました。 +

    ビューポートベースのユニット

    ビューポートベースのユニットのモバイルとデスクトップの使用に関しては、ユニットタイプに大きな違いが見られました。モバイルサイトは36.8％がvh（ビューポートの高さ）を使用していますが、デスクトップサイトは31％しか使用していません。また、vhはvw（ビューポートの幅）よりも約11％一般的です。 vmin（ビューポートの最小値）はvmax（ビューポートの最大値）よりも人気があり、モバイルでのvminの使用率は約8％で、vmaxはWebサイトの1％のみが使用しています。

    カスタムプロパティ

    @@ -496,7 +610,7 @@

    - 図7.ページごとのセレクタータイプの人気。 + 図7.ページごとのセレクタータイプの人気。
    図 7.ページごとのセレクタータイプの人気。
    @@ -504,7 +618,7 @@

    - 図8.セレクタごとのセレクタタイプの人気。 + 図8.セレクタごとのセレクタタイプの人気。
    図 8.セレクタごとのセレクタタイプの人気。
    @@ -513,14 +627,14 @@

    、[attribute^="value"]、[title~="rad"]、[attribute$="-rad"]または[attribute*="value"]などのセレクターです。それらを使用しますか？　よく使われていると思いますか？　それらがWeb全体でIDとクラスでどのように使用されるかを比較しましょう。

    - 図9. ID属性セレクターごとの演算子の人気。 + 図9. ID属性セレクターごとの演算子の人気。
    図 9. ID属性セレクターごとの演算子の人気。
    - 図10.クラス属性セレクタごとの演算子の人気。 + 図10.クラス属性セレクタごとの演算子の人気。
    図 10.クラス属性セレクタごとの演算子の人気。
    @@ -534,17 +648,23 @@

    レイアウト

    Flexbox

    -

    Flexboxは、子を指示、整列するコンテナスタイルです。つまり制約ベースの方法でレイアウトを支援します。 2010年から2013年の間に仕様が2〜3の大幅な変更を経たため、Webでの開始は非常に困難でした。幸いなことに、2014年までにすべてのブラウザに落ち着き実装されました。その歴史を考えると採用率は低かったのですが、それから数年が経ちました！　今では非常に人気があり、それに関する多くの記事とそれを活用する方法がありますが、他のレイアウト戦術と比較してまだ新しいです。

    +

    + Flexboxhttps://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexboxは、子を指示、整列するコンテナスタイルです。つまり制約ベースの方法でレイアウトを支援します。 2010年から2013年の間に仕様が2〜3の大幅な変更を経たため、Webでの開始は非常に困難でした。幸いなことに、2014年までにすべてのブラウザに落ち着き実装されました。その歴史を考えると採用率は低かったのですが、それから数年が経ちました！　今では非常に人気があり、それに関する多くの記事とそれを活用する方法がありますが、他のレイアウト戦術と比較してまだ新しいです。 +

    - 図12.フレックスボックスの採用。 + 図12.フレックスボックスの採用。
    図 12.フレックスボックスの採用。

    Webのほぼ50％がスタイルシートでflexboxを使用しているため、ここに示したかなりの成功事例です。

    Grid

    -

    flexboxと同様に、グリッドも早い段階でいくつかの仕様変更を経ましたが、公的に展開されたブラウザの実装を変更することはありませんでした。 Microsoftは、水平方向にスクロールするデザインスタイルの主要なレイアウトエンジンとして、Windows 8の最初のバージョンにグリッドを備えていました。最初にそこで検証され、Webに移行し、その後、2017年の最終リリースまで他のブラウザーによって強化されました。ほぼすべてのブラウザーが同時に実装をリリースしたため、Web開発者はある日目覚めただけで優れたグリッドサポートを得ることができました。今日2019年の終わりに、グリッドはまだ子供のように感じています。人々がまだその力と能力に気付き始めているため。

    +

    + flexboxと同様に、グリッドhttps://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layoutも早い段階でいくつかの仕様変更を経ましたが、公的に展開されたブラウザの実装を変更することはありませんでした。 Microsoftは、水平方向にスクロールするデザインスタイルの主要なレイアウトエンジンとして、Windows 8の最初のバージョンにグリッドを備えていました。最初にそこで検証され、Webに移行し、その後、2017年の最終リリースまで他のブラウザーによって強化されました。ほぼすべてのブラウザーが同時に実装をリリースしたため、Web開発者はある日目覚めただけで優れたグリッドサポートを得ることができました。今日2019年の終わりに、グリッドはまだ子供のように感じています。人々がまだその力と能力に気付き始めているため。 +

    2%
    図 13.グリッドを使用するWebサイトの割合。
    @@ -554,7 +674,7 @@

    - 図14.方向の値の人気。 + 図14.方向の値の人気。
    図 14.方向の値の人気。
    @@ -564,7 +684,7 @@

    - 図15.ページごとにロードされるWebフォントの数の分布。 + 図15.ページごとにロードされるWebフォントの数の分布。
    図 15.ページごとにロードされるWebフォントの数の分布。
    @@ -573,7 +693,7 @@

    - 図16.上位のWebフォント。 + 図16.上位のWebフォント。
    図 16.上位のWebフォント。
    @@ -584,7 +704,7 @@

    - 図17.ページごとの異なるフォントサイズの数の分布。 + 図17.ページごとの異なるフォントサイズの数の分布。
    図 17.ページごとの異なるフォントサイズの数の分布。
    @@ -594,7 +714,7 @@

    マー

    マージンとは、自分の腕を押し出すときに要求するスペースのような要素の外側のスペースです。これは多くの場合、要素間の間隔のように見えますが、その効果に限定されません。 Webサイトまたはアプリでは、間隔はUXとデザインで大きな役割を果たします。スタイルシートにどのくらいのマージン間隔コードが入るか見てみましょうか？

    - 図18.ページごとの異なるマージン値の数の分布。 + 図18.ページごとの異なるマージン値の数の分布。
    図 18.ページごとの異なるマージン値の数の分布。
    @@ -610,7 +730,7 @@

    z-index

    CSSのz-indexを使用して、垂直の階層化またはスタックを管理できます。私たちは、人々が自分のサイトでどれだけ多くの価値を使用しているかに興味がありました。 z-indexが受け入れる範囲は理論的には無限であり、ブラウザーの可変サイズの制限によってのみ制限されます。それらすべてのスタック位置が使用されていますか？　では見てみよう！

    - 図20.ページごとの個別の`z-index`値の数の分布。 + 図20.ページごとの個別の`z-index`値の数の分布。
    図 20.ページごとの個別のz-index値の数の分布。
    @@ -619,7 +739,7 @@

    私たちの仕事の経験から、9の任意の数が最も一般的な選択肢であると思われました。可能な限り少ない数を使用するように教えたにもかかわらず、それは共同の基準ではありません。じゃあ何ですか?!　人々が一番上のものを必要とする場合、最も人気のあるZインデックス番号は何ですか？　飲み物を置いてください。これはあなたがそれを失うかもしれないので十分面白いです。

    - 図21.最も頻繁に使用される`z-index`値。 + 図21.最も頻繁に使用される`z-index`値。
    図 21.最も頻繁に使用されるz-index値。
    @@ -636,7 +756,11 @@

    図 23. フィルタープロパティを持つスタイルシートを含むページの割合。

    スタイルシートの78％にフィルタープロパティが含まれていることがわかりました。その数も非常に高かったので、少し怪しいように思えたので、私たちは深掘りしてその高い数を説明しようとしました。正直に言って、フィルターはきちんとしていますが、すべてのアプリケーションやプロジェクトに組み込まれているわけではありません。しない限り！

    -

    さらなる調査の結果、FontAwesomeのスタイルシートにはフィルターの使用法とYouTube埋め込みが含まれていることがわかりました。そのため、非常に人気のあるいくつかのスタイルシートに便乗することで、バックドアにフィルターが入り込むと考えています。また、-ms-filterの存在も含まれている可能性があり、使用率が高くなっていると考えられます。

    +

    + さらなる調査の結果、FontAwesomehttps://fontawesome.comのスタイルシートにはフィルターの使用法とYouTubehttps://youtube.com埋め込みが含まれていることがわかりました。そのため、非常に人気のあるいくつかのスタイルシートに便乗することで、バックドアにフィルターが入り込むと考えています。また、-ms-filterの存在も含まれている可能性があり、使用率が高くなっていると考えられます。 +

    ブレンドモード

    ブレンドモードは、ターゲット要素のフラットバージョンに対して実行される後処理効果であるという点でフィルターに似ていますが、ピクセル収束に関係しているという点で独特です。別の言い方をすれば、ブレンドモードとは、2つのピクセルが重なり合ったときに互いに影響を与える方法です。上部または下部のどちらの要素でも、ブレンドモードがピクセルを操作する方法に影響します。 16種類のブレンドモードがあります。どのモードが最も人気かを見てみましょう。

    @@ -650,7 +774,7 @@

    - 図25.ページごとの遷移数の分布。 + 図25.ページごとの遷移数の分布。
    図 25.ページごとの遷移数の分布。
    @@ -660,7 +784,7 @@

    - 図26.ページごとのキーフレーム数の分布。 + 図26.ページごとのキーフレーム数の分布。
    図 26.ページごとのキーフレーム数の分布。
    @@ -670,7 +794,7 @@

    - 図27.ページごとのメディアクエリ数の分布。 + 図27.ページごとのメディアクエリ数の分布。
    図 27.ページごとのメディアクエリ数の分布。
    @@ -679,7 +803,7 @@

    ビューポートメディアクエリの場合、任意のタイプのCSSユニットを評価用のクエリ式に渡すことができます。以前、人々はemとpxをクエリに渡していましたが、時間がたつにつれて単位が追加され、Webで一般的に見られるサイズの種類について非常に興味を持ちました。ほとんどのメディアクエリは一般的なデバイスサイズに従うと想定していますが、想定する代わりにデータを見てみましょう。

    - 図28.メディアクエリで使用される最も頻繁に使用されるスナップポイント。 + 図28.メディアクエリで使用される最も頻繁に使用されるスナップポイント。
    図 28.メディアクエリで使用される最も頻繁に使用されるスナップポイント。
    @@ -689,7 +813,7 @@

    - 図29.メディアクエリの方向モードの採用。 + 図29.メディアクエリの方向モードの採用。
    図 29.メディアクエリの方向モードの採用。
    @@ -699,7 +823,7 @@

    - 図30.メディアクエリスナップポイントでのユニットの採用。 + 図30.メディアクエリスナップポイントでのユニットの採用。
    図 30.メディアクエリスナップポイントでのユニットの採用。
    @@ -710,7 +834,7 @@

    人々がメディアクエリを書くとき、彼らは通常、特定の範囲を超えているか下にあるビューポート、またはその両方をチェックして、サイズの範囲内にあるかどうかをチェックしてるでしょうか？　ウェブに聞いてみましょう！

    - 図31.メディアクエリスナップポイントで使用されるプロパティの採用。 + 図31.メディアクエリスナップポイントで使用されるプロパティの採用。
    図 31.メディアクエリスナップポイントで使用されるプロパティの採用。
    @@ -720,7 +844,7 @@

    pr

    Webサイトはデジタルペーパーのように感じますか？　ユーザーとしては、ブラウザーから印刷するだけで、そのデジタルコンテンツを物理コンテンツに変換できることが一般的に知られています。 Webサイトは、そのユースケースに合わせて変更する必要はありませんが、必要に応じて変更できます。あまり知られていないのは、ツールまたはロボットによって読み取られるユースケースでWebサイトを調整する機能です。では、これらの機能はどれくらいの頻度で活用されていますか？

    - 図32.メディアクエリのall、print、screen、およびspeechタイプの採用。 + 図32.メディアクエリのall、print、screen、およびspeechタイプの採用。
    図 32.メディアクエリのall、print、screen、およびspeechタイプの採用。
    @@ -730,7 +854,7 @@

    - 図33.ページごとにロードされるスタイルシートの数の分布。 + 図33.ページごとにロードされるスタイルシートの数の分布。
    図 33.ページごとにロードされるスタイルシートの数の分布。
    @@ -850,7 +974,7 @@

    - 図35.ページごとにロードされるスタイルシートのバイト数（KB）の分布。 + 図35.ページごとにロードされるスタイルシートのバイト数（KB）の分布。
    図 35.ページごとにロードされるスタイルシートのバイト数（KB）の分布。
    @@ -946,19 +1070,22 @@

    図 36.特定のCSSライブラリを含むページの割合。
    -

    このチャートは、Bootstrapがプロジェクトを支援するために知っておくべき貴重なライブラリであることを示唆しています。支援する機会があるすべてを見てください！　すべてのサイトがCSSフレームワークを使用しているわけではないので、これはポジティブなシグナルチャートにすぎないことも注目に値します。100％に達することはありません。すべてのサイトの半分以上が、既知のCSSフレームワークを使用していません。とても面白いですよね！

    +

    + このチャートは、Bootstraphttps://getbootstrap.com/がプロジェクトを支援するために知っておくべき貴重なライブラリであることを示唆しています。支援する機会があるすべてを見てください！　すべてのサイトがCSSフレームワークを使用しているわけではないので、これはポジティブなシグナルチャートにすぎないことも注目に値します。100％に達することはありません。すべてのサイトの半分以上が、既知のCSSフレームワークを使用していません。とても面白いですよね！ +

    リセットユーティリティ

    CSSリセットユーティリティは、ネイティブWeb要素のベースラインを正規化または作成することを目的としています。あなたが知らなかった場合、各ブラウザはすべてのHTML要素に対して独自のスタイルシートを提供し、それら要素の外観、動作について独自の決定を下すことができます。リセットユーティリティはこれらのファイルを調べ、共通点を見つけた（もしくは見つけなかった）ため、開発者が1つのブラウザーでスタイルを設定し、別のブラウザーでも同じように見える合理的な自信を持たせるため、相違点を解決しました。

    それで、どれだけのサイトがそれを使っているかを見てみましょう！　彼らの存在はかなり理にかなっているように思えるので、何人の人々が彼らの戦術に同意し、彼らのサイトでそれらを使用しますか？

    - 図37. CSSリセットユーティリティの採用。 + 図37. CSSリセットユーティリティの採用。
    図 37. CSSリセットユーティリティの採用。

    - Webの約3分の1がnormalize.cssnormalize.csshttps://necolas.github.io/normalize.cssを使用していることがわかります。これは、リセットよりもタスクへのより穏やかなアプローチと考えることができます。少し詳しく見てみると、Bootstrapにはnormalize.cssが含まれていることがわかりました。 normalize.cssがBootstrapよりも多く採用されていることも注目に値するので、それを単独で使用する人がたくさんいます。

    @@ -967,7 +1094,7 @@

    CSS @supportsは、ブラウザが特定のプロパティと値の組み合わせが有効であると解析されたかどうかをチェックし、チェックがtrueを返した場合にスタイルを適用する方法です。

    - 図38. CSS「@」ルールの人気 + 図38. CSS「@」ルールの人気
    図 38. CSS「@」ルールの人気
    @@ -977,84 +1104,78 @@

    結論

    ここには、データマイニングするための非常に多くのものがあります！　結果の多くは私たちを驚かせました、そして同様にあなたも驚いたことを願っています。この驚くべきデータセットにより、要約が非常に楽しくなり、結果の一部がそうである理由を追い詰めたいかどうかを調査するための多くの手がかりと追跡の跡が残されました。

    どの結果が最も驚くべきものでしたか？ どの結果を使用して、コードベースにすばやくクエリを移動しますか？

    -

    これらの結果からの最大のポイントは、スタイルシートのパフォーマンス、乾燥、スケーラビリティの点で、カスタムプロパティが予算に見合った価値を提供することだと感じました。インターネットのスタイルシートを再度スクラブし、新しいデータムと挑発的なチャートの扱いを探しています。クエリ、質問、アサーションを含むコメントで@unaまたは@argyleinkに連絡してください。私たちはそれらを聞きたいです！

    -

    +

    + これらの結果からの最大のポイントは、スタイルシートのパフォーマンス、乾燥、スケーラビリティの点で、カスタムプロパティが予算に見合った価値を提供することだと感じました。インターネットのスタイルシートを再度スクラブし、新しいデータムと挑発的なチャートの扱いを探しています。クエリ、質問、アサーションを含むコメントで@unahttps://twitter.com/unaまたは@argyleinkhttps://twitter.com/argyleinkに連絡してください。私たちはそれらを聞きたいです！ +

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":3,"title":"マークアップ","description":"使われている要素、カスタム要素、価値、製品、及び一般的なユースケースについて抑えてある 2019 Web Almanac マークアップの章","authors":["bkardell"],"reviewers":["zcorpan","tomhodgins","matthewp"],"translators":["MSakamaki"],"discuss":"1758","results":"https://docs.google.com/spreadsheets/d/1WnDKLar_0Btlt9UgT53Giy2229bpV4IM2D_v6OM_WzA/","queries":"03_Markup","published":"2019-11-11","last_updated":"2020-05-19","chapter":"markup"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 3 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - マークアップ +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":3,"title":"マークアップ","description":"使われている要素、カスタム要素、価値、製品、及び一般的なユースケースについて抑えてある 2019 Web Almanac マークアップの章","authors":["bkardell"],"reviewers":["zcorpan","tomhodgins","matthewp"],"translators":["MSakamaki"],"discuss":"1758","results":"https://docs.google.com/spreadsheets/d/1WnDKLar_0Btlt9UgT53Giy2229bpV4IM2D_v6OM_WzA/","queries":"03_Markup","published":"2019-11-11","last_updated":"2020-05-19","chapter":"markup"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -1063,23 +1184,37 @@

    - + -
    {{ self.written_by_before() }} Brian Kardell{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Simon Pieters, Tommy Hodgins, {{ self.and() }} Matthew Phillips{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} M.Sakamaki{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    -

    2005年にIan "Hixie" Hicksonはこれまでの研究に基づいたマークアップデータの分析を投稿しました。 この作業のほとんどは、クラス名を調査して、内々で開発者が採用しているセマンティクスを確認し、標準化する意味があるかの確認をすることが目的でした。 この研究の一部は、HTML5の新要素の参考として役に立ちました。

    -

    14年すぎて、新しい見方をする時が来ました。 以降、カスタム要素(Custom Elements)とExtensible Web Manifestoの導入により、開発者は要素そのものの空間を探し、標準化団体が辞書編集者のようになることで、牛の通り道を舗装する(pave the cowpaths)よりよい方法を見つけることを推奨しています。 様々なものに使われる可能性があるCSSクラス名とは異なり、非標準の要素は作成者が要素であることを意識しているため、さらに確実なものとなります。

    +

    + 2005年にIan "Hixie" Hicksonはこれまでの研究に基づいたマークアップデータの分析https://web.archive.org/web/20060203035414/http://code.google.com/webstats/index.htmlを投稿しました。 この作業のほとんどは、クラス名を調査して、内々で開発者が採用しているセマンティクスを確認し、標準化する意味があるかの確認をすることが目的でした。 この研究の一部は、HTML5の新要素の参考として役に立ちました。 +

    +

    + 14年すぎて、新しい見方をする時が来ました。 以降、カスタム要素(Custom Elements)https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elementsとExtensible Web Manifestohttps://extensiblewebmanifesto.org/の導入により、開発者は要素そのものの空間を探し、標準化団体が辞書編集者のようになるhttps://bkardell.com/blog/Dropping-The-F-Bomb-On-Standards.htmlことで、牛の通り道を舗装する(pave the cowpaths)よりよい方法を見つけることを推奨しています。 様々なものに使われる可能性があるCSSクラス名とは異なり、非標準の要素は作成者が要素であることを意識しているため、さらに確実なものとなります。 +

    2019年7月の時点で、HTTP Archiveは、約440万のデスクトップホームページと約530万のモバイルホームページのDOMで使用されているすべての要素名の収集を開始しました。 (方法論の詳細を御覧ください)

    このクロールの結果、5,000種類を超える非標準の要素が検出されたため、計測する要素の合計数を「トップ」（以下で説明）5,048種類に制限しました。

    方法論

    各ページの要素の名前は、JavaScriptの初期化後DOMより収集されました。

    -

    現実の要素出現数を確認することは標準の要素であっても有用ではありません、検出されたすべての要素の約25%は<div>です。 そして、約17%が<a>で、11%が<span>となっており、これらは10%以上を占める唯一の要素たちです。 言語は一般的にこのようなものですが、これと比較してみると驚くほど少ない用語が使われています。 さらに、非標準の要素の取り込みを検討してみると、１つのサイトが特定の要素を1000回も使用しているために、とても人気があるように見えてしまい、大きな誤解を招く可能性があります。

    +

    + 現実の要素出現数を確認することは標準の要素であっても有用ではありません、検出されたすべての要素の約25%は<div>です。 そして、約17%が<a>で、11%が<span>となっており、これらは10%以上を占める唯一の要素たちです。 言語は一般的にこのようなものhttps://www.youtube.com/watch?v=fCn8zs912OEですが、これと比較してみると驚くほど少ない用語が使われています。 さらに、非標準の要素の取り込みを検討してみると、１つのサイトが特定の要素を1000回も使用しているために、とても人気があるように見えてしまい、大きな誤解を招く可能性があります。 +

    そのような方法を取らず、私達はHixieの元の研究のようにホームページに各要素が少なくとも1回は含まれているサイトの数に着目しました。

    注意: この方法は潜在的なバイアスが無いとは言い切れません。 人気のある製品は複数のサイトで使われています。これにより個々の作成者は意識していない非標準のマークアップが導入されるでしょう。 したがって、この方法は一般的なニーズに対応するのと同じように、作成者の直接的な知識や意識的な採用を意味しないことに注意する必要があります。 調査中に、このような例はいくつか見つかりました。 @@ -1146,26 +1281,26 @@

    ページ毎の要素

    - Hixieによる2005年の要素頻度の分布 + Hixieによる2005年の要素頻度の分布
    図 2. Hixieによる2005年の要素頻度の分布。
    - 図3. 2019年の要素頻度 + 図3. 2019年の要素頻度
    図 3. 2019年の要素頻度。

    図2の2005年のHixieのレポートと図3の最新データを比較すると、DOMツリーの平均サイズが大きくなっていることがわかります。

    - 図4. 2005年にHixieが分析したページ毎の要素タイプのヒストグラム + 図4. 2005年にHixieが分析したページ毎の要素タイプのヒストグラム
    図 4. 2005年にHixieが分析したページ毎の要素タイプのヒストグラム。
    - 図5. 2019年時点でのページ毎の要素タイプのヒストグラム。 + 図5. 2019年時点でのページ毎の要素タイプのヒストグラム。
    図 5. 2019年時点でのページ毎の要素タイプのヒストグラム。
    @@ -1200,7 +1335,7 @@

    注意：この結果は、それぞれのの作成者がマークアップを手動で作成しているのではなく、何らかの製品を使っている為と考えられます。

    - 図6.最も頻繁に使われている非推奨の要素。 + 図6.最も頻繁に使われている非推奨の要素。
    図 6.最も頻繁に使われている非推奨の要素。
    @@ -1210,7 +1345,7 @@

    要素の使い方に関する数値（標準、非推奨、またはカスタム）を議論する為には、まず何らかの観点を確立する必要があります。

    - 図7.トップ150の要素。 + 図7.トップ150の要素。
    図 7.トップ150の要素（詳細）。
    @@ -1253,7 +1388,7 @@

    これらの要素の分布を抑え、どの要素が1％以上使われているのかを見るのは興味深いことです。

    - 図8. 標準化によって人気になった要素の分類 + 図8. 標準化によって人気になった要素の分類
    図 8. 標準化によって人気になった要素の分類。
    @@ -1267,56 +1402,67 @@

    大量データ：実際のWeb上の実際のDOM

    データセット中のネイティブ/標準機能をどのように使っているかと言う観点を念頭に置いて、非標準のものについて話しましょう。

    測定したほとんどの要素は単一のWebページでのみ使用されると思われるかもしれませんが、実際には5,048個の要素すべてが複数のページに出現しています。 データセット中、最も出現数が少ない要素は15ページに存在しています。 そして、約5分の1は100ページ以上に存在します。 約7％は1,000ページ以上に存在します。

    -

    データ分析を支援するためにGlitchで小さなツールを共同で作りました。 このツールはあなたも使うことができます。そして、あなたの観測した内容をパーマリンクと共に@HTTPArchiveへシェアしてください。（Tommy Hodginsは、同じように洞察に使えるCLIツールを作成しています。）

    +

    + データ分析を支援するためにGlitchで小さなツールhttps://rainy-periwinkle.glitch.meを共同で作りました。 このツールはあなたも使うことができます。そして、あなたの観測した内容をパーマリンクと共に@HTTPArchivehttps://twitter.com/HTTPArchiveへシェアしてください。（Tommy Hodginsは、同じように洞察に使えるCLIツールhttps://github.com/tomhodgins/hadeを作成しています。） +

    それでは、いくつかのデータを見ていきましょう。

    製品（およびライブラリ）とそのカスタムマークアップ

    -

    いくつかの標準でない要素の普及率については、ファーストパーティの採用をしたというより、人気のあるサードパーティのツールに含まれていることが関係しているでしょう。たとえば <fb:like> 要素は0.03%のページで見つかります。これはサイト所有者が意図的に記述しているのではなく、Facebookウィジェットに含まれているためです。Hixieが14年前に言及した要素のほとんどは減少しているように見えますが、大部分が残っています。

    +

    + いくつかの標準でない要素の普及率については、ファーストパーティの採用をしたというより、人気のあるサードパーティのツールに含まれていることが関係しているでしょう。たとえば <fb:like> 要素は0.03%のページで見つかります。これはサイト所有者が意図的に記述しているのではなく、Facebookウィジェットに含まれているためです。Hixieが14年前に言及したhttps://web.archive.org/web/20060203031245/http://code.google.com/webstats/2005-12/editors.html要素のほとんどは減少しているように見えますが、大部分が残っています。 +

    • - Claris Home Page（最後の安定版は21年前）で作られた一般的要素は、100ページ以上にまだ現れてます。 たとえば、<x-claris-window>Claris Home Pagehttps://en.wikipedia.org/wiki/Claris_Home_Page（最後の安定版は21年前）で作られた一般的要素は、100ページ以上にまだ現れてます。 たとえば、<x-claris-window>https://rainy-periwinkle.glitch.me/permalink/28b0b7abb3980af793a2f63b484e7815365b91c04ae625dd4170389cc1ab0a52.htmlは130ページに現れています。
    • - 英国のeコマースプロバイダーであるOxatisの<actinic:*> 要素の一部はさらに多くのページに出現しています。たとえば、<actinic:basehref>Oxatishttps://www.oxatis.co.ukの<actinic:*> 要素の一部はさらに多くのページに出現しています。たとえば、<actinic:basehref>https://rainy-periwinkle.glitch.me/permalink/30dfca0fde9fad9b2ec58b12cb2b0271a272fb5c8970cd40e316adc728a09d19.htmlはデスクトップデータ中の154ページに出現しています。
    • Macromediaの要素はほとんど消えたようです。一覧にはたった一つの要素<mm:endlock>だけが現れており、その数はわずか22ページだけです。
    • - Adobe Go-Liveの<csscriptdict><csscriptdict>https://rainy-periwinkle.glitch.me/permalink/579abc77652df3ac2db1338d17aab0a8dc737b9d945510b562085d8522b18799.htmlは、デスクトップデータセットの640ページに引き続いて現れています。
    • - Microsoft Officeの<o:p><o:p>https://rainy-periwinkle.glitch.me/permalink/bc8f154a95dfe06a6d0fdb099b6c8df61727b2289141a0ef16dc17b2b57d3068.html要素は、2万ページ以上のデスクトップページとなる0.5％に引き続いて現れています。

    そして、Hixieのオリジナルレポートにはなかった多くの新しい要素も現れました。

    • - <ym-measure>は、YandexのMetrica analytics packageによって挿入されるタグです。デスクトップとモバイルページの1％以上で使われており、最も利用されている要素トップ100でその地位を確立しています。すごい！ + <ym-measure>https://rainy-periwinkle.glitch.me/permalink/e8bf0130c4f29b28a97b3c525c09a9a423c31c0c813ae0bd1f227bd74ddec03d.htmlは、YandexのMetrica analytics packagehttps://www.npmjs.com/package/yandex-metrica-watchによって挿入されるタグです。デスクトップとモバイルページの1％以上で使われており、最も利用されている要素トップ100でその地位を確立しています。すごい！
    • - 今は亡きGoogle Plusの<g:plusone><g:plusone>https://rainy-periwinkle.glitch.me/permalink/a532f18bbfd1b565b460776a64fa9a2cdd1aa4cd2ae0d37eb2facc02bfacb40c.htmlは、2万1千ページ以上で出現しています。
    • - Facebookの<fb:like><fb:like>https://rainy-periwinkle.glitch.me/permalink/2e2f63858f7715ef84d28625344066480365adba8da8e6ca1a00dfdde105669a.htmlは、14,000のモバイルページで出現しています。
    • - 同様に、<fb:like-box><fb:like-box>https://rainy-periwinkle.glitch.me/permalink/5a964079ac2a3ec1b4f552503addd406d02ec4ddb4955e61f54971c27b461984.htmlは7.8kモバイルページで出現しています。
    • - <app-root><app-root>https://rainy-periwinkle.glitch.me/permalink/6997d689f56fe77e5ce345cfb570adbd42d802393f4cc175a1b974833a0e3cb5.htmlは、Angularなどのフレームワークで一般的に含まれており、8.2kモバイルページに出現しています。

    これらを5％未満のネイティブHTML要素と比べてみましょう。

    - 図9. 採用率が5％以下での、製品固有とネイティブで人気の要素。 + 図9. 採用率が5％以下での、製品固有とネイティブで人気の要素。
    図 9. 採用率が5％以下での、製品固有とネイティブで人気の要素。
    @@ -1325,36 +1471,56 @@

    が出現しています。 しかしこれは、これは人気のある"as-a-service"製品がスペースを取り忘れているために発生していました。 幸いなことに、このエラーは調査中に報告されて、すぐに修正されました。

    Hixieはオリジナルの論文で次のように述べています。

    この非標準マークアップに対して楽天的でいられる間は少なくとも、これらの要素にはベンダープレフィックスを明確に利用しているため、これは良い考えだと言えます。これにより、標準化団体が新しく作る要素と属性が、それらと衝突する可能性を大幅に減らすことができます。
    -

    ただし、上で述べた通りこれは一般的ではありません。 記録できた非標準要素の25％以上は、グローバル名前空間の汚染を避けるために、いかなる名前空間戦略も使っていません。 例えば、モバイルデータセットにある1157個の要素一覧を表示します。 見ての通り、これらの多くは曖昧な名前やつづりの間違など、問題がない可能性があります。 しかし、少なくともこれはいくつかの挑むべき課題を示しています。 例えば、 <toast>（Google社員が<std-toast>として最近提案しようとした仕様）がこの一覧に含まれています。

    +

    + ただし、上で述べた通りこれは一般的ではありません。 記録できた非標準要素の25％以上は、グローバル名前空間の汚染を避けるために、いかなる名前空間戦略も使っていません。 例えば、モバイルデータセットにある1157個の要素一覧https://rainy-periwinkle.glitch.me/permalink/53567ec94b328de965eb821010b8b5935b0e0ba316e833267dc04f1fb3b53bd5.htmlを表示します。 見ての通り、これらの多くは曖昧な名前やつづりの間違など、問題がない可能性があります。 しかし、少なくともこれはいくつかの挑むべき課題を示しています。 例えば、 <toast>（Google社員が<std-toast>として最近提案しようとした仕様https://www.chromestatus.com/feature/5674896879255552）がこの一覧に含まれています。 +

    それほど難しくない一般的な要素もいくつかあります。

    • - Yahoo Mapsの<ymaps><ymaps>https://rainy-periwinkle.glitch.me/permalink/2ba66fb067dce29ecca276201c37e01aa7fe7c191e6be9f36dd59224f9a36e16.htmlは、〜12.5kのモバイルページに出現します。
    • - 2008年のフォント置換ライブラリである<cufon>と <cufontext><cufon>と <cufontext>https://rainy-periwinkle.glitch.me/permalink/5cfe2db53aadf5049e32cf7db0f7f6d8d2f1d4926d06467d9bdcd0842d943a17.htmlは、〜10.5kモバイルページに出現しています。
    • - <jdiv><jdiv>https://rainy-periwinkle.glitch.me/permalink/976b0cf78c73d125644d347be9e93e51d3a9112e31a283259c35942bda06e989.html要素は、Jivo chatの製品によって挿入されており、〜40.3kモバイルページに出現しています。

    前回のチャートに今回のデータを配置すると、次のようになります（改めて、データセットに基づいて少しだけ変わっています）

    - 図10. 採用率が5％以下での、製品固有のコンテキストまたはネイティブで人気のあるその他の要素。 + 図10. 採用率が5％以下での、製品固有のコンテキストまたはネイティブで人気のあるその他の要素。
    図 10. 採用率が5％以下での、製品固有のコンテキストまたはネイティブで人気のあるその他の要素。

    この結果には興味深い点があります、それは一つのツールが他の便利になる手段も提供していると言うことです。 データ空間を調べることに興味がある場合に、具体的なタグ名は想定される尺度の一つでしかありません。 良い「俗語」の発展を見つけることができれば、それは間違いなく最強の指標でしょう。 しかし、それが私たちの興味の範囲外である場合はどうなりますか？

    一般的なユースケースとソリューション

    -

    たとえば、一般的なユースケースの解決に興味が人々の場合はどうでしょうか？ これは、現在抱えているユースケースに対応したソリューションを探している場合や、標準化を促進するために人々が解決しようとしている一般的なユースケースをさらに研究するようなものがあります。 一般的な例として「タブ」を取り上げます。 長年にわたって、タブのようなものに対して多くの要求がありました。あいまいな検索をしてみるとタブには多くのバリエーションがあることがわかります。 同一のページに2つの要素が存在しているかを簡単に識別できないため、利用されているかどうかを数えるのは少し難しくなります。そのためこの計測条件は地味ですが、最大のカウントを持つものを単純に使用します。 ほとんどの場合、実際のページ数はそれより大幅に増えるでしょう。

    -

    また、数多くのアコーディオンやダイアログ、少なくとも65種類のカルーセル、それとポップアップに関するもの、そして最低でも27種類存在するトグルとスイッチがあります。

    -

    おそらくですが、非ネイティブである92種類のボタン要素が必要な理由を調査することで、ネイティブとのギャップを埋めようとすることができます。

    -

    人気の有るものがポップアップ（<jdiv>などのチャット）という事に気付く事ができれば 、私達の知っている知識（たとえば、<jdiv>についての目的や<olark>）を知り、それらに取り組むために作り上げた43のことを見て、そこを辿りながら空間を調査することができます。

    +

    + たとえば、一般的なユースケースの解決に興味が人々の場合はどうでしょうか？ これは、現在抱えているユースケースに対応したソリューションを探している場合や、標準化を促進するために人々が解決しようとしている一般的なユースケースをさらに研究するようなものがあります。 一般的な例として「タブ」を取り上げます。 長年にわたって、タブのようなものに対して多くの要求がありました。あいまいな検索をしてみるとタブには多くのバリエーションhttps://rainy-periwinkle.glitch.me/permalink/c6d39f24d61d811b55fc032806cade9f0be437dcb2f5735a4291adb04aa7a0ea.htmlがあることがわかります。 同一のページに2つの要素が存在しているかを簡単に識別できないため、利用されているかどうかを数えるのは少し難しくなります。そのためこの計測条件は地味ですが、最大のカウントを持つものを単純に使用します。 ほとんどの場合、実際のページ数はそれより大幅に増えるでしょう。 +

    +

    + また、数多くのアコーディオンhttps://rainy-periwinkle.glitch.me/permalink/e573cf279bf1d2f0f98a90f0d7e507ac8dbd3e570336b20c6befc9370146220b.htmlやダイアログhttps://rainy-periwinkle.glitch.me/permalink/0bb74b808e7850a441fc9b93b61abf053efc28f05e0a1bc2382937e3b78695d9.html、少なくとも65種類のカルーセルhttps://rainy-periwinkle.glitch.me/permalink/651e592cb2957c14cdb43d6610b6acf696272b2fbd0d58a74c283e5ad4c79a12.html、それとポップアップhttps://rainy-periwinkle.glitch.me/permalink/981967b19a9346ac466482c51b35c49fc1c1cc66177ede440ab3ee51a7912187.htmlに関するもの、そして最低でも27種類存在するトグルとスイッチhttps://rainy-periwinkle.glitch.me/permalink/2e6827af7c9d2530cb3d2f39a3f904091c523c2ead14daccd4a41428f34da5e8.htmlがあります。 +

    +

    + おそらくですが、非ネイティブである92種類のボタン要素https://rainy-periwinkle.glitch.me/permalink/5ae67c941395ca3125e42909c2c3881e27cb49cfa9aaf1cf59471e3779435339.htmlが必要な理由を調査することで、ネイティブとのギャップを埋めようとすることができます。 +

    +

    + 人気の有るものがポップアップ（<jdiv>などのチャット）という事に気付く事ができれば 、私達の知っている知識（たとえば、<jdiv>についての目的や<olark>）を知り、それらに取り組むために作り上げた43のことhttps://rainy-periwinkle.glitch.me/permalink/db8fc0e58d2d46d2e2a251ed13e3daab39eba864e46d14d69cc114ab5d684b00.htmlを見て、そこを辿りながら空間を調査することができます。 +

    結論

    なのでここには多くのデータがありますが、要約すると。

      @@ -1365,55 +1531,77 @@

      結論既に大量のカスタムマークアップがあります。様々な形式がありますが、ダッシュを含む要素は確実に削除されたようです。
    • 牛の通り道を舗装する(pave the cowpaths)ために、このデータをさらに調査して、適切な観測結果を出す必要があります。

    -

    最後はあなたの出番です。 大規模なコミュニティの創造性と好奇心を利用し、いくつかのツール(https://rainy-periwinkle.glitch.me/など)を使うことでこのデータを探索することができます。 興味深い観察結果を共有して、知識と理解の共有の場を作ってください。

    -

    +

    + 最後はあなたの出番です。 大規模なコミュニティの創造性と好奇心を利用し、いくつかのツール(https://rainy-periwinkle.glitch.me/https://rainy-periwinkle.glitch.me/など)を使うことでこのデータを探索することができます。 興味深い観察結果を共有して、知識と理解の共有の場を作ってください。 +

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":4,"title":"メディア","description":"2019年版Web Almanacのメディアの章では、画像ファイルのサイズとフォーマット、レスポンシブ画像、クライアントのヒント、遅延読み込み、アクセシビリティ、動画を取り上げています。","authors":["colinbendell","dougsillars"],"reviewers":["ahmadawais","eeeps"],"translators":["ksakae"],"discuss":"1759","results":"https://docs.google.com/spreadsheets/d/1hj9bY6JJZfV9yrXHsoCRYuG8t8bR-CHuuD98zXV7BBQ/","queries":"04_Media","published":"2019-11-11","last_updated":"2020-05-19","chapter":"media"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 4 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - メディア +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":4,"title":"メディア","description":"2019年版Web Almanacのメディアの章では、画像ファイルのサイズとフォーマット、レスポンシブ画像、クライアントのヒント、遅延読み込み、アクセシビリティ、動画を取り上げています。","authors":["colinbendell","dougsillars"],"reviewers":["ahmadawais","eeeps"],"translators":["ksakae"],"discuss":"1759","results":"https://docs.google.com/spreadsheets/d/1hj9bY6JJZfV9yrXHsoCRYuG8t8bR-CHuuD98zXV7BBQ/","queries":"04_Media","published":"2019-11-11","last_updated":"2020-05-19","chapter":"media"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -1422,30 +1610,42 @@

    - + -
    {{ self.written_by_before() }} Colin Bendell, {{ self.and() }} Doug Sillars{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Ahmad Awais, {{ self.and() }} Eric Portis{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    画像、アニメーション、動画はウェブ体験の重要な一部です。それらが重要な理由はたくさんあります。ストーリーを伝えたり、視聴者の関心を引きつけたり、他のウェブ技術では簡単には作れないような芸術的な表現を提供したりするのに役立ちます。これらのメディアリソースの重要性は、2つの方法で示すことができます。1つは、1ページのダウンロードに必要なバイト数の多さ、もう1つはメディアで描かれたピクセル数の多さです。

    -

    純粋なバイトの観点から見ると、HTTP Archiveは歴史的に報告されているメディアから関連付けられたリソースバイトの平均3分の2を持っています。分布の観点から見ると、事実上すべてのウェブページが画像や動画に依存していることがわかります。10パーセンタイルでさえ、我々はバイトの44％がメディアからであり、ページの90パーセンタイルで総バイトの91％に上昇できることを参照してください。

    +

    + 純粋なバイトの観点から見ると、HTTP Archiveは歴史的に報告されているhttps://legacy.httparchive.org/interesting.php#bytesperpageメディアから関連付けられたリソースバイトの平均3分の2を持っています。分布の観点から見ると、事実上すべてのウェブページが画像や動画に依存していることがわかります。10パーセンタイルでさえ、我々はバイトの44％がメディアからであり、ページの90パーセンタイルで総バイトの91％に上昇できることを参照してください。 +

    - 図1. Webページのバイト：画像と動画対その他。 + 図1. Webページのバイト：画像と動画対その他。
    図 1. Webページのバイト：画像と動画対その他。

    メディアは視覚体験には欠かせないものですが、この大量のバイトのインパクトには2つの副作用があります。

    まず、これらのバイトをダウンロードするために必要なネットワークのオーバーヘッドは大きく、携帯電話や低速ネットワーク環境（コーヒーショップやUberに乗っているときのテザリングのような）では劇的にページのパフォーマンスを遅くできます。画像はブラウザによる優先度の低いリクエストですが、ダウンロード中のCSSやJavaScriptを簡単にブロックできます。これ自体がページのレンダリングを遅らせることになります。しかし、画像コンテンツは、ページの準備ができたことをユーザーに視覚的に伝える手がかりとなります。そのため、画像コンテンツの転送が遅いと、ウェブページが遅いという印象を与えることがあります。

    -

    2つ目の影響は、ユーザーへの金銭的なコストです。これはウェブサイトの所有者の負担ではなく、エンドユーザーの負担となるため、しばしば無視されがちな側面です。逸話として、日本のようなという市場では、データの上限に達した月末近くは学生の購買意欲が低下し、ユーザーはビジュアルコンテンツを見ることができなくなるということが伝えられています。

    -

    さらに、世界のさまざまな地域でこれらのウェブサイトを訪問するための金銭的コストは不釣り合いです。中央値と90パーセンタイルでは、画像のバイト数はそれぞれ1MBと1.9MBです。WhatDoesMySiteCost.comを使用すると、マダガスカルのユーザーの一人当たりの国民総所得（GNI）コストは90パーセンタイルでウェブページを1回読み込んだだけで、一日の総所得の2.6％になることがわかります。対照的に、ドイツでは、これは1日の総所得の0.3％になります。

    +

    + 2つ目の影響は、ユーザーへの金銭的なコストです。これはウェブサイトの所有者の負担ではなく、エンドユーザーの負担となるため、しばしば無視されがちな側面です。逸話として、日本のようなhttps://twitter.com/yoavweiss/status/1195036487538003968?s=20という市場では、データの上限に達した月末近くは学生の購買意欲が低下し、ユーザーはビジュアルコンテンツを見ることができなくなるということが伝えられています。 +

    +

    + さらに、世界のさまざまな地域でこれらのウェブサイトを訪問するための金銭的コストは不釣り合いです。中央値と90パーセンタイルでは、画像のバイト数はそれぞれ1MBと1.9MBです。WhatDoesMySiteCost.comhttps://whatdoesmysitecost.com/#gniCostを使用すると、マダガスカルのユーザーの一人当たりの国民総所得（GNI）コストは90パーセンタイルでウェブページを1回読み込んだだけで、一日の総所得の2.6％になることがわかります。対照的に、ドイツでは、これは1日の総所得の0.3％になります。 +

    - 図2. ウェブページあたりの総画像バイト数（モバイル）。 + 図2. ウェブページあたりの総画像バイト数（モバイル）。
    図 2. ウェブページあたりの総画像バイト数（モバイル）。
    @@ -1465,14 +1665,14 @@

    序章

    - 図3. 1ページあたりのピクセル画像（モバイル）。CSS対実物。 + 図3. 1ページあたりのピクセル画像（モバイル）。CSS対実物。
    図 3. 1ページあたりのピクセル画像（モバイル）。CSS対実物。
    - 図4. 1ページあたりのピクセル画像（デスクトップ）。CSS対実物。 + 図4. 1ページあたりのピクセル画像（デスクトップ）。CSS対実物。
    図 4. 1ページあたりのピクセル画像（デスクトップ）。CSS対実物。
    @@ -1486,7 +1686,7 @@

    序章

    注：これは、viperとレイアウトコンテンツのボリュームの両方のCSSレイアウトを見ているだけです。レスポンシブ画像の効果や、DPRの高いコンテンツを提供することの効果を評価しているわけではありません。

    - 図5. 画像のピクセル量と画面サイズ（CSSピクセル）の関係。 + 図5. 画像のピクセル量と画面サイズ（CSSピクセル）の関係。
    図 5. 画像のピクセル量と画面サイズ（CSSピクセル）の関係。
    @@ -1583,7 +1783,10 @@

    画像

    @@ -1605,7 +1808,7 @@

    - Most frequent Image types used on web pages + Most frequent Image types used on web pages
    図 7. 画像フォーマットの使用法
    @@ -1613,7 +1816,7 @@

    - Figure 8. Image format usage per page. + Figure 8. Image format usage per page.
    図 8. 1ページあたりの画像フォーマットの使用量
    @@ -1621,7 +1824,7 @@

    - 図9. 少なくとも1枚の画像を使用しているページの割合。 + 図9. 少なくとも1枚の画像を使用しているページの割合。
    図 9. 少なくとも1枚の画像を使用しているページの割合。
    @@ -1631,7 +1834,7 @@

    - A comparison of image formats by file size + A comparison of image formats by file size
    図 10. 画像形式別のファイルサイズ（KB）。
    @@ -1639,7 +1842,7 @@

    - 図11. ピクセルあたりのバイト数。 + 図11. ピクセルあたりのバイト数。
    図 11. ピクセルあたりのバイト数。
    @@ -1654,7 +1857,7 @@

    Lighthouseテストは、ベースラインとプログレッシブにエンコードされたJPEGをA/Bで比較するものです。これは画像全体がロスレス技術でさらに最適化されるか、また異なる品質レベルを使用するなど、潜在的には不可逆技術で最適化されるかどうかを示すための気付きを提供しています。

    - 図12. 「最適化された」画像の割合。 + 図12. 「最適化された」画像の割合。
    図 12. 「最適化された」画像の割合。
    @@ -1662,7 +1865,7 @@

    - 図13. Lighthouseからの画像最適化によるページパフォーマンスの向上を予測。 + 図13. Lighthouseからの画像最適化によるページパフォーマンスの向上を予測。
    図 13. Lighthouseからの画像最適化によるページパフォーマンスの向上を予測。
    @@ -1678,12 +1881,15 @@

    - 図14. HTMLでレスポンシブ画像を使用しているページの割合。 + 図14. HTMLでレスポンシブ画像を使用しているページの割合。
    図 14. HTMLでレスポンシブ画像を使用しているページの割合。

    -

    アートディレクションのような高度なレスポンシブウェブデザイン（RWD）レイアウトによく使われていることを考えると、<picture>の使用率が著しく低いのは驚くべきことでありません。

    +

    + アートディレクションhttps://developer.mozilla.org/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images#Art_directionのような高度なレスポンシブウェブデザイン（RWD）レイアウトによく使われていることを考えると、<picture>の使用率が著しく低いのは驚くべきことでありません。 +

    サイズの使用

    srcsetの有用性は、通常はsizesメディアクエリの精度に依存します。sizesがないと、ブラウザは<img>タグが小さいコンポーネントではなくビューポート全体を埋め尽くすと仮定します。興味深いことに、ウェブ開発者が<img sizes>に採用している共通のパターンは5つあります。

      @@ -1752,17 +1958,19 @@

      - 図16. 'img sizes'のトップパターン。 + 図16. 'img sizes'のトップパターン。
      図 16. <img sizes>のトップパターン。

    クライアントヒント

    -

    クライアントヒント は、コンテンツ制作者が画像のリサイズをHTTPコンテンツネゴシエーションに移すことを可能にします。この方法では、HTMLはマークアップを乱雑にするための追加の <img srcset> を必要とせず、代わりにサーバや 最適な画像を選択するための画像CDN に依存できます。これによりHTMLの簡素化が可能になり、オリジンサーバが時間の経過とともに適応し、コンテンツ層とプレゼンテーション層を切り離すことが可能になります。

    +

    + クライアントヒントhttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/client-hints は、コンテンツ制作者が画像のリサイズをHTTPコンテンツネゴシエーションに移すことを可能にします。この方法では、HTMLはマークアップを乱雑にするための追加の <img srcset> を必要とせず、代わりにサーバや 最適な画像を選択するための画像CDNhttps://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67 に依存できます。これによりHTMLの簡素化が可能になり、オリジンサーバが時間の経過とともに適応し、コンテンツ層とプレゼンテーション層を切り離すことが可能になります。 +

    クライアントヒントを有効にするには、ウェブページでブラウザに追加のHTTPヘッダーAccept-CH: DPR, Width, Viewport-Widthを使ってシグナルを送る必要があります。 または HTML<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">を追加します。どちらか一方の手法の利便性は実装するチームに依存し、どちらも利便性のために提供されています。

    - Accept-CH の使用法: HTTP と HTML の比較。 + Accept-CH の使用法: HTTP と HTML の比較。
    図 17. Accept-CHヘッダーと同等の<meta>タグの使用法。
    @@ -1771,7 +1979,7 @@

    - 図18. 有効化されたクライアントヒント。 + 図18. 有効化されたクライアントヒント。
    図 18. 有効化されたクライアントヒント。
    @@ -1779,17 +1987,24 @@

    遅延ローディング

    ウェブページのパフォーマンスを改善することは、部分的にはイリュージョンのゲームとして特徴付けることができます。このように遅延読み込み画像は、ユーザーがページをスクロールしたときにのみ画像やメディアコンテンツが読み込まれる、これらのイリュージョンの1つです。これにより、遅いネットワークでも知覚パフォーマンスが向上し、ユーザーが他の方法で表示されていないバイトをダウンロードする手間が省けます。

    -

    以前、図5で、75パーセンタイルの画像コンテンツの量が、理論的には単一のデスクトップやモバイルのビューポートで表示できる量をはるかに超えていることを示しました。オフスクリーン画像Lighthouseの監査は、この疑念を裏付けています。ウェブページの中央値では、折り目の下に27％の画像コンテンツがあります。これは、90パーセンタイルの割合で84％に増加しています。

    +

    + 以前、図5で、75パーセンタイルの画像コンテンツの量が、理論的には単一のデスクトップやモバイルのビューポートで表示できる量をはるかに超えていることを示しました。オフスクリーン画像https://developers.google.com/web/tools/lighthouse/audits/offscreen-imagesLighthouseの監査は、この疑念を裏付けています。ウェブページの中央値では、折り目の下に27％の画像コンテンツがあります。これは、90パーセンタイルの割合で84％に増加しています。 +

    - 図19. Lighthouse監査：オフスクリーン。 + 図19. Lighthouse監査：オフスクリーン。
    図 19. Lighthouse監査：オフスクリーン。

    Lighthouseの監査では、質の高いプレースホルダーを使用するなど、油断できない状況がいくつもあるため、臭いを嗅ぎ分けてくれます。

    -

    遅延ローディングはIntersection Observers、Resize Observersの組み合わせを含め実装可能 です、またはlazySizes、lozadなどのJavaScriptライブラリの使用などさまざまな方法で実装できます。

    -

    2019年8月、Chrome76では<img loading="lazy">を使用したマークアップベースの遅延ローディングのサポートが開始されました。2019年のWeb Almanacに使用されたウェブサイトのスナップショットは2019年7月のデータを使用していますが、2,509以上のウェブサイトがすでにこの機能を利用していました。

    +

    + 遅延ローディングはIntersection Observers、Resize Observersの組み合わせを含め実装可能https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video です、またはlazySizeshttps://github.com/aFarkas/lazysizes、lozadhttps://github.com/ApoorvSaxena/lozad.jsなどのJavaScriptライブラリの使用などさまざまな方法で実装できます。 +

    +

    2019年8月、Chrome76では<img>を使用したマークアップベースの遅延ローディングのサポートが開始されました。2019年のWeb Almanacに使用されたウェブサイトのスナップショットは2019年7月のデータを使用していますが、2,509以上のウェブサイトがすでにこの機能を利用していました。

    アクセンシビリティ

    画像アクセシビリティの中心にあるのは alt タグです。画像に alt タグが追加されると、このテキストは画像を見ることができない（障害のある、インターネット接続が悪いのいずれかの理由で）ユーザーに画像を説明するために使用されます。

    データセットのHTMLファイルに含まれるすべての画像タグを検出できます。デスクトップでは1,300万個、モバイルでは1,500万個の画像タグのうち、91.6％の画像にaltタグが存在しています。一見すると、ウェブ上では画像のアクセシビリティは非常に良好な状態にあるように見えます。しかし、よく調べてみると、見通しはあまり良くありません。データセットに存在するaltタグの長さを調べると、altタグの長さの中央値は6文字であることがわかります。これは空のaltタグ（alt=""のように見える）に対応する。6文字以上の長さのaltテキストを使用している画像は全体の39％にすぎない。実際の」altテキストの中央値は31文字で、そのうち25文字が実際に画像を説明しています。

    @@ -1799,7 +2014,7 @@

    - 図20. 拡張子別の動画ファイルの数 + 図20. 拡張子別の動画ファイルの数
    図 20. 拡張子別の動画ファイルの数
    @@ -1808,7 +2023,7 @@

    - 図21. 動画の拡張子別のファイルサイズの中央値。 + 図21. 動画の拡張子別のファイルサイズの中央値。
    図 21. 動画の拡張子別のファイルサイズの中央値。
    @@ -1818,7 +2033,7 @@

    - 図21. HTML 動画タグ属性の使用法。 + 図21. HTML 動画タグ属性の使用法。
    図 22. HTML動画タグ属性の使用法。
    @@ -1830,7 +2045,7 @@

    より高度な再生（および動画ストリームの再生）を行うには、HTML5ネイティブ動画プレイヤーは動作しません。再生に使用する一般的な動画ライブラリがいくつかあります。

    - 図23. トップの JavaScript 動画プレイヤー + 図23. トップの JavaScript 動画プレイヤー
    図 23. トップの JavaScript 動画プレイヤー
    @@ -1838,79 +2053,73 @@

    もっとも人気があるのは（圧倒的に）video.jsで、JWPLayerとHLS.jsがそれに続いています。著者は、「video.js」という名前のファイルが、同じ動画再生ライブラリではない可能性があることを認めています。

    結論

    ほぼすべてのウェブページではユーザー体験を向上させ、意味を生み出すために、画像や動画をある程度使用しています。これらのメディアファイルは大量のリソースを利用し、ウェブサイトのトン数の大部分を占めています（そして、それらがなくなることはありません！）代替フォーマット、遅延ロード、レスポンシブ画像、画像の最適化を利用することは、ウェブ上のメディアのサイズを小さくするために長い道のりを行くことができます。

    -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":5,"title":"サードパーティ","description":"2019 Web Almanacのサードパーティの章。サードパーティの使用目的、パフォーマンスへの影響、プライバシーへの影響について説明しています。","authors":["patrickhulce"],"reviewers":["zcorpan","obto","jasti"],"translators":["ksakae"],"discuss":"1760","results":"https://docs.google.com/spreadsheets/d/1iC4WkdadDdkqkrTY32g7hHKhXs9iHrr3Bva8CuPjVrQ/","queries":"05_Third_Parties","published":"2019-11-11","last_updated":"2020-05-14","chapter":"third-parties"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 5 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - サードパーティ +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":5,"title":"サードパーティ","description":"2019 Web Almanacのサードパーティの章。サードパーティの使用目的、パフォーマンスへの影響、プライバシーへの影響について説明しています。","authors":["patrickhulce"],"reviewers":["zcorpan","obto","jasti"],"translators":["ksakae"],"discuss":"1760","results":"https://docs.google.com/spreadsheets/d/1iC4WkdadDdkqkrTY32g7hHKhXs9iHrr3Bva8CuPjVrQ/","queries":"05_Third_Parties","published":"2019-11-11","last_updated":"2020-05-14","chapter":"third-parties"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -1919,13 +2128,16 @@

    - + -
    {{ self.written_by_before() }} Patrick Hulce{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Simon Pieters, David Fox, {{ self.and() }} Vamsee Jasti{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    オープンWebは広大で、リンク可能で、設計により相互運用可能です。他の誰かの複雑なライブラリを取得し、単一の<link>または<script>要素を使用してサイトで使用する機能により開発者の生産性が大幅に向上し、素晴らしく新しいWeb体験を実現しました。反対に、一部のサードパーティプロバイダーが非常に人気があるため、パフォーマンス、プライバシー、およびセキュリティに関する重要な懸念が生じています。この章では、2019年のWebに対するサードパーティコードの普及と影響、サードパーティソリューションの人気につながる使用パターンと、Web体験の将来への影響の可能性について検討します。

    定義

    @@ -1940,7 +2152,10 @@

    プロバイダーカテゴリー

    -

    この章では、サードパーティプロバイダをこれらの大まかなカテゴリのいずれかに分類しています。以下に簡単な説明を記載し、ドメインとカテゴリのマッピングについては、サードパーティ・ウェブ・リポジトリを参照してください。

    +

    + この章では、サードパーティプロバイダをこれらの大まかなカテゴリのいずれかに分類しています。以下に簡単な説明を記載し、ドメインとカテゴリのマッピングについては、サードパーティ・ウェブ・リポジトリhttps://github.com/patrickhulce/third-party-web/blob/8afa2d8cadddec8f0db39e7d715c07e85fb0f8ec/data/entities.json5を参照してください。 +

    • Ad - 広告の表示と測定
    • Analytics - トラッキングサイト訪問者の行動
      • @@ -1976,7 +2191,10 @@

      ウェブ上でのサードパーティの存在は広告が最もユーザーの目につきやすい例かもしれませんが、アナリティクスプロバイダーが最も一般的なサードパーティのカテゴリーであり、76％のサイトで少なくとも1つのアナリティクスリクエストが含まれています。CDNが63％、広告が57％、Sentry、Stripe、Google Maps SDKなどの開発者向けユーティリティが56％で、最も多くのウェブプロパティに表示されているのは僅差の2位、3位、4位と続いています。これらのカテゴリの人気は、本章で後述するウェブ利用パターンの基礎を形成しています。

      プロバイダー

      プロバイダーの比較的小さなセットがサードパーティの状況を支配しています：トップ100ドメインは、ウェブ全体のネットワーク要求の30％を占めています。Google、Facebook、YouTubeのような大企業は、それぞれのシェアの完全なパーセンテージポイントでここの見出しを作るが、WixやShopifyのような小さな事業体は同様にサードパーティの人気のかなりの部分を指揮します。

      -

      個々のプロバイダの人気とパフォーマンスへの影響については、多くのことが言えるかもしれませんが、このより意見の多い分析は読者やサードパーティ製Webのような他の目的のために構築されたツールの練習として残されています。

      +

      + 個々のプロバイダの人気とパフォーマンスへの影響については、多くのことが言えるかもしれませんが、このより意見の多い分析は読者やサードパーティ製Webhttps://thirdpartyweb.todayのような他の目的のために構築されたツールの練習として残されています。 +

      @@ -2117,7 +2335,7 @@

      - 図5. カテゴリーとコンテンツタイプ別の第三者リクエストの割合。 + 図5. カテゴリーとコンテンツタイプ別の第三者リクエストの割合。
      図 5. カテゴリーとコンテンツタイプ別の第三者リクエストの割合。
      @@ -2132,7 +2350,7 @@

      - 図7. サードパーティカテゴリ毎のリソースバイトの分布。 + 図7. サードパーティカテゴリ毎のリソースバイトの分布。
      図 7. サードパーティカテゴリ毎のリソースバイトの分布。
      @@ -2150,14 +2368,19 @@

      サードパーティウェブ のような他の目的のために構築されたツールもあります。

      +

      + 個々のプロバイダの人気とパフォーマンスの影響については、多くのことが言えるかもしれませんが、より意見の多い分析は読者のための演習として残されていますし先に述べた サードパーティウェブhttps://thirdpartyweb.today のような他の目的のために構築されたツールもあります。 +

      使用パターン

      サイトオーナーはなぜサードパーティのコードを使うのか？　サードパーティのコンテンツがネットワークリクエストの半分近くを占めるようになったのはなぜでしょうか？　これらのリクエストは何をしているのか？　これらの疑問に対する答えは、サードパーティのリソースの3つの主要な使用パターンにあります。大まかに言えば、サイト所有者はユーザーからデータを生成して消費し、サイト体験を収益化しWeb開発を簡素化するためにサードパーティを利用しています。

      データの生成と消費

      アナリティクスは、ウェブ上で最も人気のあるサードパーティのカテゴリですが、ユーザーの目に触れることはほとんどありません。ユーザーのコンテキスト、デバイス、ブラウザ、接続品質、ロケーション、ページのインタラクション、セッションの長さ、再訪問者のステータスなどが継続的に生成されています。このような大規模な時系列データをウェアハウスし、正規化し分析するツールを維持するのは困難で面倒で、コストがかかります。アナリティクスがサードパーティプロバイダーの領域に入ることを明確に必要とするものはありませんが、ユーザーを理解することの魅力、問題空間の複雑さ、データを尊重し責任を持って管理することの重要性が増していることから、アナリティクスはサードパーティの人気のある使用パターンとして自然に表面化しています。

      しかし、ユーザーデータには消費という裏返しの側面もあります。アナリティクスはサイトの訪問者からデータを生成することですが、他のサードパーティのリソースは、他の人しか知らない訪問者に関するデータを消費することに重点を置いています。ソーシャルプロバイダーは、この利用パターンにぴったりと当てはまります。サイト所有者は、訪問者のFacebookプロフィールからの情報をサイトに統合したい場合、Facebookのリソースを使用する必要があります。サイトオーナーがソーシャルネットワークのウィジェットを使って体験をパーソナライズし、訪問者のソーシャルネットワークを活用してリーチを増やすことに興味がある限り、ソーシャル統合はサードパーティの領域であり続けると思われます。

      ウェブトラフィックの収益化

      -

      ウェブのオープンモデルは、コンテンツ制作者の金銭的利益を必ずしも満足させるものではなく、多くのサイト所有者は広告でサイトを収益化することに頼っています。広告主との直接の関係を構築し、価格契約を交渉するのは比較的難しく時間のかかるプロセスであるため、この懸念はターゲット広告とリアルタイム入札を行うサードパーティのプロバイダーによって主に処理されています。否定的な世論の広がり、広告ブロッキング技術の普及、ヨーロッパなどの主要な世界市場での規制措置は、収益化のためにサードパーティのプロバイダを継続的に使用する最大の脅威となっています。サイト所有者が突然独自の広告契約を結んだり特注の広告ネットワークを構築したりすることは考えにくいですが、ペイウォールやBraveのBasic Attention Tokenのような実験のような代替的なマネタイズモデルは、将来のサードパーティの広告業界を揺るがす可能性を秘めています。

      +

      + ウェブのオープンモデルは、コンテンツ制作者の金銭的利益を必ずしも満足させるものではなく、多くのサイト所有者は広告でサイトを収益化することに頼っています。広告主との直接の関係を構築し、価格契約を交渉するのは比較的難しく時間のかかるプロセスであるため、この懸念はターゲット広告とリアルタイム入札を行うサードパーティのプロバイダーによって主に処理されています。否定的な世論の広がり、広告ブロッキング技術の普及、ヨーロッパなどの主要な世界市場での規制措置は、収益化のためにサードパーティのプロバイダを継続的に使用する最大の脅威となっています。サイト所有者が突然独自の広告契約を結んだり特注の広告ネットワークを構築したりすることは考えにくいですが、ペイウォールやBraveのBasic Attention Tokenhttps://basicattentiontoken.org/のような実験のような代替的なマネタイズモデルは、将来のサードパーティの広告業界を揺るがす可能性を秘めています。 +

      開発の簡素化

      何よりもサードパーティのリソースは、ウェブ開発の経験を単純化するために使用されます。以前の使用パターンでさえも、おそらくこのパターンに当てはまる可能性があります。ユーザーの行動分析、広告主とのコミュニケーション、ユーザー体験のパーソナライズなど、サードパーティのリソースはファーストパーティの開発を容易にするため使用されます。

      ホスティングプロバイダは、このパターンの最も極端な例です。これらのプロバイダーの中には、技術的な専門知識がなくても、地球上の誰もがサイトのオーナーになれるようしているところもあります。これらのプロバイダーは、資産のホスティング、コーディングの経験がなくてもサイトを構築できるツール、ドメイン登録サービスを提供しています。

      @@ -2172,63 +2395,94 @@

      プライバシー

      サードパーティの最大の利用例は、サイト所有者がユーザーを追跡することであり、一握りの企業がウェブトラフィックの大部分に関する情報を受け取っています。

      -

      ユーザーの行動を理解して分析することに対するサイト所有者の関心、それ自体は悪意のあるものではありませんが、ウェブ解析の普及した比較的裏方的な性質は有効な懸念を引き起こし、ヨーロッパのGDPRやカリフォルニア州のCCPAなどのプライバシー規制によりユーザー、企業、法律家は近年注目を集めています。開発者がユーザーデータを責任を持って扱い、ユーザーを尊重して扱い、収集されたデータが透明であることを保証することは、アナリティクスを最も人気のあるサードパーティのカテゴリーとして維持し、将来のユーザー価値を提供するためにユーザーの行動を分析するという共生的な性質を維持するための鍵となります。

      +

      + ユーザーの行動を理解して分析することに対するサイト所有者の関心、それ自体は悪意のあるものではありませんが、ウェブ解析の普及した比較的裏方的な性質は有効な懸念を引き起こし、ヨーロッパのGDPRhttps://ja.wikipedia.org/wiki/EU%E4%B8%80%E8%88%AC%E3%83%87%E3%83%BC%E3%82%BF%E4%BF%9D%E8%AD%B7%E8%A6%8F%E5%89%87やカリフォルニア州のCCPAhttps://en.wikipedia.org/wiki/California_Consumer_Privacy_Actなどのプライバシー規制によりユーザー、企業、法律家は近年注目を集めています。開発者がユーザーデータを責任を持って扱い、ユーザーを尊重して扱い、収集されたデータが透明であることを保証することは、アナリティクスを最も人気のあるサードパーティのカテゴリーとして維持し、将来のユーザー価値を提供するためにユーザーの行動を分析するという共生的な性質を維持するための鍵となります。 +

      スクリプトの実行が上位に集中していることは、パフォーマンス向上の潜在的な影響を考えると素晴らしいことですが、プライバシーへの影響を考えるとあまり刺激的ではありません。ウェブ上の全スクリプト実行時間の29％は、GoogleやFacebookが所有するドメイン上のスクリプトだけです。これは、たった2つの事業体によって制御されているCPU時間の非常に大きな割合です。アナリティクスプロバイダーに適用されているのと同じプライバシー保護が、他の広告、ソーシャル、開発者向けユーティリティカテゴリにも適用されるようにすることが重要です。

      セキュリティ

      -

      セキュリティのトピックについては セキュリティ の章で詳しく説明していますが、サイトに外部の依存関係を導入することによるセキュリティへの影響は、プライバシーへの懸念と密接に関連しています。第三者が任意のJavaScriptを実行できるようにすることは、あなたのページを完全に制御できます。スクリプトがDOMとwindowを制御できれば、すべてのことができるようになります。たとえコードにセキュリティ上の懸念がなくても、単一の障害点を導入できますこれは以前から潜在的な問題として認識されていました。

      -

      サードパーティのコンテンツをセルフホスティングする は、ここで述べた懸念事項のいくつかとその他の懸念事項に対応しています。さらに、ブラウザが HTTPキャッシュのパーティショニング を増やしていることから、サードパーティから直接読み込むことのメリットはますます疑問視されています。おそらく多くのユースケースでサードパーティのコンテンツを利用するには、その影響を測定することが難しくなってもこの方法の方が良いでしょう。

      +

      + セキュリティのトピックについては セキュリティ の章で詳しく説明していますが、サイトに外部の依存関係を導入することによるセキュリティへの影響は、プライバシーへの懸念と密接に関連しています。第三者が任意のJavaScriptを実行できるようにすることは、あなたのページを完全に制御できます。スクリプトがDOMとwindowを制御できれば、すべてのことができるようになります。たとえコードにセキュリティ上の懸念がなくても、単一の障害点を導入できますこれは以前から潜在的な問題として認識されていましたhttps://www.stevesouders.com/blog/2010/06/01/frontend-spof/。 +

      +

      + サードパーティのコンテンツをセルフホスティングするhttps://csswizardry.com/2019/05/self-host-your-static-assets/ は、ここで述べた懸念事項のいくつかとその他の懸念事項に対応しています。さらに、ブラウザが HTTPキャッシュのパーティショニングhttps://chromestatus.com/feature/5730772021411840 を増やしていることから、サードパーティから直接読み込むことのメリットはますます疑問視されています。おそらく多くのユースケースでサードパーティのコンテンツを利用するには、その影響を測定することが難しくなってもこの方法の方が良いでしょう。 +

      結論

      サードパーティのコンテンツはどこにでもあります。これは驚くべきことでありません。ウェブの基本は、相互接続とリンクを可能にすることです。この章では、メインドメインから離れてホストされている資産という観点から、サードパーティコンテンツを調べてみました。もし、自己ホスト型のサードパーティ・コンテンツ（例えば、メイン・ドメインにホストされている一般的なオープンソース・ライブラリなど）を含めるとサードパーティの利用率はさらに高まっていたでしょう。

      -

      コンピュータ技術での再利用は一般的にベストプラクティスですが、ウェブ上のサードパーティは、ページのパフォーマンス、プライバシー、セキュリティにかなりの影響を与える依存関係を導入します。セルフホスティングと慎重なプロバイダの選択は、これらの影響を軽減するために長い道のりを歩むことができます。

      +

      + コンピュータ技術での再利用https://en.wikipedia.org/wiki/Code_reuseは一般的にベストプラクティスですが、ウェブ上のサードパーティは、ページのパフォーマンス、プライバシー、セキュリティにかなりの影響を与える依存関係を導入します。セルフホスティングと慎重なプロバイダの選択は、これらの影響を軽減するために長い道のりを歩むことができます。 +

      第三者のコンテンツがどのようにページに追加されるかという重要な問題に関わらず、結論は同じです。サードパーティはWebの不可欠な部分です！

      -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":6,"title":"フォント","description":"フォントがどこから読み込まれるか、フォントのフォーマット、フォントの読み込み性能、可変フォント、カラーフォントを網羅した2019年Web AlmanacのFontsの章。","authors":["zachleat"],"reviewers":["hyperpress","AymenLoukil"],"translators":["ksakae"],"discuss":"1761","results":"https://docs.google.com/spreadsheets/d/108g6LXdC3YVsxmX1CCwrmpZ3-DmbB8G_wwgQHX5pn6Q/","queries":"06_Fonts","published":"2019-11-11","last_updated":"2020-05-16","chapter":"fonts"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 6 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - フォント +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":6,"title":"フォント","description":"フォントがどこから読み込まれるか、フォントのフォーマット、フォントの読み込み性能、可変フォント、カラーフォントを網羅した2019年Web AlmanacのFontsの章。","authors":["zachleat"],"reviewers":["hyperpress","AymenLoukil"],"translators":["ksakae"],"discuss":"1761","results":"https://docs.google.com/spreadsheets/d/108g6LXdC3YVsxmX1CCwrmpZ3-DmbB8G_wwgQHX5pn6Q/","queries":"06_Fonts","published":"2019-11-11","last_updated":"2020-05-16","chapter":"fonts"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -2237,32 +2491,41 @@

    - + -
    {{ self.written_by_before() }} Zach Leatherman{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} John Teague, {{ self.and() }} Aymen Loukil{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    ウェブフォントは、ウェブ上で美しく機能的なタイポグラフィを可能にします。ウェブフォントを使用することは、デザインに力を与えるだけでなく、デザインのサブセットを民主化します。しかし、どんなに良いことがあってもウェブフォントが適切に読み込まれていないと、サイトのパフォーマンスに大きな悪影響を及ぼすこともあります。

    それらはウェブにとってプラスになるのか？　それらは害よりも多くの利益を提供しているか?　Web標準の牛道は、デフォルトでWebフォントの読み込みのベストプラクティスを奨励するために十分に舗装されているだろうか？　そうでない場合、何を変える必要があるのでしょうか？　今日のウェブ上でウェブフォントがどのように使用されているかを調べることで、これらの疑問に答えられるかどうかをデータ駆動型で覗いてみましょう。

    そのウェブフォントはどこで手に入れたの？

    最初の、そして最も顕著な問題は、パフォーマンスです。パフォーマンスに特化した章がありますが、ここではフォント固有のパフォーマンスの問題について少し掘り下げてみましょう。

    -

    ホストされたWebフォントを使用すると、実装やメンテナンスが容易になりますが、セルフホスティングは最高のパフォーマンスを提供します。Webフォントはデフォルトで、Webフォントの読み込み中にテキストを非表示にする（Flash of Invisible Text、またはFOITとしても知られています）ことを考えると、Webフォントのパフォーマンスは画像のような非ブロッキング資産よりも重要になる可能性があります。

    +

    + ホストされたWebフォントを使用すると、実装やメンテナンスが容易になりますが、セルフホスティングは最高のパフォーマンスを提供します。Webフォントはデフォルトで、Webフォントの読み込み中にテキストを非表示にする（Flash of Invisible Texthttps://css-tricks.com/fout-foit-foft/、またはFOITとしても知られています）ことを考えると、Webフォントのパフォーマンスは画像のような非ブロッキング資産よりも重要になる可能性があります。 +

    フォントは同じホストでホストされているのか、それとも別のホストでホストされているのか？

    サードパーティのホスティングに対するセルフホスティングの差別化は、HTTP/2の世界ではますます重要になってきています。同一ホストのリクエストには、ウォーターフォール内の他の同一ホストのリクエストに対して優先順位をつける可能性が高いという大きな利点があります。

    別のホストからウェブフォントを読み込む際のパフォーマンスコストを軽減するための推奨事項としては、preconnect、dns-prefetch、preload リソースのヒントの使用がありますが、優先度の高いウェブフォントは、ウェブフォントのパフォーマンスへの影響を最小限に抑えるため、同一ホストからのリクエストにすべきです。これは視覚的に、非常に目立つコンテンツやページの大部分を占める本文コピーで使用されるフォントへ対して特に重要です。

    - 図1. 人気のあるウェブフォントのホスティング戦略。 + 図1. 人気のあるウェブフォントのホスティング戦略。
    図 1. 人気のあるウェブフォントのホスティング戦略。font hosting strategies.

    4分の3がホストされているという事実は、おそらく我々が議論するGoogle Fontsの優位性を考えると意外と知られていません以下。

    Googleはhttps://fonts.googleapis.comでホストされているサードパーティのCSSファイルを使ってフォントを提供しています。開発者は、マークアップの<link>タグを使ってこれらのスタイルシートにリクエストを追加します。これらのスタイルシートはレンダーブロッキングされていますが、そのサイズは非常に小さいです。しかし、フォントファイルはhttps://fonts.gstatic.comという別のドメインでホストされています。2つの異なるドメインへの2つの別々のホップを必要とするモデルでは、CSSがダウンロードされるまで発見されない2つ目のリクエストにはpreconnectが最適な選択肢となります。

    -

    preloadはリクエストのウォーターフォールの上位にフォントファイルをロードするための素晴らしい追加機能ですが（preconnectは接続を設定するもので、ファイルの内容をリクエストするものではないことを覚えておいてください）、preloadはGoogle Fontsではまだ利用できません。Google Fontsはフォントファイル用のユニークなURLを生成しますこれは変更される可能性があります。

    +

    + preloadはリクエストのウォーターフォールの上位にフォントファイルをロードするための素晴らしい追加機能ですが（preconnectは接続を設定するもので、ファイルの内容をリクエストするものではないことを覚えておいてください）、preloadはGoogle Fontsではまだ利用できません。Google Fontsはフォントファイル用のユニークなURLを生成しますこれは変更される可能性がありますhttps://github.com/google/fonts/issues/1067。 +

    最も人気のあるサードパーティ製のホストは何ですか？

    @@ -2392,7 +2655,8 @@

    HTTP Link:ヘッダーを使ってGoogle Fontsを使っているということになるかもしれません。 + あるいは、超ありえないシナリオにまで踏み込んでみたいのであれば、多くの人が代わりにHTTP Link:ヘッダーhttps://developer.mozilla.org/ja/docs/Web/HTTPを使ってGoogle Fontsを使っているということになるかもしれません。
    @@ -2408,7 +2672,7 @@

    図 5. モバイルページがウェブフォントホストにプリコネクティングしている割合。

    - うわー！　2％未満のページがpreconnectpreconnecthttps://web.dev/uses-rel-preconnectを使用している！　Google Fontsが75％であることを考えると、これはもっと高いはずです！　開発者の皆さん: Google Fontsを使うなら、preconnectを使いましょう！　Google Fonts:preconnectをもっと宣伝しよう！

    実際、もしあなたがGoogle Fontsを使っているのであれば、<head>にこれを追加してください。

    @@ -2553,12 +2817,18 @@

    図 6. 全フォント宣言に占める上位20のフォントファミリーの割合。

    -

    ここでの上位のエントリがGoogle Fontsの人気順フォント一覧と非常によく似ていることは驚くに値しません。

    +

    + ここでの上位のエントリがGoogle Fontsの人気順フォント一覧https://fonts.google.com/?sort=popularityと非常によく似ていることは驚くに値しません。 +

    どのようなフォント形式を使用していますか？

    -

    今日のブラウザではWOFF2はかなりサポートされています。Google FontsはWOFF2というフォーマットを提供していますが、これは前身のWOFFよりも圧縮率が向上したフォーマットで、それ自体はすでに他の既存のフォントフォーマットよりも改善されていました。

    +

    + 今日のブラウザではWOFF2はかなりサポートされていますhttps://caniuse.com/#feat=woff2。Google FontsはWOFF2というフォーマットを提供していますが、これは前身のWOFFよりも圧縮率が向上したフォーマットで、それ自体はすでに他の既存のフォントフォーマットよりも改善されていました。 +

    - 図7. ウェブフォントのMIMEタイプの普及率 + 図7. ウェブフォントのMIMEタイプの普及率
    図 7. ウェブフォントのMIMEタイプの普及率
    @@ -2568,12 +2838,15 @@

    <

    もう少し深く掘り下げて、@font-face宣言のsrc:プロパティで使われているformat()の値を見てみましょう。

    - 図8. <code>@font-face</code>宣言におけるフォントフォーマットの人気度。 + 図8. <code>@font-face</code>宣言におけるフォントフォーマットの人気度。
    図 8. @font-face宣言におけるフォントフォーマットの人気度。
    -

    SVGフォントが衰退しているのを見て期待していたのですが。バグだらけだし、Safari以外のブラウザでは実装が削除されている。そろそろ捨ててしまおうか。

    +

    + SVGフォントhttps://caniuse.com/#feat=svg-fontsが衰退しているのを見て期待していたのですが。バグだらけだし、Safari以外のブラウザでは実装が削除されている。そろそろ捨ててしまおうか。 +

    ここのSVGデータポイントを見ると、どのMIMEタイプでSVGフォントを提供しているのか気になります。図7のどこにもimage/svg+xmlは見当たりません。とにかく、それを修正することは気にしないで、ただそれらを取り除くだけです！

    WOFF2専用

    @@ -2719,19 +2992,25 @@

    WOFF

    重要なのは、この特定のデータはまだWOFF2オンリーのケースを支持しているわけではないということですが、魅力的なアイデアであることに変わりはありません。

    見えない文字との戦い

    デフォルトのWebフォントの読み込み動作である「読み込み中は見えない」(FOITとしても知られています)に対抗するため持っている第一のツールはfont-displayです。font-display: swapを@font-faceブロックに追加すると、ウェブフォントが読み込まれている間にフォールバックテキストを表示するようにブラウザに指示する簡単な方法です。

    -

    ブラウザ対応もいいですね。Internet ExplorerやChromium以前のEdgeではサポートされていませんが、Webフォントが読み込まれたときにデフォルトでフォールバックテキストをレンダリングしてくれます（ここではFOITは使えません）。Chromeのテストでは、font-displayはどのくらいの頻度で使われているのでしょうか？

    +

    + ブラウザ対応https://caniuse.com/#feat=mdn-css_at-rules_font-face_font-displayもいいですね。Internet ExplorerやChromium以前のEdgeではサポートされていませんが、Webフォントが読み込まれたときにデフォルトでフォールバックテキストをレンダリングしてくれます（ここではFOITは使えません）。Chromeのテストでは、font-displayはどのくらいの頻度で使われているのでしょうか？ +

    26%
    図 10. font-displayスタイルを利用しているモバイルページの割合。

    - 私はこれが時間の経過とともに忍び寄ってくることを想定しています、特に今はGoogle Fontsがすべての新しいコードスニペットに font-display を追加していますが彼らのサイトからコピーされています。 + 私はこれが時間の経過とともに忍び寄ってくることを想定しています、特に今はGoogle Fontsがすべての新しいコードスニペットに font-display を追加していますhttps://www.zachleat.com/web/google-fonts-display/が彼らのサイトからコピーされています。 +

    +

    + Google Fontsを使っているなら、スニペットを更新しよう！　Google Fontsを使っていない場合は、font-displayを使いましょう！ font-displayについての詳細は MDNhttps://developer.mozilla.org/ja/docs/Web/CSS/@font-face/font-display を参照してください。

    -

    Google Fontsを使っているなら、スニペットを更新しよう！　Google Fontsを使っていない場合は、font-displayを使いましょう！ font-displayについての詳細は MDN を参照してください。

    どのようなfont-display値が人気あるのか見てみましょう。

    - 図11. `font-display'の値の使用法。 + 図11. `font-display'の値の使用法。
    図 11. font-displayの値の使用法。
    @@ -2741,7 +3020,7 @@

    - 図12. ページあたりのフォント要求の分布。 + 図12. ページあたりのフォント要求の分布。
    図 12. ページあたりのフォント要求の分布。
    @@ -2749,13 +3028,14 @@

    - 図13. ページあたりに要求されたウェブフォントのヒストグラム。 + 図13. ページあたりに要求されたウェブフォントのヒストグラム。
    図 13. ページあたりに要求されたウェブフォントのヒストグラム。

    - Webフォントのリクエストがデスクトップとモバイルの間でかなり安定しているように見えるというのは非常に興味深いことです。私は、@mediaクエリの中の@font-faceブロックを隠すことを推奨することが流行らなかったのを見てうれしく思います (何も考えないでください)。 + Webフォントのリクエストがデスクトップとモバイルの間でかなり安定しているように見えるというのは非常に興味深いことです。私は、@mediaクエリの中の@font-faceブロックを隠すことを推奨することhttps://css-tricks.com/snippets/css/using-font-face/#article-header-id-6が流行らなかったのを見てうれしく思います (何も考えないでください)。

    しかし、モバイルデバイスでのフォントのリクエストはわずかに多い。ここでの私の勘は、モバイルデバイスで利用できる書体が少ないということはGoogle Fonts CSSでのlocal()のヒット数が少ないということであり、ネットワークからのフォントリクエストに戻ってしまうのではないかと考えています。

    この賞を受賞したくない

    @@ -2774,7 +3054,7 @@

    図 15. unicode-rangeプロパティでWebフォントを宣言しているモバイルページの割合。

    - unicode-rangeunicode-rangehttps://developer.mozilla.org/ja/docs/Web/CSS/@font-face/unicode-rangeは、ブラウザに、ページがフォントファイルで使用したいコードポイントを具体的に知らせるための優れたCSSプロパティです。@font-face宣言にunicode-rangeがある場合、ページ上のコンテンツは、フォントが要求される前に、その範囲内のコードポイントのいずれかにマッチしなければなりません。これは非常に良いことです。

    Google FontsはそのCSSのほとんど（すべてではないにしても）でunicode-rangeを使用しているので、これもGoogle Fontsの使用状況によって偏っていると予想される指標です。ユーザーの世界でこれはあまり一般的でないと思いますが、Web Almanacの次の版ではGoogle Fontsのリクエストをフィルタリングして除外することが可能かもしれません。

    @@ -2784,7 +3064,10 @@

    図 16. local()プロパティでWebフォントを宣言しているモバイルページの割合。

    local()は@font-face、srcのシステムフォントを参照するための良い方法です。もし local()フォントが存在するならば、ウェブフォントを要求する必要は全くありません。これはGoogle Fontsによって広く使われており、論争の的にもなっているのでユーザの土地からパターンを得ようとしているのであれば、これも歪んだデータの一例になるでしょう。

    -

    ここでは、私よりも賢い人々(TypeKitのBram Stein氏) が、インストールされているフォントのバージョンが古くて信頼性は低い場合があるため、local()を使うことは予測不可能である可能性があると述べていることにも注目しておきましょう。

    +

    + ここでは、私よりも賢い人々(TypeKitのBram Stein氏) が、インストールされているフォントのバージョンが古くて信頼性は低い場合があるため、local()を使うことは予測不可能である可能性があるhttps://bramstein.com/writing/web-font-anti-patterns-local-fonts.htmlと述べていることにも注目しておきましょう。 +

    縮約されたフォントとfont-stretch

    @@ -2792,18 +3075,27 @@

    7%
    図 17. font-stretch プロパティを持つスタイルを含むデスクトップページとモバイルページの割合。
    -

    歴史的に、font-stretchはブラウザのサポートが悪く、よく知られた@font-faceプロパティではありませんでした。詳しくはMDNのfont-stretchについて を参照してください。しかし、ブラウザのサポートは広がっています。

    +

    + 歴史的に、font-stretchはブラウザのサポートが悪く、よく知られた@font-faceプロパティではありませんでした。詳しくはMDNのfont-stretchについてhttps://developer.mozilla.org/ja/docs/Web/CSS/font-stretch を参照してください。しかし、ブラウザのサポートhttps://caniuse.com/#feat=css-font-stretchは広がっています。 +

    小さいビューポートで凝縮されたフォントを使用することで、より多くのテキストを表示できるようになることが示唆されていますが、このアプローチは一般的には使用されていません。とはいえ、このプロパティがモバイルよりもデスクトップで半パーセントポイント多く使われているというのは予想外で、7％というのは私が予想していたよりもはるかに高いと思えます。

    可変フォントは未来のもの

    -

    可変フォントでは、1つのフォントファイルに複数のフォントの太さやスタイルを含めることができます。

    +

    + 可変フォントhttps://developer.mozilla.org/ja/docs/Web/CSS/CSS_Fonts/Variable_Fonts_Guideでは、1つのフォントファイルに複数のフォントの太さやスタイルを含めることができます。 +

    1.8%
    図 18. 可変フォントを含むページの割合
    -

    1.8％でさえ、これは予想よりも高かったが、これがうまくいくのを見て興奮している。Google Fonts v2には可変フォントのサポートがいくつか含まれています。

    +

    + 1.8％でさえ、これは予想よりも高かったが、これがうまくいくのを見て興奮している。Google Fonts v2https://developers.google.com/fonts/docs/css2には可変フォントのサポートがいくつか含まれています。 +

    - 図19. 'font-variation-settings'軸の使用法。 + 図19. 'font-variation-settings'軸の使用法。
    図 19. font-variation-settings軸の使用法。
    @@ -2814,60 +3106,82 @@

    117

    図 20. カラーフォントを含むデスクトップウェブページの数。
    -

    これらのここでの使用法は基本的に存在しませんが、詳細についてはカラーフォント！　WTF?という優れたリソースをチェックできます。フォント用のSVGフォーマット(これは良くないし消えていく)に似ていますが(全くそうではありません)、これを使うとOpenTypeファイルの中にSVGを埋め込むことができ、これは素晴らしくクールです。

    +

    + これらのここでの使用法は基本的に存在しませんが、詳細についてはカラーフォント！　WTF?https://www.colorfonts.wtf/という優れたリソースをチェックできます。フォント用のSVGフォーマット(これは良くないし消えていく)に似ていますが(全くそうではありません)、これを使うとOpenTypeファイルの中にSVGを埋め込むことができ、これは素晴らしくクールです。 +

    結論

    ここでの最大の収穫は、Google Fontsがウェブフォントの議論を支配しているということだ。彼らが取ったアプローチは、ここで記録したデータに大きく影響している。ここでのポジティブな点はウェブフォントへのアクセスが容易であること、優れたフォントフォーマット（WOFF2）であること、そして自由なunicode範囲の設定が可能であることだ。ここでの欠点はサードパーティのホスティング、異なるホストからのリクエスト、およびpreloadにアクセスできないことでパフォーマンスが低下することです。

    私は、将来的には「バリアブルフォントの台頭」を見ることになるだろうと完全に予想しています。バリアブルフォントは複数の個々のフォントファイルを1つの合成フォントファイルに結合するので、これはウェブフォントのリクエストの減少と対になっているはずです。しかし歴史が示しているように、ここで通常起こることは、あるものを最適化してその空所を埋めるためにさらに多くのものを追加してしまうことです。

    カラーフォントの人気が高まるかどうかは非常に興味深いところです。私は、これらは可変フォントよりもはるかにニッチなものになると予想していますが、アイコンフォントのスペースに生命線を見ることができるかもしれません。

    フォントを凍らせるなよ。

    -
    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":7,"title":"パフォーマンス","description":"コンテンツの初回ペイント（FCP）、最初のバイトまでの時間（TTFB）、初回入力遅延（FID）を取り扱う2019 Web Almanac パフォーマンスの章。","authors":["rviscomi"],"reviewers":["JMPerez","obto","sergeychernyshev","zeman"],"translators":["MSakamaki"],"discuss":"1762","results":"https://docs.google.com/spreadsheets/d/1zWzFSQ_ygb-gGr1H1BsJCfB7Z89zSIf7GX0UayVEte4/","queries":"07_Performance","published":"2019-11-11","last_updated":"2020-03-02","chapter":"performance"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 7 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - パフォーマンス +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":7,"title":"パフォーマンス","description":"コンテンツの初回ペイント（FCP）、最初のバイトまでの時間（TTFB）、初回入力遅延（FID）を取り扱う2019 Web Almanac パフォーマンスの章。","authors":["rviscomi"],"reviewers":["JMPerez","obto","sergeychernyshev","zeman"],"translators":["MSakamaki"],"discuss":"1762","results":"https://docs.google.com/spreadsheets/d/1zWzFSQ_ygb-gGr1H1BsJCfB7Z89zSIf7GX0UayVEte4/","queries":"07_Performance","published":"2019-11-11","last_updated":"2020-03-02","chapter":"performance"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -2876,19 +3190,26 @@

    - + -
    {{ self.written_by_before() }} Rick Viscomi{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} José M. Pérez, David Fox, Sergey Chernyshev, {{ self.and() }} Mark Zeman{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} M.Sakamaki{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    パフォーマンスはユーザー体験で大切なものの一つです。 多くのWebサイトでは、ページの読み込み時間を早くする事によるユーザー体験の向上と、コンバージョン率の上昇は一致しています。 逆に、パフォーマンスが低い場合、ユーザーはコンバージョンを達成せず、不満を持ち、ページをクリックすると怒りを覚えることさえあります。

    Webのパフォーマンスを定量化する方法は色々とあります。 ここで一番大切なのは、ユーザーにとって特に重要な点を計測することです。 ただ、onloadやDOMContentLoadedなどのイベントはユーザーが実際に目で見て体験できているものとは限りません。 例えば、電子メールクライアントを読み込んだ時、受信トレイの内容が非同期に読み込まれる間、画面全体を覆うようなプログレスバーが表示される事があります。 ここでの問題はonloadイベントが受信ボックスの非同期読み込みの完了まで待機しないことです。 この例において、ユーザーの一番大切にするべき計測値とは「受信トレイが使えるようになるまでの時間」であり、onloadイベントに着目するのは誤解を招く可能性があります。 そのために、この章ではユーザーが実際にページをどのように体験しているかを把握し、よりモダンで広く使える描画、読み込み、および対話性の計測を検討します。

    パフォーマンスデータにはラボとフィールドの２種類があります。 合成テストや実ユーザー測定（またはRUM）でそれらを聞いたことがあるかもしれません。 ラボでパフォーマンスを測定すると、各Webサイトが共通の条件でテストされ、ブラウザー、接続速度、物理的な場所、キャッシュ状態などの状態は常に同じになります。 この一貫性が保証されることで、それぞれのWebサイトを比較することができます。 その反面、フィールドのパフォーマンス測定は、ラボでは決して行うことのできない無限に近い条件の組み合わせで、現実に近いユーザーのWeb体験を計測することを可能にします。 この章の目的と実際のユーザー体験を理解するために、今回はフィールドデータを見ていきます。

    パフォーマンスの状態

    -

    Web Almanacにある他のほとんどの章は、HTTP Archiveのデータに基づいています。 ただ、実際のユーザーがWebをどのように体験するかを取得するには、違うデータセットが必要になります。 このセクションでは、Chrome UXレポート（CrUX）を使用しています。この情報はHTTP Archiveとすべて同じウェブサイトで構成されるGoogleの公開データセットとなっており、Chromeを使うユーザーの実際の体験を集約しています。そして体験は次のように分類されます。

    +

    + Web Almanacにある他のほとんどの章は、HTTP Archivehttps://httparchive.org/のデータに基づいています。 ただ、実際のユーザーがWebをどのように体験するかを取得するには、違うデータセットが必要になります。 このセクションでは、Chrome UXレポートhttp://bit.ly/chrome-ux-report（CrUX）を使用しています。この情報はHTTP Archiveとすべて同じウェブサイトで構成されるGoogleの公開データセットとなっており、Chromeを使うユーザーの実際の体験を集約しています。そして体験は次のように分類されます。 +

    • ユーザーデバイスのフォームファクタ @@ -2910,12 +3231,15 @@

      コンテンツの初回ペイント(First Contentful Paint)(FCP)です。 これはページや画像やテキストなど、ユーザーが画面として見るために必要なものが表示されるのを待つ時間です。 次は、読み込み時間の指標である最初のバイトまでの時間(Time to First Byte) (TTFB)です。 これはユーザーがナビゲーションを行ってから、Webページのレスポンスの最初のバイトを受信するまでにかかった時間を計測したものです。 そして最後に確認するフィールドの指標は初回入力遅延(First Input Delay) (FID)です。 これは比較的新しい指標で、読み込み以外のパフォーマンスUXの一部を表すものです。 ユーザーがページのUIを操作できるようになるまでの時間、つまり、ブラウザのメインスレッドがイベント処理の準備が整うまでの時間を測定したものです。

      +

      + 体験は描画、読み込み、そして対話性の定量化を含めて毎月測定されます。 最初に私達が見るべき指標はコンテンツの初回ペイント(First Contentful Paint)https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#first_paint_and_first_contentful_paint(FCP)です。 これはページや画像やテキストなど、ユーザーが画面として見るために必要なものが表示されるのを待つ時間です。 次は、読み込み時間の指標である最初のバイトまでの時間(Time to First Byte)https://developer.mozilla.org/en-US/docs/Glossary/time_to_first_byte (TTFB)です。 これはユーザーがナビゲーションを行ってから、Webページのレスポンスの最初のバイトを受信するまでにかかった時間を計測したものです。 そして最後に確認するフィールドの指標は初回入力遅延(First Input Delay)https://developers.google.com/web/updates/2018/05/first-input-delay (FID)です。 これは比較的新しい指標で、読み込み以外のパフォーマンスUXの一部を表すものです。 ユーザーがページのUIを操作できるようになるまでの時間、つまり、ブラウザのメインスレッドがイベント処理の準備が整うまでの時間を測定したものです。 +

      では、それによってどのような洞察ができるのかを見てきましょう。

      コンテンツの初回ペイント(First Contentful Paint)

      - 図1. Webサイトの高速、適度、および低速のFCPパフォーマンスの分布。 + 図1. Webサイトの高速、適度、および低速のFCPパフォーマンスの分布。
      図 1. Webサイトの高速、適度、および低速のFCPパフォーマンスの分布。
      @@ -2925,7 +3249,7 @@

      Webサイトが十分に高速かどうかを分類するために、新しい方法論である PageSpeed Insights (PSI)を使います。 この方法はWebサイトのFCP体験の少なくとも75%が１秒未満でなければなりません。 同様に、FCP体験がとても低速となる25%のWebサイトでは３秒以上かかっています。 どちらの条件も満たさない場合、Webサイトのパフォーマンスは適度です。

      - 図2. 高速、適度、低速のFCPラベルが貼られたWebサイトの分布。 + 図2. 高速、適度、低速のFCPラベルが貼られたWebサイトの分布。
      図 2. 高速、適度、低速のFCPラベルが貼られたWebサイトの分布。
      @@ -2935,14 +3259,14 @@

      デバイス毎のFCP

      - 図3. 「デスクトップ向け」Webサイトの高速、適度、低速のFCPパフォーマンスの分布。 + 図3. 「デスクトップ向け」Webサイトの高速、適度、低速のFCPパフォーマンスの分布。
      図 3. デスクトップWebサイトの高速、適度、低速のFCPパフォーマンスの分布。
      - 図4. 「携帯電話向け」Webサイトの高速、適度、低速のFCPパフォーマンスの分布。 + 図4. 「携帯電話向け」Webサイトの高速、適度、低速のFCPパフォーマンスの分布。
      図 4. 携帯電話向けWebサイトの高速、適度、低速のFCPパフォーマンスの分布。
      @@ -2950,7 +3274,7 @@

      - 図5.高速、適度、低速FCPのラベルが付けられたWebサイトの分布。デバイスの種類で分類されています。 + 図5.高速、適度、低速FCPのラベルが付けられたWebサイトの分布。デバイスの種類で分類されています。
      図 5.高速、適度、低速FCPのラベルが付けられたWebサイトの分布。デバイスの種類で分類されています。
      @@ -2960,7 +3284,7 @@

      有効な接続タイプ毎のFCP

      - 図6. 高速、適度、低速のFCPでラベル付けされたWebサイトの分布。ECTで分類されています。 + 図6. 高速、適度、低速のFCPでラベル付けされたWebサイトの分布。ECTで分類されています。
      図 6. 高速、適度、低速のFCPでラベル付けされたWebサイトの分布。ECTで分類されています。
      @@ -2969,36 +3293,49 @@

      地理によるFCP

      - 図7. 高速、適度、低速FCPでラベル付を行ったWebサイトの分布を地域別に分類したもの。 + 図7. 高速、適度、低速FCPでラベル付を行ったWebサイトの分布を地域別に分類したもの。
      図 7. 高速、適度、低速FCPでラベル付を行ったWebサイトの分布を地域別に分類したもの。
      -

      最後にユーザーの地理（geo）でFCPを切り分けてみましょう。 上記のグラフは、個別に多くのWebサイトを持っているトップ23の地域を表しています。これはオープンWeb全体での人気の計測です。 アメリカのWebユーザーは、1,211,002の最も際立ったWebサイトにアクセスします。 十分に高速なFCP体験のWebサイトの割合で地理をソートしましょう。リストのトップ3にはアジアパシフィック(APAC)が入っています。それは韓国、台湾、日本です。 この結果から、これらの地域では非常に高速なネットワーク接続が使われていることが説明できます。 韓国では高速のFCP基準を満たすウェブサイトが36％あり、低速と評価されているのはわずか7%です。 高速/適度/低速のウェブサイトの世界的な分布はおおよそ13/66/20であり、韓国がかなり良い意味で外れ値となっています。

      +

      + 最後にユーザーの地理（geo）でFCPを切り分けてみましょう。 上記のグラフは、個別に多くのWebサイトを持っているトップ23の地域を表しています。これはオープンWeb全体での人気の計測です。 アメリカのWebユーザーは、1,211,002の最も際立ったWebサイトにアクセスします。 十分に高速なFCP体験のWebサイトの割合で地理をソートしましょう。リストのトップ3にはアジアパシフィックhttps://en.wikipedia.org/wiki/Asia-Pacific(APAC)が入っています。それは韓国、台湾、日本です。 この結果から、これらの地域では非常に高速なネットワーク接続https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speedsが使われていることが説明できます。 韓国では高速のFCP基準を満たすウェブサイトが36％あり、低速と評価されているのはわずか7%です。 高速/適度/低速のウェブサイトの世界的な分布はおおよそ13/66/20であり、韓国がかなり良い意味で外れ値となっています。 +

      他のAPAC地域の話をしましょう。タイ、ベトナム、インドネシア、インドの高速Webサイトは、ほぼ10％未満です。 そして、これらの地域は韓国の3倍以上低速なWebサイトと言う割合になっています。

      最初のバイトまでの時間(Time to First Byte) (TTFB)

      -

      最初のバイトまでの時間は、ユーザーがWebページにナビゲーションしてからレスポンスの最初のバイトを受信するまでにかかった時間の測定値です。

      -
      +

      + 最初のバイトまでの時間https://web.dev/time-to-first-byteは、ユーザーがWebページにナビゲーションしてからレスポンスの最初のバイトを受信するまでにかかった時間の測定値です。 +

      +
      - 図8.ページナビゲーションのイベントとNavigation Timing API の図表。 + 図8.ページナビゲーションのイベントとNavigation Timing API の図表。
      図 8.ページナビゲーションのイベントとNavigation Timing API の図表。
      -

      TTFBとそれに影響する多くの要因を説明するために、Navigation Timing APIの仕様から図を借りました。 上の図8はstartTimeからresponseStartまでの間を表しており、unload、redirects、AppCache、DNS、SSL、TCPなどのサーバー側のリクエスト処理に費やす全てを含んでいます。 このようなコンテキストを考慮して、ユーザーがこの数値をどのように体験しているかを見てみましょう。

      +

      + TTFBとそれに影響する多くの要因を説明するために、Navigation Timing APIの仕様https://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_APIから図を借りました。 上の図8はstartTimeからresponseStartまでの間を表しており、unload、redirects、AppCache、DNS、SSL、TCPなどのサーバー側のリクエスト処理に費やす全てを含んでいます。 このようなコンテキストを考慮して、ユーザーがこの数値をどのように体験しているかを見てみましょう。 +

      - 図9. WebサイトのTTFBパフォーマンス、高速、適度、低速の分布。 + 図9. WebサイトのTTFBパフォーマンス、高速、適度、低速の分布。
      図 9. WebサイトのTTFBパフォーマンス、高速、適度、低速の分布。
      -

      図1のFCPチャートと同様に、これは高速TTFB毎に並べられた代表的な1,000個の値のサンプルのビューです。 高速TTFBは0.2秒（200ミリ秒）未満、低速TTFBは1秒以上、その間はすべて適度です。

      +

      + 図1のFCPチャートと同様に、これは高速TTFB毎に並べられた代表的な1,000個の値のサンプルのビューです。 高速TTFBhttps://developers.google.com/speed/docs/insights/Server#recommendationsは0.2秒（200ミリ秒）未満、低速TTFBは1秒以上、その間はすべて適度です。 +

      高速の割合の曲がり方を見ると、形はFCPとかなり異なります。 75％を超える高速なTTFBを持つWebサイトは非常に少なく、25％を下回るWebサイトが半分以上となっています。

      以前にFCPで使用したPSI方法論からインスピレーションを貰って、TTFB速度のラベルを各Webサイトに適用しましょう。 ウェブサイトが75％以上のユーザー体験に対して高速なTTFBを提供する場合、高速とラベル付けされます。 それ以外に、25％以上のユーザー体験に対して低速 なTTFBを提供するものを、低速とします。 この条件のどちらでもないものを適度とします

      - 図10. TTFBが高速、適度、低速としてラベル付けされたWebサイトの分布。 + 図10. TTFBが高速、適度、低速としてラベル付けされたWebサイトの分布。
      図 10. TTFBが高速、適度、低速としてラベル付けされたWebサイトの分布。
      @@ -3007,18 +3344,21 @@

      TTFB by geo

      - 図11. 高速、適度、低速のTTFBそれぞれでラベル付けされたWebサイトの分布。地域別に分類されています。 + 図11. 高速、適度、低速のTTFBそれぞれでラベル付けされたWebサイトの分布。地域別に分類されています。
      図 11. 高速、適度、低速のTTFBそれぞれでラベル付けされたWebサイトの分布。地域別に分類されています。

      次に、さまざまな地域で、高速なTTFBをユーザーに提供しているWebサイトの割合を見てみましょう。 韓国、台湾、日本のようなAPAC地域は依然として世界のユーザーを上回っています。 しかし、どの地域も15%を超えてた高速なTTFBとなっているWebサイトはありません。 インドでは、高速TTFBとなっているWebサイトは1%未満で、低速なTTFBとなっているWebサイトは79%となっています。

      初回入力遅延（First Input Delay）

      -

      最後に確認するフィールド値は初回入力遅延(First Input Delay)(FID)です。 この値は、ユーザーがページのUIを最初に操作してから、ブラウザのメインスレッドでイベントの処理が可能になるまでの時間です。 この時間には、アプリケーションへの実際の入力処理の時間は含まれないことに注意してください。 最悪の場合は、FIDが遅いとページが応答しなくなり、ユーザー体験は苛立たしいものとなってしまいます。

      +

      + 最後に確認するフィールド値は初回入力遅延(First Input Delay)https://developers.google.com/web/updates/2018/05/first-input-delay(FID)です。 この値は、ユーザーがページのUIを最初に操作してから、ブラウザのメインスレッドでイベントの処理が可能になるまでの時間です。 この時間には、アプリケーションへの実際の入力処理の時間は含まれないことに注意してください。 最悪の場合は、FIDが遅いとページが応答しなくなり、ユーザー体験は苛立たしいものとなってしまいます。 +

      いくつかのしきい値を定義することから始めましょう。 新しいPSI手法によると、高速なFIDは100ミリ秒未満です。 これによりアプリケーションは、入力イベントを処理しユーザーへの応答の結果が瞬時に感じるのに十分な時間を与えることができます。 低速なFIDは300ミリ秒以上となっており、その間はすべて適度にあたります。

      - 図12. Webサイトの高速、適度、低速のFIDパフォーマンスの分布。 + 図12. Webサイトの高速、適度、低速のFIDパフォーマンスの分布。
      図 12. Webサイトの高速、適度、低速のFIDパフォーマンスの分布。
      @@ -3026,7 +3366,7 @@

      図1と図9をそれぞれ見る). 高速FIDの曲線は100%から75%にゆるやかに下っていき、その後急降下します。 FIDの体験は、ほとんどのWebサイトでほぼ高速になっています。

      - 図13. 高速、適度、低速のTTFBでラベル付けされたWebサイトの分布。 + 図13. 高速、適度、低速のTTFBでラベル付けされたWebサイトの分布。
      図 13. 高速、適度、低速のTTFBでラベル付けされたWebサイトの分布。
      @@ -3036,14 +3376,14 @@

      デバイス毎のFID

      - 図14. 「デスクトップ」 WebサイトのFIDパフォーマンスの高速、適度、低速の分布。 + 図14. 「デスクトップ」 WebサイトのFIDパフォーマンスの高速、適度、低速の分布。
      図 14. デスクトップ WebサイトのFIDパフォーマンスの高速、適度、低速の分布。
      - 図15. 「携帯電話向け」WebサイトのFIDパフォーマンスの高速、適度、低速の分布。 + 図15. 「携帯電話向け」WebサイトのFIDパフォーマンスの高速、適度、低速の分布。
      図 15. 携帯電話向け WebサイトのFIDパフォーマンスの高速、適度、低速の分布。
      @@ -3051,7 +3391,7 @@

      - 図16. 高速、適度、低速FIDとしてラベル付けされたWebサイトの分布。デバイス種類別に分類されています。 + 図16. 高速、適度、低速FIDとしてラベル付けされたWebサイトの分布。デバイス種類別に分類されています。
      図 16. 高速、適度、低速FIDとしてラベル付けされたWebサイトの分布。デバイス種類別に分類されています。
      @@ -3060,7 +3400,7 @@

      有効な接続タイプ別のFID

      - 図17. ECTによって分類された高速、適度、低速FIDとしてラベル付けされたWebサイトの分布 + 図17. ECTによって分類された高速、適度、低速FIDとしてラベル付けされたWebサイトの分布
      図 17. ECTによって分類された高速、適度、低速FIDとしてラベル付けされたWebサイトの分布
      @@ -3070,7 +3410,7 @@

      FID by geo

      - 図18. 高速、適度、低速FIDでラベル付けされたWebサイトの分布を地域別に分類したもの。 + 図18. 高速、適度、低速FIDでラベル付けされたWebサイトの分布を地域別に分類したもの。
      図 18. 高速、適度、低速FIDでラベル付けされたWebサイトの分布を地域別に分類したもの。
      @@ -3080,52 +3420,79 @@

      結論

      Webページの読み込み速度を定量化することは、単一の計測では表すことのできない不完全な科学です。 従来のonload等を計測する計測する方法は、ユーザー体験とは関係のない部分まで計測してしまい、本当に抑えるべき点を見逃してしまう可能性があります。 FCPやFIDなどのユーザーの知覚に相当する計測は、ユーザーが見たり感じたりする内容を着実に伝達できます。 ただそれでも、どちらの計測も単独で見てはページ全体の読み込み体験が高速なのか低速かについての結論を導き出すことはできません。 多くの計測値を総合的に見ることでのみ、Webサイト個々のパフォーマンスとWebの状態を理解することができます。

      この章で表されたデータから、高速なWebサイトとにするためには多くの設定されるべき目標と作業があることを示しています。 確かなフォームファクター、効果的な接続の種類、そして地理にはユーザー体験の向上と相関しますが、低いパフォーマンスとなる人口の統計も組み合わせる必要があることを忘れてはいけません。 殆どの場合、Webプラットフォームはビジネスで使われています。コンバージョン率を改善してより多くのお金を稼ぐことは、Webサイトを高速化する大きな動機になるでしょう。 最終的に、すべてのWebサイトのパフォーマンスとは、ユーザーの邪魔をしたり、イラつかせたり、怒らせたりしない方法で、ユーザーにより良い体験を提供することです。

      -

      Webがまた一つ古くなり、ユーザー体験を測定する能力が徐々に向上するにつれて、開発者がより総合的なユーザー体験を捉えて計測された値を身近に思えるようになることを楽しみにしています。 FCPは有用なコンテンツをユーザーに表示するタイムラインのほぼ最初部分であり、それ以外にもLarge Contentful Paint（LCP）と呼ばれる新しい計測値が出現して、ページの読み込みがどのように認識されるかの可視性が向上しています。 Layout Instability APIは、ページの読み込み以降でユーザーが不満を持つ体験がある事を新たに垣間見せてくれました。

      +

      + Webがまた一つ古くなり、ユーザー体験を測定する能力が徐々に向上するにつれて、開発者がより総合的なユーザー体験を捉えて計測された値を身近に思えるようになることを楽しみにしています。 FCPは有用なコンテンツをユーザーに表示するタイムラインのほぼ最初部分であり、それ以外にもLarge Contentful Painthttps://web.dev/largest-contentful-paint（LCP）と呼ばれる新しい計測値が出現して、ページの読み込みがどのように認識されるかの可視性が向上しています。 Layout Instability APIhttps://web.dev/layout-instability-apiは、ページの読み込み以降でユーザーが不満を持つ体験がある事を新たに垣間見せてくれました。 +

      こういった新しい計測が出来るようになった2020年のWebは、さらに透明性が高まって理解が深まり、開発者がパフォーマンスを改善するための有意義な進歩を遂げることで、より良いユーザー体験を提供できるでしょう。

      -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":8,"title":"セキュリティ","description":"トランスポート・レイヤー・セキュリティ(TLS()、混合コンテンツ、セキュリティヘッダ、Cookie、サブリソース完全性を網羅した2019年版Web Almanacのセキュリティの章。","authors":["ScottHelme","arturjanc"],"reviewers":["bazzadp","ghedo","paulcalvano"],"translators":["ksakae"],"discuss":"1763","results":"https://docs.google.com/spreadsheets/d/1Zq2tQhPE06YZUcbzryRrBE6rdZgHHlqEp2XcgS37cm8/","queries":"08_Security","published":"2019-11-11","last_updated":"2020-05-19","chapter":"security"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 8 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - セキュリティ +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":8,"title":"セキュリティ","description":"トランスポート・レイヤー・セキュリティ(TLS()、混合コンテンツ、セキュリティヘッダ、Cookie、サブリソース完全性を網羅した2019年版Web Almanacのセキュリティの章。","authors":["ScottHelme","arturjanc"],"reviewers":["bazzadp","ghedo","paulcalvano"],"translators":["ksakae"],"discuss":"1763","results":"https://docs.google.com/spreadsheets/d/1Zq2tQhPE06YZUcbzryRrBE6rdZgHHlqEp2XcgS37cm8/","queries":"08_Security","published":"2019-11-11","last_updated":"2020-05-19","chapter":"security"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -3134,20 +3501,26 @@

    - + -
    {{ self.written_by_before() }} Scott Helme, {{ self.and() }} Artur Janc{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Barry Pollard, Alessandro Ghedini, {{ self.and() }} Paul Calvano{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    Web Almanacのこの章では、Web上のセキュリティの現状を見ていきます。オンラインでのセキュリティとプライバシーの重要性がますます高まる中、サイト運営者とユーザーを保護するための機能が増えています。ここでは、ウェブ上でのこれらの新機能の採用状況を見ていきます。

    トランスポートレイヤーセキュリティ

    -

    現在、オンラインでのセキュリティとプライバシーを向上させるための最大の後押しは、おそらくトランスポート・レイヤー・セキュリティ（TLS）の普及です。TLS（または古いバージョンのSSL）は、HTTPSの「S」を提供し、安全でプライベートなWebサイトのブラウジングを可能にするプロトコルです。ウェブ上でのHTTPSの使用が大幅に増加しているだけでなく、TLSv1.2やTLSv1.3のような最新バージョンのTLSが増加していることも重要です。

    +

    + 現在、オンラインでのセキュリティとプライバシーを向上させるための最大の後押しは、おそらくトランスポート・レイヤー・セキュリティ（TLS）の普及です。TLS（または古いバージョンのSSL）は、HTTPSの「S」を提供し、安全でプライベートなWebサイトのブラウジングを可能にするプロトコルです。ウェブ上でのHTTPSの使用が大幅に増加しているhttps://httparchive.org/reports/state-of-the-web#pctHttpsだけでなく、TLSv1.2やTLSv1.3のような最新バージョンのTLSが増加していることも重要です。 +

    - 図1.HTTPとHTTPS の使用法。 + 図1.HTTPとHTTPS の使用法。
    図 1.HTTPとHTTPS の使用法。
    @@ -3155,17 +3528,20 @@

    プロトコルのバージョン

    - 図2. TLSプロトコルのバージョン使用状況 + 図2. TLSプロトコルのバージョン使用状況
    図 2. TLSプロトコルのバージョン使用状況
    -

    図2は、さまざまなプロトコルバージョンのサポートを示しています。TLSv1.0やTLSv1.1のようなレガシーなTLSバージョンの使用は最小限であり、ほとんどすべてのサポートはプロトコルの新しいバージョンであるTLSv1.2やTLSv1.3に対応しています。TLSv1.3はまだ標準としては非常に若いですが（TLSv1.3は2018年8月に正式に承認されたばかりです）、TLSを使用するリクエストの40％以上が最新バージョンを使用しています！　TLSv1.0やTLSv1.1のようなレガシーバージョンの使用はほとんどありません。

    +

    + 図2は、さまざまなプロトコルバージョンのサポートを示しています。TLSv1.0やTLSv1.1のようなレガシーなTLSバージョンの使用は最小限であり、ほとんどすべてのサポートはプロトコルの新しいバージョンであるTLSv1.2やTLSv1.3に対応しています。TLSv1.3はまだ標準としては非常に若いですが（TLSv1.3は2018年8月https://tools.ietf.org/html/rfc8446に正式に承認されたばかりです）、TLSを使用するリクエストの40％以上が最新バージョンを使用しています！　TLSv1.0やTLSv1.1のようなレガシーバージョンの使用はほとんどありません。 +

    これは、多くのサイトがサードパーティコンテンツのために大きなプレイヤーからのリクエストを使用していることが原因であると考えられます。例えば、どのようなサイトでもGoogle Analytics、Google AdWords、またはGoogle FontsをロードしGoogleのような大規模なプレイヤーは通常新しいプロトコルのためのアーリーアダプターです。

    ホームページだけを見て、それ以外のサイトのリクエストをすべて見ない場合、TLSの使用率は予想通りかなり高いですが、WordpressのようなCMSサイトやCDNのようなサイトが原因である可能性は高いです。

    - 図3. ホームページリクエストだけのTLSプロトコルバージョン使用状況。 + 図3. ホームページリクエストだけのTLSプロトコルバージョン使用状況。
    図 3. ホームページリクエストだけのTLSプロトコルバージョン使用状況。
    @@ -3242,8 +3618,14 @@

    図 4. 使用されている認証局トップ10。

    前述したように、Googleのボリュームは他のサイトでGoogleアナリティクス、Google Adwords、またはGoogle Fontsを繰り返し使用していることを反映している可能性が高い。

    -

    Let's Encryptの台頭は2016年初頭の開始後、急成長を遂げ、それ以来世界でもトップレベルの証明書発行局の1つになりました。無料の証明書の可用性と自動化されたツールは、ウェブ上でのHTTPSの採用に決定的に重要な役割を果たしています。Let's Encryptは、これらの両方において重要な役割を果たしています。

    -

    コストの削減により、HTTPSへの参入障壁は取り除かれましたが、Let's Encryptが使用する自動化は証明書の寿命を短くできるため、長期的にはより重要であると思われます、これは多くのセキュリ ティ上のメリットがあります。

    +

    + Let's Encrypthttps://letsencrypt.org/ja/の台頭は2016年初頭の開始後、急成長を遂げ、それ以来世界でもトップレベルの証明書発行局の1つになりました。無料の証明書の可用性と自動化されたツールは、ウェブ上でのHTTPSの採用に決定的に重要な役割を果たしています。Let's Encryptは、これらの両方において重要な役割を果たしています。 +

    +

    + コストの削減により、HTTPSへの参入障壁は取り除かれましたが、Let's Encryptが使用する自動化は証明書の寿命を短くできるため、長期的にはより重要であると思われます、これは多くのセキュリ ティ上のメリットがありますhttps://scotthelme.co.uk/why-we-need-to-do-more-to-reduce-certificate-lifetimes/。 +

    認証キーの種類

    HTTPSを使用するという重要な要件と並行して、適切な構成を使用するという要件もあります。非常に多くの設定オプションと選択肢があるため、これは慎重にバランスを取る必要があります。

    まず、認証に使用される鍵について見ていきましょう。従来、証明書はRSAアルゴリズムを使用した鍵に基づいて発行されてきましたが、より新しく優れたアルゴリズムであるECDSA(Elliptic Curve Digital Signature Algorithm — 楕円曲線DSA) を使用しており、RSAアルゴリズムよりも優れた性能を発揮する小さな鍵の使用を可能にしています。私たちのクロールの結果を見ると、ウェブの大部分がRSAを使用していることがわかります。

    @@ -3277,10 +3659,15 @@

    Forward secrecy

    -

    Forward secrecyは将来サーバの秘密鍵が漏洩した場合でも、サーバへの各接続が公開されるのを防ぐような方法で接続を保護するいくつかの鍵交換メカニズムの特性です。これは、接続のセキュリティを保護するために全てのTLS接続で望ましい事として、セキュリティコミュニティ内ではよく理解されています。2008年にTLSv1.2でオプション設定として導入され、2018年にはTLSv1.3でForward Secrecyの使用が必須となりました。

    +

    + Forward secrecyhttps://ja.wikipedia.org/wiki/Forward_secrecyは将来サーバの秘密鍵が漏洩した場合でも、サーバへの各接続が公開されるのを防ぐような方法で接続を保護するいくつかの鍵交換メカニズムの特性です。これは、接続のセキュリティを保護するために全てのTLS接続で望ましい事として、セキュリティコミュニティ内ではよく理解されています。2008年にTLSv1.2でオプション設定として導入され、2018年にはTLSv1.3でForward Secrecyの使用が必須となりました。 +

    Forward Secrecyを提供するTLSリクエストの割合を見ると、サポートが非常に大きいことがわかります。デスクトップの96.92％、モバイルリクエストの96.49％がForward Secrecyを使用しています。TLSv1.3の採用が継続的に増加していることから、これらの数字はさらに増加すると予想されます。

    暗号スイート

    -

    TLSでは、さまざまな暗号スイートを使用できます。従来、TLSの新しいバージョンは暗号スイートを追加してきましたが、古い暗号スイートを削除することには消極的でした。TLSv1.3はこれを単純化するために、より少ない暗号スイートのセットを提供し、古い安全でない暗号スイートを使用することを許可しません。SSL Labs のようなツールは、ウェブサイトのTLS設定 (サポートされている暗号スイートとその好ましい順序を含む) を簡単に見ることができ、より良い設定を促進するのに役立ちます。TLSリクエストのためにネゴシエートされた暗号化スイートの大部分は確かに優れたものであったことがわかります。

    +

    + TLSでは、さまざまな暗号スイートを使用できます。従来、TLSの新しいバージョンは暗号スイートを追加してきましたが、古い暗号スイートを削除することには消極的でした。TLSv1.3はこれを単純化するために、より少ない暗号スイートのセットを提供し、古い安全でない暗号スイートを使用することを許可しません。SSL Labshttps://www.ssllabs.com/ のようなツールは、ウェブサイトのTLS設定 (サポートされている暗号スイートとその好ましい順序を含む) を簡単に見ることができ、より良い設定を促進するのに役立ちます。TLSリクエストのためにネゴシエートされた暗号化スイートの大部分は確かに優れたものであったことがわかります。 +

    @@ -3329,8 +3716,14 @@

    図 6. 使用されている暗号スイートの使用法

    -

    古いCBC暗号は安全性が低いので、GCM暗号がこのように広く使われるようになったのはポジティブなことです。CHACHA20_POLY1305はまだニッチな暗号スイートであり、私たちはまだ安全でないトリプルDES暗号をごくわずかしか使っていません。

    -

    これらはChromeを使ったクロールに使われた暗号化スイートですが、サイトは古いブラウザでも他の暗号化スイートをサポートしている可能性が高いことに注意してください。例えばSSL Pulse などの他の情報源では、サポートされているすべての暗号スイートとプロトコルの範囲についてより詳細な情報を提供しています。

    +

    + 古いCBC暗号は安全性が低いので、GCM暗号がこのように広く使われるようになったのはポジティブなことです。CHACHA20_POLY1305https://blog.cloudflare.com/it-takes-two-to-chacha-poly/はまだニッチな暗号スイートであり、私たちはまだ安全でないトリプルDES暗号https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%97%E3%83%ABDES#%E5%AE%89%E5%85%A8%E6%80%A7をごくわずかしか使っていません。 +

    +

    + これらはChromeを使ったクロールに使われた暗号化スイートですが、サイトは古いブラウザでも他の暗号化スイートをサポートしている可能性が高いことに注意してください。例えばSSL Pulsehttps://www.ssllabs.com/ssl-pulse/ などの他の情報源では、サポートされているすべての暗号スイートとプロトコルの範囲についてより詳細な情報を提供しています。 +

    混合コンテンツ

    ウェブ上のほとんどのサイトは元々HTTPサイトとして存在しており、HTTPSにサイトを移行しなければなりませんでした。この「リフトアンドシフト」作業は難しく、時には見落としたり、取り残されたりすることもあります。その結果、ページはHTTPSで読み込まれているが、ページ上の何か（画像やスタイルなど）はHTTPで読み込まれているような、コンテンツが混在しているサイトが発生します。コンテンツが混在していると、セキュリティやプライバシーに悪影響を及ぼし、発見して修正するのが困難になることがあります。

    @@ -3362,18 +3755,25 @@

    図 7. 混在コンテンツの利用状況。

    モバイル（645,485サイト）とデスクトップ（594,072サイト）では、約20％のサイトが何らかの形で混合コンテンツを表示していることがわかります。画像のようなパッシブな混合コンテンツの危険性は低いですが、混合コンテンツを持つサイトのほぼ4分の1がアクティブな混合コンテンツを持っていることがわかります。JavaScriptのようなアクティブな混合コンテンツは、攻撃者が自分の敵対的なコードを簡単にページに挿入できるため、より危険です。

    -

    これまでのウェブブラウザは、受動的な混合コンテンツを許可して警告を表示していたが、能動的な混合コンテンツはブロックしていた。しかし最近では、Chrome発表 はこの点を改善し、HTTPSが標準になるにつれて代わりにすべての混合コンテンツをブロックすることを意図しています。

    +

    + これまでのウェブブラウザは、受動的な混合コンテンツを許可して警告を表示していたが、能動的な混合コンテンツはブロックしていた。しかし最近では、Chrome発表https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html はこの点を改善し、HTTPSが標準になるにつれて代わりにすべての混合コンテンツをブロックすることを意図しています。 +

    セキュリティヘッダ

    -

    サイト運営者がユーザーをより良く保護するための多くの新しい機能が、ブラウザに組み込まれたセキュリティ保護を設定したり制御したりできる新しいHTTPレスポンスヘッダの形で提供されています。これらの機能の中には、簡単に有効にして大きなレベルの保護を提供するものもあれば、サイト運営者が少し作業を必要とするものもあります。サイトがこれらのヘッダを使用しており、正しく設定されているかどうかを確認したい場合は、Security Headersツールを使用してスキャンできます。

    +

    + サイト運営者がユーザーをより良く保護するための多くの新しい機能が、ブラウザに組み込まれたセキュリティ保護を設定したり制御したりできる新しいHTTPレスポンスヘッダの形で提供されています。これらの機能の中には、簡単に有効にして大きなレベルの保護を提供するものもあれば、サイト運営者が少し作業を必要とするものもあります。サイトがこれらのヘッダを使用しており、正しく設定されているかどうかを確認したい場合は、Security Headershttps://securityheaders.com/ツールを使用してスキャンできます。 +

    - 図8. セキュリティヘッダの使用法 + 図8. セキュリティヘッダの使用法
    図 8. セキュリティヘッダの使用法

    HTTP Strict Transport Security

    -

    HSTS ヘッダーは、Webサイトがブラウザに、安全なHTTPS接続でのみサイトと通信するように指示することを可能にします。これは、http:// URLを使用しようとする試みは、リクエストが行われる前に自動的にhttps://に変換されることを意味します。リクエストの40％以上がTLSを使用できることを考えると、要求するようにブラウザに指示しているリクエストの割合はかなり低いと考えられます。

    +

    + HSTShttps://tools.ietf.org/html/rfc6797 ヘッダーは、Webサイトがブラウザに、安全なHTTPS接続でのみサイトと通信するように指示することを可能にします。これは、http:// URLを使用しようとする試みは、リクエストが行われる前に自動的にhttps://に変換されることを意味します。リクエストの40％以上がTLSを使用できることを考えると、要求するようにブラウザに指示しているリクエストの割合はかなり低いと考えられます。 +

    @@ -3457,27 +3857,48 @@

    図 10. HSTSの`max-age`ポリシーのパーセンタイル別の中値。

    HSTSプリロード

    -

    HTTPレスポンスヘッダーを介して配信されるHSTSポリシーでは、初めてサイトを訪れたときに、ブラウザはポリシーが設定されているかどうかを知ることができません。この初回使用時の信頼の問題を回避するために、サイト運営者はブラウザ(または他のユーザーエージェント)にポリシーをプリロードしておくことができます。

    -

    プリロードにはいくつかの要件があり、HSTSプリロードサイトで概要が説明されています。現在の基準では、デスクトップでは0.31％、モバイルでは0.26％というごく少数のサイトしか対象としていないことがわかる。サイトは、ドメインをプリロードするために送信する前、ドメインの下にあるすべてのサイトをHTTPSに完全に移行させておく必要があります。

    +

    + HTTPレスポンスヘッダーを介して配信されるHSTSポリシーでは、初めてサイトを訪れたときに、ブラウザはポリシーが設定されているかどうかを知ることができません。この初回使用時の信頼https://en.wikipedia.org/wiki/Trust_on_first_useの問題を回避するために、サイト運営者はブラウザ(または他のユーザーエージェント)にポリシーをプリロードしておくことができます。 +

    +

    + プリロードにはいくつかの要件があり、HSTSプリロードhttps://hstspreload.org/サイトで概要が説明されています。現在の基準では、デスクトップでは0.31％、モバイルでは0.26％というごく少数のサイトしか対象としていないことがわかる。サイトは、ドメインをプリロードするために送信する前、ドメインの下にあるすべてのサイトをHTTPSに完全に移行させておく必要があります。 +

    コンテンツセキュリティポリシー

    -

    ウェブアプリケーションは、敵対的なコンテンツがページへ挿入される攻撃に頻繁に直面しています。最も心配なコンテンツはJavaScriptであり、攻撃者がJavaScriptをページに挿入する方法を見つけると、有害な攻撃を実行できます。これらの攻撃はクロスサイトスクリプティング(XSS)として知られており、コンテンツセキュリティポリシー(CSP) はこれらの攻撃に対する効果的な防御策を提供しています。

    +

    + ウェブアプリケーションは、敵対的なコンテンツがページへ挿入される攻撃に頻繁に直面しています。最も心配なコンテンツはJavaScriptであり、攻撃者がJavaScriptをページに挿入する方法を見つけると、有害な攻撃を実行できます。これらの攻撃はクロスサイトスクリプティング(XSS)https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0として知られており、コンテンツセキュリティポリシー(CSP)https://www.w3.org/TR/CSP2/ はこれらの攻撃に対する効果的な防御策を提供しています。 +

    CSPとは、ウェブサイトが公開しているHTTPヘッダ(Content-Security-Policy)のことで、サイトで許可されているコンテンツに関するルールをブラウザに伝えるものです。セキュリティ上の欠陥のために追加のコンテンツがサイトに注入され、それがポリシーで許可されていない場合、ブラウザはそのコンテンツの使用をブロックします。XSS保護の他にも、CSPは、HTTPSへの移行を容易にするなど、いくつかの重要な利点を提供しています。

    -

    CSPの多くの利点にもかかわらず、その非常に目的がページ上で許容されるものを制限することであるため、ウェブサイトに実装することは複雑になる可能性があります。ポリシーは必要なすべてのコンテンツやリソースを許可しなければならず、大きく複雑になりがちです。レポートURIのようなツールは、適切なポリシーを分析して構築するのに役立ちます。

    +

    + CSPの多くの利点にもかかわらず、その非常に目的がページ上で許容されるものを制限することであるため、ウェブサイトに実装することは複雑になる可能性があります。ポリシーは必要なすべてのコンテンツやリソースを許可しなければならず、大きく複雑になりがちです。レポートURIhttps://report-uri.com/のようなツールは、適切なポリシーを分析して構築するのに役立ちます。 +

    デスクトップページのわずか5.51％にCSPが含まれ、モバイルページのわずか4.73％にCSPが含まれていることがわかりましたが、これは展開の複雑さが原因と思われます。

    ハッシュ/ノンス

    -

    CSPの一般的なアプローチは、JavaScriptなどのコンテンツをページにロードすることを許可されているサードパーティドメインのホワイトリストを作成することです。これらのホワイトリストの作成と管理は困難な場合があるため、ハッシュとノンスが代替的なアプローチとして導入されました。ハッシュはスクリプトの内容に基づいて計算されるので、ウェブサイト運営者が公開しているスクリプトが変更されたり、別のスクリプトが追加されたりするとハッシュと一致せずブロックされてしまいます。ノンスは、CSPによって許可され、スクリプトにタグが付けられているワンタイムコード(ページが読み込まれるたびに変更され推測されるのを防ぐ必要があります)です。このページのノンスの例は、ソースを見てGoogle Tag Managerがどのように読み込まれているかを見ることで見ることができます。

    +

    + CSPの一般的なアプローチは、JavaScriptなどのコンテンツをページにロードすることを許可されているサードパーティドメインのホワイトリストを作成することです。これらのホワイトリストの作成と管理は困難な場合があるため、ハッシュhttps://www.w3.org/TR/CSP2/#source-list-valid-hashesとノンスhttps://www.w3.org/TR/CSP2/#source-list-valid-noncesが代替的なアプローチとして導入されました。ハッシュはスクリプトの内容に基づいて計算されるので、ウェブサイト運営者が公開しているスクリプトが変更されたり、別のスクリプトが追加されたりするとハッシュと一致せずブロックされてしまいます。ノンスは、CSPによって許可され、スクリプトにタグが付けられているワンタイムコード(ページが読み込まれるたびに変更され推測されるのを防ぐ必要があります)です。このページのノンスの例は、ソースを見てGoogle Tag Managerがどのように読み込まれているかを見ることで見ることができます。 +

    調査対象となったサイトのうち、ノンスソースを使用しているのはデスクトップページで0.09％、ハッシュソースを使用しているのはデスクトップページで0.02％にとどまっている。モバイルページではノンスソースを使用しているサイトは0.13%とやや多いが、ハッシュソースの使用率は0.01%とモバイルページの方が低い。

    strict-dynamic

    - CSPの次のイテレーションにおけるstrict-dynamicの提案は、ホワイトリスト化されたスクリプトがさらにスクリプトの依存性をロードできるようにすることで、CSPを使用するためのサイト運営者の負担をさらに軽減します。すでにいくつかの最新ブラウザでサポートされているこの機能の導入にもかかわらず、ポリシーにこの機能を含めるのは、デスクトップページの0.03％とモバイルページの0.1％にすぎません。 + CSPhttps://www.w3.org/TR/CSP3/の次のイテレーションにおけるstrict-dynamichttps://www.w3.org/TR/CSP3/#strict-dynamic-usageの提案は、ホワイトリスト化されたスクリプトがさらにスクリプトの依存性をロードできるようにすることで、CSPを使用するためのサイト運営者の負担をさらに軽減します。すでにいくつかの最新ブラウザでサポートhttps://caniuse.com/#feat=mdn-http_headers_csp_content-security-policy_strict-dynamicされているこの機能の導入にもかかわらず、ポリシーにこの機能を含めるのは、デスクトップページの0.03％とモバイルページの0.1％にすぎません。

    trusted-types

    -

    XSS攻撃には様々な形がありますが、Trusted-TypesはDOM-XSSに特化して作られました。効果的なメカニズムであるにもかかわらず、私たちのデータによると、モバイルとデスクトップの2つのページだけがTrusted-Typesディレクティブを使用しています。

    +

    + XSS攻撃には様々な形がありますが、Trusted-Typeshttps://github.com/w3c/webappsec-trusted-typesはDOM-XSSに特化して作られました。効果的なメカニズムであるにもかかわらず、私たちのデータによると、モバイルとデスクトップの2つのページだけがTrusted-Typesディレクティブを使用しています。 +

    unsafe inlineとunsafe-eval

    @@ -3492,14 +3913,20 @@

    frame-ancestors

    -

    クリックジャッキングとして知られているもう1つの一般的な攻撃は、敵対するウェブサイトのiframeの中にターゲットのウェブサイトを配置し、自分たちがコントロールしている隠しコントロールやボタンをオーバーレイする攻撃者によって行われます。X-Frame-Optionsヘッダー(後述)はもともとフレームを制御することを目的としていましたが、柔軟性がなく、CSPのframe-ancestorsはより柔軟なソリューションを提供するために介入しました。サイト運営者は、フレーム化を許可するホストのリストを指定できるようになり、他のホストがフレーム化しようとするのを防ぐことができるようになりました。

    +

    + クリックジャッキングhttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0として知られているもう1つの一般的な攻撃は、敵対するウェブサイトのiframeの中にターゲットのウェブサイトを配置し、自分たちがコントロールしている隠しコントロールやボタンをオーバーレイする攻撃者によって行われます。X-Frame-Optionsヘッダー(後述)はもともとフレームを制御することを目的としていましたが、柔軟性がなく、CSPのframe-ancestorsはより柔軟なソリューションを提供するために介入しました。サイト運営者は、フレーム化を許可するホストのリストを指定できるようになり、他のホストがフレーム化しようとするのを防ぐことができるようになりました。 +

    調査したページのうち、デスクトップページの2.85％がCSPでframe-ancestorsディレクティブを使用しており、デスクトップページの0.74％がframe-Ancestorsを'none'に設定してフレーミングを禁止し、0.47％のページがframe-ancestorsを'self'に設定して自分のサイトのみがフレーミングできるようにしています。モバイルでは2.52％のページがframe-ancestorsを使用しており、0.71％が'none'を設定し、0.41％がself'を設定しています。

    参照元ポリシー

    - Referrer-PolicyReferrer-Policyhttps://www.w3.org/TR/referrer-policy/ヘッダーは、ユーザーが現在のページから離れた場所へ移動したとき、Referererヘッダーにどのような情報を送るかをサイトが制御することを可能とします。これは、検索クエリやURLパラメータに含まれるその他のユーザー依存情報など、URLに機密データが含まれている場合、情報漏洩の原因となる可能性があります。Refererヘッダで送信される情報を制御し、理想的には制限することで、サイトはサードパーティに送信される情報を減らすことで訪問者のプライバシーを保護できます。

    -

    リファラーポリシーはReferererヘッダのスペルミスこれはよく知られたエラーとなっていますに従っていないことに注意してください。

    +

    + リファラーポリシーはReferererヘッダのスペルミスこれはよく知られたエラーとなっていますhttps://stackoverflow.com/questions/3087626/was-the-misspelling-of-the-http-field-name-referer-intentionalに従っていないことに注意してください。 +

    デスクトップページの3.25％とモバイルページの2.95%がReferrerer-Policyヘッダを発行しています。

    @@ -3559,10 +3986,13 @@

    図 11. Referrer-Policy 設定オプションの使用法。

    -

    この表はページによって設定された有効な値を示しており、このヘッダーを使用するページのうち、デスクトップでは99.75％、モバイルでは96.55％のページが有効なポリシーを設定していることがわかる。最も人気のある設定はno-referrer-when-downgradeで、これはユーザがHTTPSページからHTTPページに移動する際Referererヘッダが送信されないようにするものです。2番目に人気のある選択はstrict-origin-when-cross-originで、これはスキームのダウングレード(HTTPSからHTTPナビゲーション)時に情報が送信されるのを防ぎ、Referererで情報が送信される際にはソースのオリジンのみを含み、完全なURLは含まれません(例えば、https://www.example.com/page/ではなくhttps://www.example.com)。その他の有効な設定の詳細は、Referrerer Policy specificationに記載されています、unsafe-urlの多用はさらなる調査を必要としますが、アナリティクスや広告ライブラリのようなサードパーティコンポーネントである可能性が高いです。

    +

    + この表はページによって設定された有効な値を示しており、このヘッダーを使用するページのうち、デスクトップでは99.75％、モバイルでは96.55％のページが有効なポリシーを設定していることがわかる。最も人気のある設定はno-referrer-when-downgradeで、これはユーザがHTTPSページからHTTPページに移動する際Referererヘッダが送信されないようにするものです。2番目に人気のある選択はstrict-origin-when-cross-originで、これはスキームのダウングレード(HTTPSからHTTPナビゲーション)時に情報が送信されるのを防ぎ、Referererで情報が送信される際にはソースのオリジンのみを含み、完全なURLは含まれません(例えば、https://www.example.com/page/ではなくhttps://www.example.com)。その他の有効な設定の詳細は、Referrerer Policy specificationhttps://www.w3.org/TR/referrer-policy/#referrer-policiesに記載されています、unsafe-urlの多用はさらなる調査を必要としますが、アナリティクスや広告ライブラリのようなサードパーティコンポーネントである可能性が高いです。 +

    機能方針

    - ウェブプラットフォームがより強力で機能も豊富になるにつれ、攻撃者はこれらの新しいAPIを興味深い方法で悪用できるようになります。強力なAPIの悪用を制限するために、サイト運営者はFeature-PolicyFeature-Policyhttps://w3c.github.io/webappsec-feature-policy/ヘッダを発行して必要のない機能を無効化し、悪用されるのを防ぐことができます。

    ここでは、機能方針で管理されている人気の高い5つの機能をご紹介します。

    @@ -3663,7 +4093,7 @@

    X-Frame-Options

    - X-Frame-OptionsX-Frame-Optionshttps://tools.ietf.org/html/rfc7034ヘッダーは、ページが別のページでiframeに配置できるかどうかを制御することを可能にします。上述したCSPのframe-ancestorsの柔軟性には欠けますが、フレームの細かい制御を必要としない場合には効果的です。

    デスクトップ(16.99％)とモバイル(14.77％)の両方でX-Frame-Optionsヘッダの使用率が非常に高いことがわかります。

    @@ -3700,19 +4130,25 @@

    図 14. 使用される X-Frame-Options の設定。
    -

    大多数のページでは、そのページのオリジンのみにフレーミングを制限しているようで、次の重要なアプローチはフレーミングを完全に防止することです。これはCSPのframe-ancestorsと似ており、これら2つのアプローチが最も一般的です。また、allow-fromオプションは、理論的にはサイト所有者がフレーム化を許可するサードパーティのドメインをリストアップできるようにするものですが、決して十分にサポートされていないので、非推奨とされています。

    +

    + 大多数のページでは、そのページのオリジンのみにフレーミングを制限しているようで、次の重要なアプローチはフレーミングを完全に防止することです。これはCSPのframe-ancestorsと似ており、これら2つのアプローチが最も一般的です。また、allow-fromオプションは、理論的にはサイト所有者がフレーム化を許可するサードパーティのドメインをリストアップできるようにするものですが、決して十分にサポートされていないのでhttps://developer.mozilla.org/ja/docs/Web/HTTP/X-Frame-Options#Browser_compatibility、非推奨とされています。 +

    X-Content-Type-Options

    - X-Content-Type-OptionsX-Content-Type-Optionshttps://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Content-Type-Optionsヘッダは最も広く展開されているセキュリティヘッダであり、最もシンプルであり、設定可能な値はnosniffのみです。このヘッダが発行されると、ブラウザはコンテンツの一部をContent-Typeヘッダで宣言されたMIMEタイプとして扱わなければならず、ファイルが異なるタイプのものであることを示唆したときに値を変更しようとはしません。ブラウザが誤ってタイプを嗅ぎ取るように説得された場合、さまざまなセキュリティ上の欠陥が導入される可能性となります。

    モバイルとデスクトップの両方で、17.61％のページがX-Content-Type-Optionsヘッダを発行していることがわかりました。

    X-XSS-Protection

    -

    X-XSS-Protection`ヘッダーは、サイトがブラウザに組み込まれたXSS AuditorやXSS Filterを制御することを可能にし、理論的には何らかのXSS保護を提供するはずです。

    +

    + X-XSS-Protection`https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-XSS-Protectionヘッダーは、サイトがブラウザに組み込まれたXSS AuditorやXSS Filterを制御することを可能にし、理論的には何らかのXSS保護を提供するはずです。 +

    デスクトップリクエストの14.69％とモバイルリクエストの15.2％がX-XSS-Protectionヘッダを使用していた。データを掘り下げてみると、ほとんどのサイト運営者がどのような意図を持っているかが図13に示されています。

    @@ -3756,14 +4192,30 @@

    ヘッダーに0の値を設定すると、ブラウザが持っている可能性のあるXSSの監査やフィルタを無効にするように指示します。歴史的な攻撃の中には監査やフィルタがユーザーを保護するのではなく、攻撃者を助けるように騙されてしまうことが実証されているものもあるのでサイト運営者の中には、XSSに対する十分な保護があると確信している場合にそれを無効にできるものもあります。

    これらの攻撃のため、EdgeはXSSフィルタを引退させ、ChromeはXSS監査を非推奨とし、Firefoxはこの機能のサポートを実装しませんでした。現在ではほとんど役に立たなくなっているにもかかわらず、現在でも全サイトの約15％でヘッダーが広く使われています。

    Report-To

    -

    Reporting API は、サイト運営者がブラウザからの遠隔測定の様々な情報を収集できるようにするため導入されました。サイト上の多くのエラーや問題は、ユーザーの体験を低下させる可能性がありますが、サイト運営者はユーザーが連絡しなければ知ることができません。Reporting APIは、ユーザーの操作や中断なしに、ブラウザがこれらの問題を自動的に報告するメカニズムを提供します。Reporting APIはReport-Toヘッダーを提供することで設定されます。

    -

    遠隔測定を送信すべき場所を含むヘッダーを指定することでブラウザは自動的にデータの送信を開始し、Report URIのようなサードパーティのサービスを使用してレポートを収集したり、自分で収集したりできます。導入と設定の容易さを考えると、現在この機能を有効にしているサイトは、デスクトップ（1.70％）とモバイル（1.57％）のごく一部に過ぎないことがわかります。収集できるテレメトリの種類については、Reporting API仕様を参照してください。

    +

    + Reporting APIhttps://www.w3.org/TR/reporting/ は、サイト運営者がブラウザからの遠隔測定https://scotthelme.co.uk/introducing-the-reporting-api-nel-other-major-changes-to-report-uri/の様々な情報を収集できるようにするため導入されました。サイト上の多くのエラーや問題は、ユーザーの体験を低下させる可能性がありますが、サイト運営者はユーザーが連絡しなければ知ることができません。Reporting APIは、ユーザーの操作や中断なしに、ブラウザがこれらの問題を自動的に報告するメカニズムを提供します。Reporting APIはReport-Toヘッダーを提供することで設定されます。 +

    +

    + 遠隔測定を送信すべき場所を含むヘッダーを指定することでブラウザは自動的にデータの送信を開始し、Report URIhttps://report-uri.com/のようなサードパーティのサービスを使用してレポートを収集したり、自分で収集したりできます。導入と設定の容易さを考えると、現在この機能を有効にしているサイトは、デスクトップ（1.70％）とモバイル（1.57％）のごく一部に過ぎないことがわかります。収集できるテレメトリの種類については、Reporting API仕様https://www.w3.org/TR/reporting/を参照してください。 +

    ネットワークエラーロギング

    -

    ネットワークエラーロギング(NEL)は、サイトが動作不能になる可能性のあるブラウザのさまざまな障害についての詳細な情報を提供します。Report-Toが読み込まれたページの問題を報告するために使用されるのに対し、NELヘッダーを使用すると、サイトはブラウザにこのポリシーをキャッシュするように通知し、将来の接続問題が発生したときに上記のReporting-Toヘッダーで設定されたエンドポイントを介して報告できます。したがって、NELはReporting APIの拡張機能とみなすことができます。

    +

    + ネットワークエラーロギング(NEL)https://www.w3.org/TR/network-error-logging/は、サイトが動作不能になる可能性のあるブラウザのさまざまな障害についての詳細な情報を提供します。Report-Toが読み込まれたページの問題を報告するために使用されるのに対し、NELヘッダーを使用すると、サイトはブラウザにこのポリシーをキャッシュするように通知し、将来の接続問題が発生したときに上記のReporting-Toヘッダーで設定されたエンドポイントを介して報告できます。したがって、NELはReporting APIの拡張機能とみなすことができます。 +

    もちろん、NELはReporting APIに依存しているので、NELの使用量がReporting APIの使用量を上回ることはありません。これらの数値が同じであるという事実は、これらが一緒にデプロイされていることを示唆しています。

    -

    NELは信じられないほど貴重な情報を提供しており、情報の種類についてはネットワークエラーロギング仕様で詳しく説明しています。

    +

    + NELは信じられないほど貴重な情報を提供しており、情報の種類についてはネットワークエラーロギング仕様https://w3c.github.io/network-error-logging/#predefined-network-error-typesで詳しく説明しています。 +

    クリアサイトデータ

    -

    クッキー、キャッシュ、ローカルストレージなどを介してユーザーのデバイスにデータをローカルに保存する機能が増えているため、サイト運営者はこのデータを管理する信頼性の高い方法を必要としていました。Clear Site Dataヘッダーは、特定のタイプのすべてのデータがデバイスから削除されることを確実にする手段を提供しますが、すべてのブラウザではまだサポートされていません。

    +

    + クッキー、キャッシュ、ローカルストレージなどを介してユーザーのデバイスにデータをローカルに保存する機能が増えているため、サイト運営者はこのデータを管理する信頼性の高い方法を必要としていました。Clear Site Dataヘッダーは、特定のタイプのすべてのデータがデバイスから削除されることを確実にする手段を提供しますが、すべてのブラウザではまだサポートされていませんhttps://caniuse.com/#feat=mdn-http_headers_clear-site-data。 +

    このヘッダの性質を考えると、使用量がほとんど報告されていないのは驚くに値しません。デスクトップリクエストが9件、モバイルリクエストが7件だけです。私たちのデータはサイトのホームページしか見ていないので、ログアウトのエンドポイントでヘッダーが最もよく使われているのを見ることはないでしょう。サイトからログアウトすると、サイト運営者はClear Site Dataヘッダを返し、ブラウザは指定されたタイプのすべてのデータを削除します。これはサイトのホームページでは行われないでしょう。

    クッキー

    クッキーには利用可能な多くのセキュリティ保護があり、それらのいくつかは長年にわたって利用可能であるが、それらのいくつかは本当に非常に新しいものでありここ数年の間に導入されただけです。

    @@ -3778,7 +4230,10 @@

    SameSite

    -

    クッキーの保護に追加された最近の追加機能として、SameSiteフラグは クロスサイトリクエストフォージェリ(CSRF)攻撃(XSRFとしてもよく知られています)に対する強力な保護となります。

    +

    + クッキーの保護に追加された最近の追加機能として、SameSiteフラグは クロスサイトリクエストフォージェリ(CSRF)https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA攻撃(XSRFとしてもよく知られています)に対する強力な保護となります。 +

    これらの攻撃は、ブラウザが通常、すべてのリクエストに関連するクッキーを含むという事実を利用して動作します。したがって、ログインしていてクッキーが設定されていて、悪意のあるサイトを訪問した場合、APIを呼び出すことができブラウザは「親切に」クッキーを送信します。クッキーにSameSite属性を追加することで、第三者のサイトからの呼び出しがあった場合にクッキーを送信しないようにウェブサイトがブラウザに通知し、攻撃を失敗させることができます。

    最近導入されたメカニズムなので、デスクトップとモバイルの両方でリクエストの0.1％と予想されるように、同じサイトのクッキーの使用率ははるかに低くなっています。クッキーがクロスサイトで送信されるべき使用例があります。例えば、シングルサインオンサイトは認証トークンと一緒にクッキーを設定することで暗黙のうちに動作します。

    @@ -3815,7 +4270,10 @@

    図 16. SameSite設定の使用法。

    既にSame-Siteのクッキーを利用しているページのうち、半分以上がstrictモードで利用していることがわかる。これに続いて、laxモードでSame-Siteを利用しているサイト、そして少数のサイトではnoneを利用しているサイトが続いています。この最後の値は、ブラウザベンダーがlaxモードをデフォルトで実装する可能性があるという今後の変更をオプトアウトするために使用されます。

    -

    この機能は危険な攻撃からの保護を提供するため、現在のところ、主要なブラウザが デフォルトでこの機能を実装し、値が設定されていなくてもクッキーに対してこの機能を有効にする可能性があると指摘されています。これが実現した場合、SameSiteの保護機能は有効になりますが、strictモードではなくlaxモードの弱い設定では、より多くの破損を引き起こす可能性があるためです。

    +

    + この機能は危険な攻撃からの保護を提供するため、現在のところ、主要なブラウザが デフォルトでこの機能を実装https://blog.chromium.org/2019/10/developers-get-ready-for-new.htmlし、値が設定されていなくてもクッキーに対してこの機能を有効にする可能性があると指摘されています。これが実現した場合、SameSiteの保護機能は有効になりますが、strictモードではなくlaxモードの弱い設定では、より多くの破損を引き起こす可能性があるためです。 +

    プレフィックス

    クッキーに最近追加されたもう一つの方法として、クッキープレフィックスがあります。これらはクッキーの名前を使用して、すでにカバーされている保護に加えて、2つのさらなる保護のうちの1つを追加します。上記のフラグはクッキー上で誤って設定を解除される可能性がありますが、名前は変更されませんので、セキュリティ属性を定義するために名前を使用することでより確実にフラグを強制できます。

    現在のところ、クッキーの名前の前には__Secure-か__Host-のどちらかを付けることができ、どちらもクッキーに追加のセキュリティを提供しています。

    @@ -3875,7 +4333,10 @@

    同時に、TLS設定のギャップは依然としてかなり一般的です。15％以上のページが混合コンテンツの問題に悩まされており、ブラウザに警告が表示され、4％のサイトではセキュリティ上の理由から最新のブラウザにブロックされています。同様に、HTTP Strict Transport Securityの利点は、主要なサイトのごく一部にしか及ばず、大多数のWebサイトでは最も安全なHSTS構成を有効にしておらず、HSTS プリロードの対象外となっています。HTTPSの採用が進んでいるにもかかわらず、未だに多くのクッキーがSecureフラグなしで設定されており、クッキーを設定しているホームページのうち、暗号化されていないHTTPでの送信を防止しているのはわずか4％に過ぎません。

    一般的なウェブの脆弱性からの防御

    - 機密データを扱うサイトで作業するウェブ開発者は、XSS、CSRF、クリックジャッキング、およびその他の一般的なウェブバグからアプリケーションを保護するために、オプトインウェブセキュリティ機能を有効にしていることがよくあります。これらの問題は、X-Frame-OptionsXSShttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0wiki/Cross-site_scripting、CSRFhttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA、クリックジャッキングhttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0、およびその他の一般的なウェブバグからアプリケーションを保護するために、オプトインウェブセキュリティ機能を有効にしていることがよくあります。これらの問題は、X-Frame-Options、X-Content-Type-Options、コンテンツセキュリティポリシーを含む、多くの標準的で広くサポートされているHTTPレスポンスヘッダを設定することで緩和できます。 @@ -3886,88 +4347,91 @@

    現代のウェブプラットフォームの防御

    近年、ブラウザーは、主要な脆弱性や新たなWeb脅威からの保護を提供する強力な新しいメカニズムを実装しています; これには、サブリソースの完全性、同じサイトのクッキー、およびクッキーのプレフィックスが含まれます。

    -

    これらの機能は比較的少数のウェブサイトでしか採用されていません。Trusted Types、オリジン間リソース共有、オリジン間オープナー共有のような、さらに最近のセキュリティメカニズムは、まだ広く採用されていません。

    +

    + これらの機能は比較的少数のウェブサイトでしか採用されていません。Trusted Typeshttps://w3c.github.io/webappsec-trusted-types/dist/spec/、オリジン間リソース共有https://developer.mozilla.org/ja/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)、オリジン間オープナー共有https://www.chromestatus.com/feature/5432089535053824のような、さらに最近のセキュリティメカニズムは、まだ広く採用されていません。 +

    同様に、Reporting API、ネットワークエラーロギング、Clear-Site-Dataヘッダのような便利な機能もまだ初期段階であり、現在は少数のサイトで利用されています。

    結びつき

    ウェブの規模では、オプトインプラットフォームのセキュリティ機能の全体的なカバー率は、現在のところ比較的低い。最も広く採用されている保護であっても、一般的なセキュリティ問題に対するプラットフォームのセーフガードを持たないウェブの大部分を残して、ウェブサイトの4分の1未満で有効になっています。

    -

    しかし、これらのメカニズムの採用は、より機密性の高いユーザーデータを頻繁に扱う大規模なウェブアプリケーションに偏っていることに注意することが重要です。これらのサイトの開発者は、一般的な脆弱性に対する様々な保護を可能にすることを含め、ウェブの防御力を向上させるために投資することが多くなっています。Mozilla ObservatoryやSecurity Headersなどのツールは、ウェブで利用可能なセキュリティ機能の便利なチェックリストを提供してくれます。

    +

    + しかし、これらのメカニズムの採用は、より機密性の高いユーザーデータを頻繁に扱う大規模なウェブアプリケーションに偏っていることに注意することが重要です。これらのサイトの開発者は、一般的な脆弱性に対する様々な保護を可能にすることを含め、ウェブの防御力を向上させるために投資することが多くなっています。Mozilla Observatoryhttps://observatory.mozilla.org/やSecurity Headershttps://securityheaders.com/などのツールは、ウェブで利用可能なセキュリティ機能の便利なチェックリストを提供してくれます。 +

    ウェブアプリケーションが機密性の高いユーザーデータを扱う場合はユーザーを保護し、ウェブをより安全にするためこのセクションで概説されているセキュリティメカニズムを有効にすることを検討してください。

    -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":9,"title":"アクセシビリティ","description":"読みやすさ、メディア、操作性の容易さ、および支援技術とその互換性をカバーする2019 Web Almanacアクセシビリティの章。","authors":["nektarios-paisios","obto","kleinab"],"reviewers":["ljme"],"translators":["MSakamaki"],"discuss":"1764","results":"https://docs.google.com/spreadsheets/d/16JGy-ehf4taU0w4ABiKjsHGEXNDXxOlb__idY8ifUtQ/","queries":"09_Accessibility","published":"2019-11-11","last_updated":"2020-03-01","chapter":"accessibility"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 9 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - アクセシビリティ +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":9,"title":"アクセシビリティ","description":"読みやすさ、メディア、操作性の容易さ、および支援技術とその互換性をカバーする2019 Web Almanacアクセシビリティの章。","authors":["nektarios-paisios","obto","kleinab"],"reviewers":["ljme"],"translators":["MSakamaki"],"discuss":"1764","results":"https://docs.google.com/spreadsheets/d/16JGy-ehf4taU0w4ABiKjsHGEXNDXxOlb__idY8ifUtQ/","queries":"09_Accessibility","published":"2019-11-11","last_updated":"2020-03-01","chapter":"accessibility"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -3976,28 +4440,36 @@

    - + -
    {{ self.written_by_before() }} Nektarios Paisios, David Fox, {{ self.and() }} Abigail Klein{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Laura Eberly{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} M.Sakamaki{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    Webのアクセシビリティは、包摂的で公平な社会の上では無くてはならない存在です。私たちの社会性と仕事や生活の多くがオンラインの世界に推移するにつれて、障害のある人々も分け隔てなく、すべてのオンラインの対話に参加できることがさらに重要になってきます。建築家が車椅子用の傾斜路のようなアクセシビリティ機能を作成や省略できるように、Web開発者はユーザーが頼りにしている支援技術を助けたり邪魔したりできます。

    障害を持つユーザーの事を考えた時ユーザージャーニーはほぼ同じとなることを忘れないでください、彼らは異なるツールを使っているだけでしかありません。よく知られてるツールとして、スクリーンリーダー、画面拡大鏡、ブラウザまたは文字の拡大、音声コントロールなどがありますが、これ以外にも色々とあります。

    ほとんどの場合、アクセシビリティを改善することでサイトを訪れるすべての人に対してメリットを与える事ができます。私達は普通、障害者は生涯その障害を抱えていると思っていますが、一時的だったり状況的に障害を持つような人も居ます。たとえばその誰かが全盲なのか、一時的な目の感染症なのか、はたまた野外で眩しい太陽の下という状況なのか。これらすべて、その誰かが画面を見ることができない理由の説明になります。誰もが状況により障害を持ちうるため、Webページのアクセシビリティを改善することは、あらゆる状況ですべてのユーザーの体験を向上させることに繋がります。

    -

    Webコンテンツのアクセシビリティガイドライン (WCAG)はWebサイトの利便性を向上する方法についてのアドバイスが纏められています。このガイドラインを分析の基礎に使いました。しかし、ほとんどの場合においてWebサイトのアクセシビリティをプログラムによって分析するのは非常に困難です。たとえば、Webプラットフォームは機能的には同じ結果となる複数の方法を提供しており、それを実現するための基盤となるコードはまったく別物になる場合があります。したがって、私達の分析結果はWebアクセシビリティ全体の単なる概算でしかありません。

    +

    + Webコンテンツのアクセシビリティガイドラインhttps://www.w3.org/WAI/WCAG21/quickref/ (WCAG)はWebサイトの利便性を向上する方法についてのアドバイスが纏められています。このガイドラインを分析の基礎に使いました。しかし、ほとんどの場合においてWebサイトのアクセシビリティをプログラムによって分析するのは非常に困難です。たとえば、Webプラットフォームは機能的には同じ結果となる複数の方法を提供しており、それを実現するための基盤となるコードはまったく別物になる場合があります。したがって、私達の分析結果はWebアクセシビリティ全体の単なる概算でしかありません。 +

    私達はもっとも興味深い洞察を4種類のカテゴリに分類しました。それは読みやすさ、Web上のメディア、ページナビゲーションのしやすさ、補助技術との互換性です。

    テスト中にデスクトップとモバイルの間でアクセシビリティに大きな違いは見つかりませんでした。この結果で提示されているメトリックは、とくに明記していない限りはデスクトップの分析結果です。

    読みやすさ

    Webページの主な目的はユーザーの興味を引くコンテンツを配信することです。このコンテンツはビデオや画像の組み合わせなどありますが、ほとんどの場合、シンプルなページ上のテキストです。テキストコンテンツが読者にとって読みやすいことは、とても重要です。訪問者がWebページを読めない場合、訪問者はWebページに興味を持つことがなくなり、最終的には離脱してしまうでしょう。この節ではサイトが苦労するであろう3つの分野を見ていきます。

    色のコントラスト

    -

    あなたのサイトの訪問者が完璧な内容を見ることができない、さまざまな可能性があります。訪問者は色覚多様性を持ち、フォントと背景色を区別できない場合があります（ヨーロッパ系の男性12人に1人、女性200人に1人）。おそらく、彼らは太陽の下で画面の明るさを最大にして読んでいるため、視力を著しく損なっているのでしょう。もしくは年をとってしまい、彼らの目が以前と同じように色を区別できなくなったのでしょう。

    +

    + あなたのサイトの訪問者が完璧な内容を見ることができない、さまざまな可能性があります。訪問者は色覚多様性を持ち、フォントと背景色を区別できない場合があります（ヨーロッパ系の男性12人に1人、女性200人に1人http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf）。おそらく、彼らは太陽の下で画面の明るさを最大にして読んでいるため、視力を著しく損なっているのでしょう。もしくは年をとってしまい、彼らの目が以前と同じように色を区別できなくなったのでしょう。 +

    このような条件下であっても、あなたのWebサイトが確実に読めるようにするため、テキストと背景で十分な色のコントラストがあることを確認することは重要です。

    - 図1.色のコントラストが不十分なテキストの表示例 LookZook提供 + 図1.色のコントラストが不十分なテキストの表示例 LookZook提供
    図 1.色のコントラストが不十分なテキストの表示例 LookZook提供
    @@ -4005,9 +4477,16 @@

    注意：画像中のテキストは分析できていないため、ここで報告されているメトリックはカラーコントラストテストに合格したWebサイトの総数の上限でしかありません。

    ズーミングとページのスケーリング

    -

    読みやすいフォントサイズやターゲットサイズを使うことで、ユーザーがWebサイトを読んだり操作するのを手助けできます。しかし、このガイドラインに対して完全に準拠しているWebサイトですら、訪問者一人ひとりの特定のニーズを満たすことはできません。これがピンチズームやスケーリングなどのデバイスによる機能が非常に重要となる理由です。ユーザーが貴方のページを微調整できるようにして彼らのニーズを満たします。また、小さなフォントやボタンが使われて操作が非常に難しいサイトであっても、ユーザーにそのサイトを使う機会を与えることができます。

    +

    + 読みやすいフォントサイズhttps://accessibleweb.com/question-answer/minimum-font-size/やターゲットサイズhttps://www.w3.org/WAI/WCAG21/quickref/#target-sizeを使うことで、ユーザーがWebサイトを読んだり操作するのを手助けできます。しかし、このガイドラインに対して完全に準拠しているWebサイトですら、訪問者一人ひとりの特定のニーズを満たすことはできません。これがピンチズームやスケーリングなどのデバイスによる機能が非常に重要となる理由です。ユーザーが貴方のページを微調整できるようにして彼らのニーズを満たします。また、小さなフォントやボタンが使われて操作が非常に難しいサイトであっても、ユーザーにそのサイトを使う機会を与えることができます。 +

    まれですが、スケーリングの無効化が許容される場合はあります。それは問題となるページがタッチコントロールを使ったWebベースのゲームなどの場合です。このような場合、有効にしてしまうとプレイヤーがゲームで2回タップをするたびにプレイヤーのスマホがズームインやズームアウトしてしまい、皮肉なことに操作できなくなってしまいます。

    -

    なので、開発者はメタビューポートタグで次の2つのプロパティのどちらかを設定することで、この機能を無効化できます。

    +

    + なので、開発者はメタビューポートタグhttps://developer.mozilla.org/ja/docs/Mobile/Viewport_meta_tagで次の2つのプロパティのどちらかを設定することで、この機能を無効化できます。 +

    1. user-scalableを0かnoに設定

      @@ -4016,10 +4495,13 @@

      maximum-scaleを1もしくは1.0などに設定

    -

    悲しいことに、開発者はこの機能を誤用しすぎており、モバイルサイトの3つのうち1つ（32.21％）でこの機能を無効化しています。さらにApple（iOS 10の時点）でWeb開発者がズームを無効化できなくなってしまいました。モバイルSafariは純粋にタグを無視します。すべてのサイトは新しいiOSデバイスでズームとスケーリングができます。

    +

    + 悲しいことに、開発者はこの機能を誤用しすぎており、モバイルサイトの3つのうち1つ（32.21％）でこの機能を無効化しています。さらにApple（iOS 10の時点）でWeb開発者がズームを無効化できなくなってしまいました。モバイルSafariは純粋にタグを無視しますhttps://archive.org/details/ios-10-beta-release-notes。すべてのサイトは新しいiOSデバイスでズームとスケーリングができます。 +

    - 図2. ズームとスケーリングを無効にしているサイトとデバイスの種類の割合。 + 図2. ズームとスケーリングを無効にしているサイトとデバイスの種類の割合。
    図 2. ズームとスケーリングを無効にしているサイトとデバイスの種類の割合。
    @@ -4027,28 +4509,32 @@

    言語の識別

    Webには驚くべき大量のコンテンツが溢れていますが、ここには大きな落とし穴があります。世界には1,000以上の異なる言語が存在しており、探しているコンテンツが流暢な言葉で書かれていない可能性があります。昨今、私たちは翻訳技術で大きな進歩を遂げており、貴方はおそらくその1つをWebで利用しているでしょう（例：Google翻訳）

    - この機能を円滑に行うために、翻訳エンジンはあなたのページがどの言語で書かれているかを知る必要があります。これにはlang属性が使われます。lang属性がないと、コンピューターはページが記述されている言語を推測する必要が出てきます。想像できると思いますが、ページ中で複数の言語が使われている場合、これは多くの間違いを引き起こします（たとえば、ページナビゲーションは英語なのに投稿されているコンテンツが日本語のような場合）。 + この機能を円滑に行うために、翻訳エンジンはあなたのページがどの言語で書かれているかを知る必要があります。これにはlang属性https://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/langが使われます。lang属性がないと、コンピューターはページが記述されている言語を推測する必要が出てきます。想像できると思いますが、ページ中で複数の言語が使われている場合、これは多くの間違いを引き起こします（たとえば、ページナビゲーションは英語なのに投稿されているコンテンツが日本語のような場合）。

    この言語が指定されていない場合の問題は、規定のユーザー言語でテキストを読む傾向があるスクリーンリーダーのようなテキスト読み上げ支援技術で顕著になります。

    分析の結果、26.13％でlang属性による言語指定がありませんでした。これは4分の1以上のページが上記のような問題の影響を受けやすいという事です。良いニュース？ lang属性を使っているサイトの99.68％で有効な言語コードが適用されています。

    煩わしいコンテンツ

    認知障害などの一部のユーザーは、1つの作業に対して長時間集中することが困難です。こういったユーザーは、とくに表面的なエフェクトが多く、それが目の前の作業に関わらない場合、動きやアニメーションが多く含まれるページを利用したくありません。

    - 残念なことに、私達の調査結果では無限ループアニメーションがWebでは非常に一般的であり、21.04％のページが無限CSSアニメーションや<marquee>および<blink><marquee>https://developer.mozilla.org/ja/docs/Web/HTML/Element/marqueeおよび<blink>https://developer.mozilla.org/ja/docs/Web/HTML/Element/blink要素が使われている事を示しています。

    ただし、この問題の大部分は人気のあるサードパーティー製のスタイルシートが規定で無限ループのCSSアニメーションが含まれている事が原因であることに注意してください。このようなアニメーションスタイルを実際に適用したページ数がいくつあるのか、私達は特定できませんでした。

    Web上のメディア

    画像の代替テキスト

    -

    画像はWebの体験の根幹です。それらは強い物語性を伝えることができ、注意を引いて感情を引き出すことができます。しかし、ストーリーの一部を伝えるために私達が頼っている画像は、誰でも見ることができるわけではありません。幸いなことに、1995年、HTML 2.0でこの問題に対する解決策が提供されました、それはalt属性です。alt属性は使われている画像にテキストの説明を追加できる機能をWeb開発者に提供します。これによって、画像を見ることができない（もしくは読み込めない）ときに、altテキストに書かれた説明を読むことができます。altテキストは、彼らが見逃していたかもしれないストーリーの一部を埋めることができます。

    +

    + 画像はWebの体験の根幹です。それらは強い物語性を伝えることができ、注意を引いて感情を引き出すことができます。しかし、ストーリーの一部を伝えるために私達が頼っている画像は、誰でも見ることができるわけではありません。幸いなことに、1995年、HTML 2.0でこの問題に対する解決策が提供されました、それはalt属性https://webaim.org/techniques/alttext/です。alt属性は使われている画像にテキストの説明を追加できる機能をWeb開発者に提供します。これによって、画像を見ることができない（もしくは読み込めない）ときに、altテキストに書かれた説明を読むことができます。altテキストは、彼らが見逃していたかもしれないストーリーの一部を埋めることができます。 +

    alt属性は25年前から存在していますが、49.91％のページで画像の一部にalt属性が提供されておらず、8.68％のページでまったく使用されていませんでした。

    ビデオやオーディオの字幕

    画像が強力なストーリーテラーであるように、オーディオとビデオも注目を集めたりアイデアを表現する事ができます。オーディオやビデオコンテンツに字幕が付けられていない場合、コンテンツが聞こえないユーザーはWebのほとんどを見逃してしてしまいます。耳が聞こえない、もしくは難聴のユーザーから一番よく聞くのは、すべてのオーディオとビデオコンテンツに字幕を含めて欲しいというお話です。

    - <audio>や<video>要素を使うサイトのうち、字幕を提供しているのは0.54％のみでした（<track><audio>https://developer.mozilla.org/ja/docs/Web/HTML/Element/audioや<video>https://developer.mozilla.org/ja/docs/Web/HTML/Element/video要素を使うサイトのうち、字幕を提供しているのは0.54％のみでした（<track>https://developer.mozilla.org/ja/docs/Web/Guide/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video要素を含むサイトで測定）一部のWebサイトには、ユーザーにビデオとオーディオの字幕を提供するカスタムソリューションがあります。これらは検出できなかったので、字幕を利用しているサイトの本当の割合は、おそらく少し高いでしょう。

    使いやすいページナビゲーション

    @@ -4065,17 +4551,20 @@

    - 図3. 見出しレベルの人気。 + 図3. 見出しレベルの人気。
    図 3. 見出しレベルの人気。

    Mainランドマーク

    -

    mainランドマークはWebページのメインコンテンツが始まる場所をスクリーンリーダーに示すことで、ユーザーがーすぐその場所に飛ぶことができます。mainランドマークがない場合、スクリーンリーダーのユーザーはサイト内の新しいページにアクセスするたび、手動でナビゲーションをスキップする必要が出てきます。これは明らかにイライラするでしょう。

    +

    + mainランドマークhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles/Main_roleはWebページのメインコンテンツが始まる場所をスクリーンリーダーに示すことで、ユーザーがーすぐその場所に飛ぶことができます。mainランドマークがない場合、スクリーンリーダーのユーザーはサイト内の新しいページにアクセスするたび、手動でナビゲーションをスキップする必要が出てきます。これは明らかにイライラするでしょう。 +

    ページの4分の1（26.03％）にだけmainランドマークが含まれていることが判明しました。さらに驚くべきことに、8.06％のページに複数のmainランドマークが誤って含まれているため、ユーザーは実際のメインコンテンツがどのランドマークなのかを推測する必要が出ていました。

    - 図4. 「main」ランドマークの数によるページの割合。 + 図4. 「main」ランドマークの数によるページの割合。
    図 4. 「main」ランドマークの数によるページの割合。
    @@ -4083,22 +4572,22 @@

    HTML section要素

    HTML5は2008年リリースされ、2014年に公式の標準となっているので、コンピューターとスクリーンリーダーがページの見た目と構造を理解するのに有用なHTML要素がたくさんあります。

    - <header>、<footer>、<navigation>、<main><header>https://developer.mozilla.org/ja/docs/Web/HTML/Element/header、<footer>https://developer.mozilla.org/ja/docs/Web/HTML/Element/footer、<navigation>https://developer.mozilla.org/ja/docs/Web/HTML/Element/nav、<main>https://developer.mozilla.org/ja/docs/Web/HTML/Element/mainなどの要素は特定の種類のコンテンツがどこにあるか明示的にして、ユーザーがそのページへ素早く飛ぶことを可能にします。これらはWeb全体で幅広く使われており、ほとんどがページの50％以上で使われています。(<main>は外れ値です。)

    - <article>、<hr>、<aside><article>https://developer.mozilla.org/ja/docs/Web/HTML/Element/article、<hr>https://developer.mozilla.org/ja/docs/Web/HTML/Element/hr、<aside>https://developer.mozilla.org/ja/docs/Web/HTML/Element/asideのようなものは、読者がページのメインコンテンツを理解するのに役立ちます。たとえば、<article>は記事が終了して別の記事が開始される場所を示します。これらの要素はほとんど使われておらず、使用率は約20％ですが、これらはすべてのWebページで必要となるわけではないため、とくに驚くべき統計ではありません。

    これらの要素はすべてアクセシビリティサポートを主目的として設計されており、見た目の変化はありません。つまりこれは、既存の要素を安全に置き換えることが可能なので意図しない影響で苦しむことはないでしょう。

    - 図5. 色々なHTMLセマンティック要素の利用率。 + 図5. 色々なHTMLセマンティック要素の利用率。
    図 5. 色々なHTMLセマンティック要素の利用率。
    @@ -4107,17 +4596,20 @@

    - 図6. ナビゲーションで使われるその他のHTML要素。 + 図6. ナビゲーションで使われるその他のHTML要素。
    図 6. ナビゲーションで使われるその他のHTML要素。

    スキップリンク

    -

    スキップリンクはスクリーンリーダーやキーボードだけを使うユーザーが、メインコンテンツに直接飛ぶことができるようにする、ページ上部に配置されるリンクです。これは、ページの上部にあるすべてのナビゲーションリンクとメニューを効率的に「スキップ」します。スキップリンクは、スクリーンリーダーを利用していないキーボードユーザーにとってとくに便利です。それは、このようなユーザーは通常他のクィックナビゲーションモード（ランドマークや見出しなど）にアクセスできないためです。サンプリングされたページの14.19％にスキップリンクが使われていました。

    +

    + スキップリンクhttps://webaim.org/techniques/skipnav/はスクリーンリーダーやキーボードだけを使うユーザーが、メインコンテンツに直接飛ぶことができるようにする、ページ上部に配置されるリンクです。これは、ページの上部にあるすべてのナビゲーションリンクとメニューを効率的に「スキップ」します。スキップリンクは、スクリーンリーダーを利用していないキーボードユーザーにとってとくに便利です。それは、このようなユーザーは通常他のクィックナビゲーションモード（ランドマークや見出しなど）にアクセスできないためです。サンプリングされたページの14.19％にスキップリンクが使われていました。 +

    スキップリンクの動作を試す事ができます！　シンプルにGoogle検索を実行し、検索結果ページが表示されたらすぐに「Tab」キーを押します。図7のような、事前に隠されたリンクが表示されます。

    - 図7. google.comのスキップリンク外観。 + 図7. google.comのスキップリンク外観。
    図 7. google.comのスキップリンク外観。
    @@ -4125,8 +4617,8 @@

    ショートカット

    - aria-keyshortcutsやaccesskeyaria-keyshortcutshttps://www.w3.org/TR/wai-aria-1.1/#aria-keyshortcutsやaccesskeyhttps://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/accesskey属性を介して設定されたショートカットキーは、次の2つの方法のどちらかで使うことができます。

      @@ -4134,8 +4626,8 @@

      aria-keyshortcutsはほとんど採用されておらず、400万以上ある分析対象のうち、たった159のサイトでだけ使われていました。accesskeyaria-keyshortcutshttps://www.w3.org/TR/wai-aria-1.1/#aria-keyshortcutsはほとんど採用されておらず、400万以上ある分析対象のうち、たった159のサイトでだけ使われていました。accesskeyhttps://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/accesskey属性はかなり利用されており、Webページの2.47％（モバイルだと1.74％）で使われています。デスクトップでショートカットの利用率が多いのは、開発者がモバイルでサイトにアクセスする時、キーボードでなくタッチスクリーンのみで利用することを期待しているためと考えています。

      とくに驚くべき点は、ショートカットキーを適用しているモバイルサイトの15.56％とデスクトップサイトの13.03％で、1つのショートカットキーを複数の要素に割り当てている事です。これはブラウザがショートカットキーの対象となる要素を推測する必要があることを意味しています。

      @@ -4144,26 +4636,28 @@

      テーブルの見出し

      テーブルの詳細な構造に対応したテーブルヘッダーを使うことで、特定の列または行が参照するコンテキストを失うこと無く、列や行全体を簡単に読み取り可能とします。ヘッダー行や列のないテーブルを操作しないといけないのは、スクリーンリーダーのユーザーにとっては使いづらいでしょう。これは、テーブルが非常に大きい時にスクリーンリーダーのユーザーはヘッダーのないテーブルだと自分の場所を把握するのが難しいからです。

      - テーブルのヘッダーをマークアップするには、シンプルに（<td>タグの代わりに）<th>タグを使うか、ARIAの columnheaderかrowheader<td>https://developer.mozilla.org/ja/docs/Web/HTML/Element/tdタグの代わりに）<th>https://developer.mozilla.org/ja/docs/Web/HTML/Element/thタグを使うか、ARIAの columnheaderhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles/Table_Roleかrowheaderhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles/Table_Roleロールのどれかを使います。この方法のどれかでテーブルがマークアップされていたのは、テーブルを含むページの24.5％だけでした。そのため、テーブルにヘッダーが含まれない四分の三のページは、スクリーンリーダーのユーザーにとって非常に深刻な課題を持っています。

      <th>と <td>を利用するのは、テーブルにヘッダーをマークアップするもっとも一般的な方法のようです。columnheaderとrowheaderのロールを使っているサイトはほとんど存在せず、使っているサイトは合計677個（0.058％）のみでした。

      キャプション

      - <caption><caption>https://developer.mozilla.org/ja/docs/Web/HTML/Element/caption要素が使われているテーブルキャプションは、さまざまな読者に対してより多くのコンテキストを提供できます。キャプションはテーブルが共有している情報を読む準備ができてる人や、集中できない環境だったり、作業の中断が必要な人々にとってとくに便利になります。また、スクリーンリーダーユーザーや学習障害、知的障害のある人などの、大きなテーブルだと自分の見ている場所で迷子になる可能性がある人々にとっても有用です。読者が分析している内容を理解しやすくすればするほど、より良い結果を得られるでしょう。

      にもかかわらず、表が含まれるページでは4.32％だけでしかキャプションを提供していません。

      支援技術との互換性

      ARIAの使用

      -

      Web上でもっとも一般的かつ広く活用されているアクセシビリティの使用の1つにAccessible Rich Internet Applications (ARIA)という標準があります。この標準は視覚的要素の背景にある目的（つまり、セマンティクスな意味）と、それにより可能になるアクションの種類を教えるのに役立つ追加のHTML属性をもった大きな配列を提供します。

      +

      + Web上でもっとも一般的かつ広く活用されているアクセシビリティの使用の1つにAccessible Rich Internet Applicationshttps://www.w3.org/WAI/standards-guidelines/aria/ (ARIA)という標準があります。この標準は視覚的要素の背景にある目的（つまり、セマンティクスな意味）と、それにより可能になるアクションの種類を教えるのに役立つ追加のHTML属性をもった大きな配列を提供します。 +

      ARIAを適切かつ正しく使うのは難しい場合があります。例えば、ARIA属性を使っているページでは12.31％の属性に無効な値が割り当てられていました。ARIA属性の利用に誤りがあると、ページに視覚的な影響が及ばないため問題になります。これらの間違いは自動検証ツールを使っても検出できますが、一般的には実際の支援ソフトウェア（スクリーンリーダーなど）を実際に使う必要があります。この節ではARIAがWeb上でどのように使われているか、特に標準のどの部分が最も普及しているのかを検証していきます。

      - 図8. 総ページ数とARIA属性の割合。 + 図8. 総ページ数とARIA属性の割合。
      図 8. 総ページ数とARIA属性の割合。
      @@ -4175,7 +4669,7 @@

      実際には46.91％のページが少なくとも1つのARIAロール属性を使っています。以下の図9は、最もよく使われているトップ10のARIAロールの値一覧を纏めました。

      - 図9. ariaロールトップ10。 + 図9. ariaロールトップ10。
      図 9. ariaロールトップ10。
      @@ -4186,29 +4680,40 @@
      多くのサイトは、ダイアログをアクセス可能にしようとしています
      -

      スクリーンリーダーを使っているユーザーはダイアログへのアクセスが難しく、見るからにそれがダイアログロールその相対的な人気となっています。そのため、分析されたページの約8％で挑戦しはじめているのを見るのは興奮します。繰り返しますが、これはいくつかのUIフレームワークを使った結果に思えます。

      +

      + スクリーンリーダーを使っているユーザーはダイアログへのアクセスが難しく、見るからにそれがダイアログロールhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/Roles/dialog_roleその相対的な人気となっています。そのため、分析されたページの約8％で挑戦しはじめているのを見るのは興奮します。繰り返しますが、これはいくつかのUIフレームワークを使った結果に思えます。 +

      対話的要素のあるラベル

      ユーザーがWebサイトを操作する最も一般的な方法は、Webサイトを閲覧するためのリンクやボタンなどのコントロールを使うことです。ただし、殆どの場合においてスクリーンリーダーのユーザーは、活性化されたコントロールが何を実行するのかを判断できません。この混乱が発生する原因の多くは、テキストラベルが無いためです。例えば、左向きの矢印アイコンが表示された「戻る」事を示すボタンですが、テキストが実際は含まれていません。

      ボタンまたはリンクを使うページの約4分の1（24.39％）でしか、これらのコントロールにテキストラベルが含まれていませんでした。コントロールにラベルが付いていない場合、スクリーンリーダーのユーザーは「検索」などの意味のある単語ではなく「ボタン」などの一般的なものを読み上げることがあります。

      ボタンとリンクはタブオーダーの対象であるため、視認性は非常に高くなります。Tabキーを使ってのWebサイト閲覧は、キーボードだけを使っているユーザーのWebサイト閲覧では普通の事です。なので、ユーザーはTabキーを使ってWebサイトを移動している場合に、ラベルのないボタンとリンクに必ず遭遇するでしょう。

      フォームコントロールのアクセシビリティ

      - フォームへの入力は私達が毎日行う沢山行う作業です。ショッピングや旅行の予約、仕事の申込みなど、フォームはユーザーがWebページと情報を共有する主な方法です。そのため、フォームを便利にすることは非常に重要です。これを達成するための簡単な方法は、各入力にラベルを提供することです（<label>要素やaria-labelまたはaria-labelledby<label>要素https://developer.mozilla.org/ja/docs/Web/HTML/Element/labelやaria-labelhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attributeまたはaria-labelledbyhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attributeを用いて）。悲しいことに、すべてのフォーム入力にラベルを提供しているのページは22.33％しかありませんでした。つまり、5ページあるうちの4ページは非常に記入が難しいフォームを持っています。

      必須や無効なフィールドであることを示す手がかり

      -

      大きなアスタリスクがあるフィールドに出会うと、それが必須フィールドだと理解できます。もしくは、サブミットをクリックして無効な入力があると通知された場合に、異なる色で強調表示されているものは全てを修正してから再送信する必要があります。しかし、視力が低い人や無い人はこのような視覚的合図に頼ることができないため、htmlの入力属性である requiredやaria-requiredとaria-invalid などが非常に重要になります。これらは、スクリーンリーダーに対して赤いアスタリスクや赤い強調表示されたフィールドと同等の物を提供します。更に良いことに、必要なフィールドをブラウザに教えればフォームの一部を検証することも可能です。これにはJavaScriptが必要ありません。

      +

      + 大きなアスタリスクがあるフィールドに出会うと、それが必須フィールドだと理解できます。もしくは、サブミットをクリックして無効な入力があると通知された場合に、異なる色で強調表示されているものは全てを修正してから再送信する必要があります。しかし、視力が低い人や無い人はこのような視覚的合図に頼ることができないため、htmlの入力属性である requiredやaria-requiredとaria-invalid などが非常に重要になります。これらは、スクリーンリーダーに対して赤いアスタリスクや赤い強調表示されたフィールドと同等の物を提供します。更に良いことに、必要なフィールドをブラウザに教えればフォームの一部を検証https://developer.mozilla.org/ja/docs/Learn/HTML/Forms/Form_validationすることも可能です。これにはJavaScriptが必要ありません。 +

      フォームを使っているページのうち21.73％は必須フィールドをマークアップするときに requiredかaria-required を適用しています。５分の１のサイトでだけ、これらは使用されています。これはサイトを使いやすくするための簡単な手続きです、すべてのユーザーに対してブラウザの役立つ機能を開放します。

      フォームを持つサイトの3.52％でaria-invalidが使われていることも判明しました。しかし、ほとんどのフォームは誤った情報が送信された後にこのフィールドを参照するため、このマークアップを適用しているサイトの本当の割合を確認することはできませんでした。

      重複したID

      - HTMLでIDを使い２つの要素をリンクさせることができます。例えば<label>要素は次のように機能します。ラベルにinputフィールドのIDを指定し、ブラウザはその２つをリンクさせます。結果はどうなるか？　ユーザーはこのラベルをクリックすることでユーザーはinputフィールドにフォーカスすることが可能になり、スクリーンリーダーはこのラベルを説明として使うことができます。 + HTMLでIDを使い２つの要素をリンクさせることができます。例えば<label>要素https://developer.mozilla.org/ja/docs/Web/HTML/Element/labelは次のように機能します。ラベルにinputフィールドのIDを指定し、ブラウザはその２つをリンクさせます。結果はどうなるか？　ユーザーはこのラベルをクリックすることでユーザーはinputフィールドにフォーカスすることが可能になり、スクリーンリーダーはこのラベルを説明として使うことができます。 +

      +

      + 残念ながら34.62％のサイトで重複したIDが確認できます、つまり多くのサイトではユーザーの指定したIDが複数の異なったinputを参照しています。そのため、ユーザーがラベルをクリックしてフィールドを選択すると、意図したものと違う項目が選択されるhttps://www.deque.com/blog/unique-id-attributes-matter/可能性を持っています。想像されている通り、これはショッピングカートのようなものに対して良くない結果をもたらす可能性があります。

      -

      残念ながら34.62％のサイトで重複したIDが確認できます、つまり多くのサイトではユーザーの指定したIDが複数の異なったinputを参照しています。そのため、ユーザーがラベルをクリックしてフィールドを選択すると、意図したものと違う項目が選択される可能性を持っています。想像されている通り、これはショッピングカートのようなものに対して良くない結果をもたらす可能性があります。

      - この問題はユーザーが選択肢の内容を視覚的に再確認できないスクリーンリーダーユーザーに対してさらに際立ちます。そして、aria-describedbyやaria-labelledbyaria-describedbyhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attributeやaria-labelledbyhttps://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attributeなどのARIA属性は上で説明したlabel要素と同じように機能します。つまり、サイトを操作しやすくするには、最初に重複するIDを全て削除するのが良いでしょう。

      結論

      @@ -4222,86 +4727,73 @@

      -

      Authors

      +
      + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

      + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

      -

    +
    -
    -
    +{% set metadata = {"part_number":"I","chapter_number":10,"title":"SEO","description":"コンテンツ、メタタグ、インデクサビリティ、リンク、速度、構造化データ、国際化、SPA、AMP、セキュリティをカバーする2019 Web AlmanacのSEOの章。","authors":["ymschaap","rachellcostello","AVGP"],"reviewers":["clarkeclark","andylimn","AymenLoukil","catalinred","mattludwig"],"translators":["MSakamaki"],"discuss":"1765","results":"https://docs.google.com/spreadsheets/d/1uARtBWwz9nJOKqKPFinAMbtoDgu5aBtOhsBNmsCoTaA/","queries":"10_SEO","published":"2019-11-11","last_updated":"2020-03-01","chapter":"seo"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} I {{ self.chapter() }} 10 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - SEO +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"I","chapter_number":10,"title":"SEO","description":"コンテンツ、メタタグ、インデクサビリティ、リンク、速度、構造化データ、国際化、SPA、AMP、セキュリティをカバーする2019 Web AlmanacのSEOの章。","authors":["ymschaap","rachellcostello","AVGP"],"reviewers":["clarkeclark","andylimn","AymenLoukil","catalinred","mattludwig"],"translators":["MSakamaki"],"discuss":"1765","results":"https://docs.google.com/spreadsheets/d/1uARtBWwz9nJOKqKPFinAMbtoDgu5aBtOhsBNmsCoTaA/","queries":"10_SEO","published":"2019-11-11","last_updated":"2020-03-01","chapter":"seo"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -4310,16 +4802,22 @@

    - + -
    {{ self.written_by_before() }} Yvo Schaap, Rachel Costello, {{ self.and() }} Martin Splitt{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} John Fox, Andrew Limn, Aymen Loukil, Catalin Rosu, {{ self.and() }} Matt Ludwig{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} M.Sakamaki{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    検索エンジン最適化（SEO）はデジタルマーケティングの担当者にとって、単なる趣味やサイドプロジェクトではなくWebサイトを成功に導くための重要な要素です。 SEOの主な目標は、Webサイトをクロールする必要のある検索エンジンボットと、Webサイトを操作するコンテンツの消費者向けにWebサイトを最適化することです。 SEOはWebサイトを作っている開発者から、新しい潜在顧客に対して宣伝する必要のあるデジタルマーケティング担当者に至るまで、すべてのWebサイトに関わる人に影響を及ぼします。

    -

    それでは、SEOの重要性を見ていきましょう。 今年のはじめにSEO業界は「困難な年」と言われた後ASOSが利益の87%減少を報告したため、その恐ろしさ(と魅力)への注目が集まりました。 このブランドの問題は、200以上のマイクロサイトを立ち上げた為に発生した検索エンジンのランキング低下と、Webサイトのナビゲーションの大幅な変更などの技術的変更が原因であると考えられています。驚きです！

    +

    + それでは、SEOの重要性を見ていきましょう。 今年のはじめにSEO業界は「困難な年」と言われた後ASOSが利益の87%減少https://www.bbc.co.uk/news/business-47877688を報告したため、その恐ろしさ(と魅力)への注目が集まりました。 このブランドの問題は、200以上のマイクロサイトを立ち上げた為に発生した検索エンジンのランキング低下と、Webサイトのナビゲーションの大幅な変更などの技術的変更が原因であると考えられています。驚きです！ +

    Web AlmanacのSEOの章の目的は、検索エンジンによるコンテンツのクロールとインデックス付け、そして最終的にWebサイトのパフォーマンスに影響を与えるWebのオンサイト要素を分析することです。 この章では、上位のWebサイトがユーザーおよび検索エンジンに優れた体験を提供するためにどれだけ十分な整備がされているか、そしてどのような作業を行うべきかについて見ていきます。

    この分析には、Lighthouseと、Chrome UX Report、HTML要素の分析データが含まれています。 <title>要素、様々な種類のページ上リンク、コンテンツ、読み込み速度などによるSEOの基礎だけではなく、500万以上のインデクサビリティ、構造化データ、国際化、AMPなどSEOのさらなる技術的な面にも注目しています。

    カスタムメトリクスはこれまで公開されていなかった洞察を提供します。hreflangタグ、リッチリザルトの適格性、見出しタグの使用、さらにシングルページアプリケーションのアンカーによるナビゲーション要素などの採用と実装について断言できるようになりました。

    @@ -4334,7 +4832,7 @@

    単語

    私達は、少なくとも３つの単語グループを探し合計でいくつ見つかったかを数えるようにして、ページのコンテンツを評価しました。 デスクトップページには単語グループを持たないものが2.73%見つかりました。これはWebサイトが何を指しているのかを検索エンジンが理解するのに役立つ本文コンテンツが無いことを示しています。

    - 図1.ページ毎の単語数分布。 + 図1.ページ毎の単語数分布。
    図 1.ページ毎の単語数分布。
    @@ -4344,7 +4842,7 @@

    見出しまた、ページに含まれるコンテンツのコンテキストが適切な方法で構造化されて提供されているかを調べました。 見出し（H1、 H2、 H3、など）を使ってページを整え構造化すれば、コンテンツは読みやすく、解析しやすいようになります。 そんな見出しの重要性にもかかわらず、ページの10.67%には見出しタグがまったくありませんでした。

    - 図2.ページ毎の見出し数分布。 + 図2.ページ毎の見出し数分布。
    図 2.ページ毎の見出し数分布。
    @@ -4352,13 +4850,16 @@

    見出し１ページあたりの見出し要素の中央値は10となっています。 見出しにはモバイルページで30単語、デスクトップページで32単語が含まれています。 これは、見出しを活用できているWebサイトが、ページが読みやすく、説明的で、ページの構造とコンテキストを検索エンジンボットに明確に概説することに多大な労力を費やしていることを意味します。

    - 図3.ページ毎のH1の長さの分布。 + 図3.ページ毎のH1の長さの分布。
    図 3.ページ毎のH1の長さの分布。

    具体的な見出しの長さを見ると、最初に見つかったH1要素の長さの中央値はデスクトップで19文字です。

    -

    SEOとアクセシビリティのためのH1と見出しの処理に関するアドバイスについては、Ask Google WebmastersシリーズのJohn Muellerによるこのビデオの回答をご覧ください。

    +

    + SEOとアクセシビリティのためのH1と見出しの処理に関するアドバイスについては、Ask Google WebmastersシリーズのJohn Muellerによるこのビデオの回答https://www.youtube.com/watch?v=zyqJJXWk0gkをご覧ください。 +

    メタタグ

    メタタグを使用すると、ページ上の色々な要素やコンテンツに関する特定の指示や情報を検索エンジンボットに提供できます。 特定のメタタグにはページの注目すべき情報や、クロールとインデックス付けの方法などを伝えることができます。 私達はWebサイトの提供するメタタグが、これらの機会を最大限に活用しているかどうかを評価したいと考えました。

    ページのタイトル

    @@ -4369,22 +4870,28 @@

    ページのタイトルはページの目的をユーザーや検索エンジンに伝える重要な手段です。 <title>タグはSERPSの見出にも、ページにアクセスする時のブラウザーのタブのタイトルとしても使われるので、モバイルページの97.1%にドキュメントタイトルが存在することは驚くことではないでしょう。

    - 図5.ページごとのタイトルの長さの分布。 + 図5.ページごとのタイトルの長さの分布。
    図 5.ページごとのタイトルの長さの分布。
    -

    一般的にGoogleのSERPはページタイトルの最初の50〜60文字を表示しますが、<title>タグの長さの中央値はモバイルページで21文字、デスクトップページで20文字でした。 75パーセンタイルでも、境界を下回っています。 これは、一部のSEOとコンテンツの記者が、検索エンジンによって割り当てられたSERPsのホームページを記述するために割り当てられた領域を最大限利用できていないことを示します。

    +

    + 一般的にGoogleのSERPはページタイトルの最初の50〜60文字を表示https://moz.com/learn/seo/title-tagしますが、<title>タグの長さの中央値はモバイルページで21文字、デスクトップページで20文字でした。 75パーセンタイルでも、境界を下回っています。 これは、一部のSEOとコンテンツの記者が、検索エンジンによって割り当てられたSERPsのホームページを記述するために割り当てられた領域を最大限利用できていないことを示します。 +

    メタディスクリプション

    <title>タグと比べると、メタディスクリプションが検出されたページは少なくなっており、モバイル用ホームページの64.02%にだけメタディスクリプションが設定されています。 Googleが検索者のクエリに応じてSERP内のメタディスクリプションの記述を頻繁に書き換えることを考慮すると、おそらくWebサイトの所有者はメタディスクリプションを含めることを重要視しないでしょう。

    - 図6. ページ毎のメタ記述の長さ分布。 + 図6. ページ毎のメタ記述の長さ分布。
    図 6. ページ毎のメタ記述の長さ分布。
    -

    メタディスクリプションの長さは155-160文字が推奨となっていますが、デスクトップページの中央値ははそれより短い123文字となっています。 さらに興味深い事があります、モバイルのSERPはピクセル制限により従来よりも短かくなるにも関わらず、メタディスクリプションは一貫してデスクトップよりもモバイルが長くなっています。 この制約は最近拡張されたばかりなので、おそらく多くのWebサイトの所有者がモバイルの結果に対して、より長くて説明的なメタディスクリプションの影響を確認しているのでしょう。

    +

    + メタディスクリプションの長さは155-160文字が推奨https://moz.com/learn/seo/meta-descriptionとなっていますが、デスクトップページの中央値ははそれより短い123文字となっています。 さらに興味深い事があります、モバイルのSERPはピクセル制限により従来よりも短かくなるにも関わらず、メタディスクリプションは一貫してデスクトップよりもモバイルが長くなっています。 この制約は最近拡張されたばかりなので、おそらく多くのWebサイトの所有者がモバイルの結果に対して、より長くて説明的なメタディスクリプションの影響を確認しているのでしょう。 +

    画像のaltタグ

    SEOとアクセシビリティのためのaltテキストの重要性を考えたとき、モバイルページの46.71%でしか画像にalt属性が使われていないのを見ると理想とはほど遠い状況です。 これは、Web上の画像をユーザーにとってさらにアクセスしやすく、検索エンジンにとって理解しやすくすることに関しては、まだ改善する点が多く有ることを意味します。 この問題に対する詳細についてはアクセシビリティの章を御覧ください。

    インデクサビリティ

    @@ -4397,36 +4904,54 @@

    ステータスコード

    検索エンジンにインデックスを付けたい重要なページは常に200 OKステータスコードにしておく事をお勧めします。 テストされたページの殆どは検索エンジンにアクセス可能で、デスクトップでは最初のHTML要求の87.03%が200ステータスコードを返しました。 モバイルの場合は少しだけ低く、82.95%のページだけが200となるステータスコードを返しました。

    -

    モバイルでは次によく見られるステータスコードは一時的なリダイレクトである302となっており、これはモバイルページの10.45%で見つけることができました。 この結果はデスクトップよりも多く、デスクトップ用のホームページで302ステータスコードを返すのは6.71%しかありませんでした。 これは、モバイル用のホームページがレスポンシヴでなくデバイスごとにWebサイトのバージョンが異なるような、デスクトップページの代替が用意されていることに起因している可能性があります。

    +

    + モバイルでは次によく見られるステータスコードは一時的なリダイレクトである302となっており、これはモバイルページの10.45%で見つけることができました。 この結果はデスクトップよりも多く、デスクトップ用のホームページで302ステータスコードを返すのは6.71%しかありませんでした。 これは、モバイル用のホームページがレスポンシヴでなくデバイスごとにWebサイトのバージョンが異なるようなhttps://developers.google.com/search/mobile-sites/mobile-seo/separate-urls、デスクトップページの代替が用意されていることに起因している可能性があります。 +

    注意：この結果にはステータスコード4xxと5xxは含んでいません。

    noindex

    noindex指示はHTMLの <head>もしくはHTTPヘッダーのX-Robots指示で使うことができます。 noindex指示は基本的に検索エンジンにそのページをSERPに含めないように指示しますが、ユーザーがWebサイトを操作しているときでもページはアクセス可能です。 一般的にnoindex指示は、同一コンテンツを提供するページの複製バージョン、またはオーガニック検索からWebサイトにアクセスするユーザーに価値を提供しないであろう低品質のページ(フィルタ、ファセット、内部検索ページなど)に追加されます。

    -

    モバイル用ページの96.93%がLighthouseのインデックス作成監査に合格しており、これらのページにはnoindex指示が含まれていませんでした。 ただし、これはモバイルホームページの3.07%にnoindex指示が含まれていたことも意味しています。これは心配の種であり、Googleはこれらのページのインデックスを作成できないことを意味しています。

    +

    + モバイル用ページの96.93%がLighthouseのインデックス作成監査に合格しておりhttps://developers.google.com/web/tools/lighthouse/audits/indexing、これらのページにはnoindex指示が含まれていませんでした。 ただし、これはモバイルホームページの3.07%にnoindex指示が含まれていたことも意味しています。これは心配の種であり、Googleはこれらのページのインデックスを作成できないことを意味しています。 +

    私達の調査に含まれるWebサイトはChrome UX Reportのデータセットから提供されていますが、公開されていないWebサイトは除外されています。 これはChromeが非公開であると判断したサイトは分析できないので、バイアスの重要な源です。 これについては方法論の詳細を御覧ください。

    canonicalによる最適化

    canonicalタグを使い重複ページと優先代替ページを指定します。 これにより検索エンジンは、グループ内の複数のページに散っているオーソリティを1つのメインページに統合してランキングの結果を上げることができます。

    -

    モバイル用ホームページの48.34%でcanonicalタグが使われていることが検出されました。 自分を指ししめすcanonicalタグは必須でなく、普通は複製されたページにcanonicalタグを必要とします。 ホームページがサイトのどこか他の場所に複製されることはめったに無いので、canonicalタグがページ毎で半分未満になっているのは驚くことではありません。

    +

    + モバイル用ホームページの48.34%でcanonicalタグが使われていることが検出https://developers.google.com/web/tools/lighthouse/audits/canonicalされました。 自分を指ししめすcanonicalタグは必須でなく、普通は複製されたページにcanonicalタグを必要とします。 ホームページがサイトのどこか他の場所に複製されることはめったに無いので、canonicalタグがページ毎で半分未満になっているのは驚くことではありません。 +

    robots.txt

    - 検索エンジンのクロールを制御する最も効果的な方法の1つは、robots.txtファイルです。 これは、Webサイトのルートドメインに置かれる事で、検索エンジンのクロールに対し許可しないURLとURLパスを指定する事ができるファイルです。 + 検索エンジンのクロールを制御する最も効果的な方法の1つは、robots.txtファイルhttps://www.deepcrawl.com/knowledge/technical-seo-library/robots-txt/です。 これは、Webサイトのルートドメインに置かれる事で、検索エンジンのクロールに対し許可しないURLとURLパスを指定する事ができるファイルです。 +

    +

    + Lighthouseの結果https://developers.google.com/web/tools/lighthouse/audits/robotsからモバイル用サイトの72.16%でしか有効なrobots.txtを持っていないことがわかりました。 見つかった問題の主な内訳は、robots.txtファイルをまったく持たないサイトが22%、無効なrobots.txtファイルを提供する約6%で、それぞれ検査に失敗しています。 クロールバジェットの問題https://webmasters.googleblog.com/2017/01/what-crawl-budget-means-for-googlebot.htmlに悩まされないような小規模Webサイトを運営していたりするなど、robots.txtファイルを持たない妥当な理由もあったりしますが、無効なrobots.txtが有るというのは、それだけで心配の種になります。

    -

    Lighthouseの結果からモバイル用サイトの72.16%でしか有効なrobots.txtを持っていないことがわかりました。 見つかった問題の主な内訳は、robots.txtファイルをまったく持たないサイトが22%、無効なrobots.txtファイルを提供する約6%で、それぞれ検査に失敗しています。 クロールバジェットの問題に悩まされないような小規模Webサイトを運営していたりするなど、robots.txtファイルを持たない妥当な理由もあったりしますが、無効なrobots.txtが有るというのは、それだけで心配の種になります。

    リンク

    Webページの最も重要な属性の1つはリンクです。 リンクは検索エンジンがインデックスに追加してWebサイトをナビゲートするための新しい関連ページを発見するのに役立ちます。 データセットにあるWebページの96%には最低でも1つの内部リンク存在し、93%は少なくとも１つの別ドメインへの外部リンクが存在しています。 内部や外部リンクを持たないごく一部のページは、ターゲットページへ通じるリンクという大きな価値を取りこぼしています。

    デスクトップ用のページに含まれる内部と外部リンクの数は、モバイル用のページよりも全ての場合で多くなっています。これは殆どの場合、モバイルのデザインはビューポートが小さく空間が限られているために、リンクが含まれるテキストはデスクトップに比べて少なくなっているためです。

    -

    モバイル用のページで内部リンクが少ない場合、Webサイトで問題が発生する可能性が有るため注意が必要です。 新しいWebサイトでGoogleの規定であるモバイルファーストインデックスが適用されると、そのページがデスクトップ用ではリンクされているがモバイル用からリンクが無い時、検索エンジンはそのページを見つけてランク付けするのがとても難しくなってしまいます。

    +

    + モバイル用のページで内部リンクが少ない場合、Webサイトで問題が発生する可能性https://moz.com/blog/internal-linking-mobile-first-crawl-pathsが有るため注意が必要です。 新しいWebサイトでGoogleの規定であるモバイルファーストインデックスhttps://www.deepcrawl.com/knowledge/white-papers/mobile-first-index-guide/が適用されると、そのページがデスクトップ用ではリンクされているがモバイル用からリンクが無い時、検索エンジンはそのページを見つけてランク付けするのがとても難しくなってしまいます。 +

    - 図7.ページ毎の内部リンク分布。 + 図7.ページ毎の内部リンク分布。
    図 7.ページ毎の内部リンク分布。
    - 図8.ページ毎の外部リンク数の分布。 + 図8.ページ毎の外部リンク数の分布。
    図 8.ページ毎の外部リンク数の分布。
    @@ -4434,23 +4959,30 @@

    リンクデスクトップ用ページの内部リンク(同一サイト)数は中央値で70となっていますが、モバイル用ページの内部リンク数の中央値は60になっています。外部リンク数のページ毎中央値も同じような傾向となっており、デスクトップ用ページの外部リンク数は10で、モバイル用ページは8になっています。

    - 図9.ページ毎のアンカーリンク数の分布。 + 図9.ページ毎のアンカーリンク数の分布。
    図 9.ページ毎のアンカーリンク数の分布。

    同一ページの特定スクロール位置にリンクするアンカーリンクはあまり人気が無いようです。 ホームページの65%以上でアンカーリンクは使われていません。 これはおそらく、一般的なホームページには長文形式のコンテンツが含まれていないからでしょう。

    -

    説明的なリンクテキストの測定からは良いニュースが伺えます。 モバイル用ページの89.94%がLighthouseの説明的なリンクテキストの監査で合格しています。つまり、これらのページは一般的な「ここをクリック」「リンク」「続きを読む」「全文表示」のようなリンクを使わず、より有意義なリンクテキストを使うことで、ユーザーと検索エンジンにページのコンテキストやページ同士のつながりがあることを理解できるようにしています。

    +

    + 説明的なリンクテキストの測定からは良いニュースが伺えます。 モバイル用ページの89.94%がLighthouseの説明的なリンクテキストの監査https://developers.google.com/web/tools/lighthouse/audits/descriptive-link-textで合格しています。つまり、これらのページは一般的な「ここをクリック」「リンク」「続きを読む」「全文表示」のようなリンクを使わず、より有意義なリンクテキストを使うことで、ユーザーと検索エンジンにページのコンテキストやページ同士のつながりがあることを理解できるようにしています。 +

    Advanced

    説明的で有用なコンテンツ以外に対してnoindexやDisallowという指示を出してページを検索エンジンからブロックするだけでは、Webサイトをオーガニックサーチさせるには不十分です。これらは単なる基本でしかありません。 WebサイトのパフォーマンスやSERPsの外観を向上させるなど、できることはたくさんあります。

    Webサイトのインデックス作成とランク付成功のために重要となっている技術的に複雑な局面として、速度、構造化データ、国際化、セキュリティ、モバイルフレンドリーなどがあります。

    Speed

    -

    モバイルの読み込み速度は、2018年にGoogleからランキング要素として初めて発表されました。 しかしGoogleにとって速度は新しい観点ではありません。 2010年に既に速度がランキングシグナルとして導入されたことが明らかにっています。

    +

    + モバイルの読み込み速度は、2018年にGoogleからランキング要素として初めて発表https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.htmlされました。 しかしGoogleにとって速度は新しい観点ではありません。 2010年に既に速度がランキングシグナルとして導入されたことが明らかhttps://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.htmlにっています。 +

    Webサイトが高速であることは、優れたユーザー体験のためにも重要です。 サイトの読み込みに数秒待たされるユーザは、すぐ離脱してSERPsから別の似たような内容の素早く読み込まれるページを探す傾向があります。

    Web全体の読み込み速度の分析に使った指標は Chrome UX Report（CrUX）を基にしています。このレポートは、実際のChromeユーザーからデータを収集します。 このデータで驚くべき点は、48%のWebサイトが遅いとラベル付されていることです。 FCPの25%が3秒より遅い場合、もしくは FIDの5%が300ミリ秒より遅い場合にWebサイトは低速とラベル付されます。

    - 図10.デバイスタイプごとのユーザー体験パフォーマンスの分布。 + 図10.デバイスタイプごとのユーザー体験パフォーマンスの分布。
    図 10.デバイスタイプごとのユーザー体験パフォーマンスの分布。
    @@ -4458,16 +4990,34 @@

    Speed

    デバイスごとに分けるとより鮮明になります、この画像ではタブレット(65%)、電話(58%)を示しています。

    数字だけ見るとWebの速度には暗雲が立ち込めるように思えますが、良いニュースもあります。 それはSEOの専門家とツールがWebサイトの高速化のための技術課題に集中しているという点です。 Webパフォーマンスの状態についてはパフォーマンスの章で詳しく知ることができます。

    構造化データ

    -

    構造化データを使うことでWebサイトの所有者は、JSON-LDスニペットやMicrodataなどを加える事で、Webページに付属的なセマンティックデータを付与できます。 検索エンジンはこのデータを解析してこれらのページを深く理解し、マークアップにより検索結果に追加の関連情報を表示も行う事ができます。

    +

    + 構造化データを使うことでWebサイトの所有者は、JSON-LDhttps://en.wikipedia.org/wiki/JSON-LDスニペットやMicrodatahttps://developer.mozilla.org/en-US/docs/Web/HTML/Microdataなどを加える事で、Webページに付属的なセマンティックデータを付与できます。 検索エンジンはこのデータを解析してこれらのページを深く理解し、マークアップにより検索結果に追加の関連情報を表示も行う事ができます。 +

    よく見る構造化データの種類には次のようなものがあります。

    -

    構造化データがWebサイトに提供できる追加の可視性はユーザーがサイトに訪れる機会を増やすのに役立つため、サイトの所有者にとっては魅力的です。 たとえば、比較的新しいFAQスキーマはスニペットとSERPsの領域を２倍にできます。

    +

    + 構造化データがWebサイトに提供できる追加の可視性https://developers.google.com/search/docs/guides/enhance-siteはユーザーがサイトに訪れる機会を増やすのに役立つため、サイトの所有者にとっては魅力的です。 たとえば、比較的新しいFAQスキーマhttps://developers.google.com/search/docs/data-types/faqpageはスニペットとSERPsの領域を２倍にできます。 +

    調査の結果、モバイルでリッチな結果を得ることが出来るサイトは14.67%しか無いことが解りました。 興味深いことに、デスクトップサイトの適格性はわずかに低くなり12.46%となっています。 これはサイト所有者がホームページ検索で表示されるための最適化に対して、もっと出来ることが有ることを示しています。

    構造化データのマークアップを持つサイトの中で、最もよく見る種類は次の５つでした。

      @@ -4477,12 +5027,23 @@

      サイトリンクの検索ボックスを強化するSearchActionです。

      +

      + 興味深いことに、一番良く利用されている検索エンジンの機能をトリガーするデータ型はサイトリンクの検索ボックスhttps://developers.google.com/search/docs/data-types/sitelinks-searchboxを強化するSearchActionです。 +

      トップ5のマークアップタイプはすべてGoogleの検索結果の可視性を高める物で、これらのタイプの構造化データをさらに採用する理由になるかもしれません。

      今回の分析はホームページだけを見ているため、インテリアページも考慮した場合は結果は大きく異なった結果が見えてくる可能性があります。

      -

      レビューの星はWebのホームページ上で1.09%だけにしかありません。(AggregateRatingより) また、新しく導入されたQAPageは48の例しかなく、FAQPageは少しだけ高い数が出現して218となっています。 この最後の2種類の数については、クロールを更に実行してWeb Almanacの分析を掘り下げていくと、将来増加することが予想されています。

      +

      + レビューの星はWebのホームページ上で1.09%だけにしかありません。(AggregateRatinghttps://schema.org/AggregateRatingより) また、新しく導入されたQAPagehttps://schema.org/QAPageは48の例しかなく、FAQPagehttps://schema.org/FAQPageは少しだけ高い数が出現して218となっています。 この最後の2種類の数については、クロールを更に実行してWeb Almanacの分析を掘り下げていくと、将来増加することが予想されています。 +

      国際化

      -

      一部のGoogle検索の従業員によれば、国際化はSEOの最も複雑な面の1つとなっているようです。 SEOの国際化は、ユーザーが特定の言語のコンテンツをターゲットしていることを確認し、それに合わせて複数の言語や国のバージョンを持つWebサイトから適切なコンテンツを提供することに重点をおいています。

      +

      + 一部のGoogle検索の従業員https://twitter.com/JohnMu/status/965507331369984002によれば、国際化はSEOの最も複雑な面の1つとなっているようです。 SEOの国際化は、ユーザーが特定の言語のコンテンツをターゲットしていることを確認し、それに合わせて複数の言語や国のバージョンを持つWebサイトから適切なコンテンツを提供することに重点をおいています。 +

      HTML lang属性が英語に設定されているデスクトップ用サイトの38.40%（モバイルでは33.79%）で、別の言語バージョンへの hreflangリンクが含まれるサイトはたった7.43%（モバイルで6.79%）しかありませんでした。 これから、分析したWebサイトの殆どが言語ターゲティングを必要とするホームページの別バージョンを提供していないことを示しています。しかしそれは、個別のバージョンは存在するが構成が正しく無い場合を除きます。

      @@ -4628,126 +5189,114 @@

      国際化図 11. よく見るhreflang値のトップ25。

      英語の次に最もよく見る言語は、フランス語、スペイン語、およびドイツ語です。 この後にアメリカ人向けの英語（en-us）やアイルランド人向けのスペイン語（es-ie）などの不明瞭な組み合わせなどの、特定の地域を対象とした言語が続いています。

      -

      この分析では、異なる言語バージョン同士が相互で適切にリンクしているかどうかなどの正しい実装は確認しませんでした。 しかし、推奨にあるx-defaultバージョン（デスクトップでは3.77%、モバイルでは1.30%）の採用が少ない点を考慮すると、この要素が複雑で常に正しいとは限らないということを示しています。

      +

      + この分析では、異なる言語バージョン同士が相互で適切にリンクしているかどうかなどの正しい実装は確認しませんでした。 しかし、推奨にあるhttps://www.google.com/url?q=https://support.google.com/webmasters/answer/189077?hl%3Den&sa=D&ust=1570627963630000&usg=AFQjCNFwzwglsbysT9au_I-7ZQkwa-QvrAx-defaultバージョン（デスクトップでは3.77%、モバイルでは1.30%）の採用が少ない点を考慮すると、この要素が複雑で常に正しいとは限らないということを示しています。 +

      SPAのクロールに関する可能性

      -

      ReactやVue.jsなどのフレームワークで構築されたシングルページアプリケーション（SPA）には、独特のSEOの複雑さが伴っています。 ハッシュを使ったナビゲーションを使用するWebサイトは検索エンジンがクロールして適切にインデックスを作成するのがとても難しくなります。 例を上げると、Googleには「AJAXクロールスキーム」という回避策がありましたが、開発者だけでなく検索エンジンにとっても難解であることが判明し、この仕様は2015年に廃止されました。

      +

      + ReactやVue.jsなどのフレームワークで構築されたシングルページアプリケーション（SPA）には、独特のSEOの複雑さが伴っています。 ハッシュを使ったナビゲーションを使用するWebサイトは検索エンジンがクロールして適切にインデックスを作成するのがとても難しくなります。 例を上げると、Googleには「AJAXクロールスキーム」という回避策がありましたが、開発者だけでなく検索エンジンにとっても難解であることが判明し、この仕様は2015年に廃止https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.htmlされました。 +

      ハッシュURLを介して提供されるリンクの数が比較的少なく、Reactモバイルページの13.08%がナビゲーションにハッシュURLを使用し、モバイルVue.jsページで8.15%、モバイルAngularページで2.37%で使用されているという結果になっています。 この結果はデスクトップ用ページでも非常に似通った結果でした。 ハッシュURLからコンテンツの発見に対する影響を考慮すると、この結果はSEOの観点からは良い状態と言えるでしょう。

      -

      特に驚いた点は、ハッシュURLの数がAngularページでは少ないのとは対照的に、ReactページでのハッシュURLの数が多くなっている点です。 両方のフレームワークはハッシュURLに依存せず、代わりにリンク時にHistory APIが標準となっているルーティングパッケージの採用を推奨しています。 Vue.jsはvue-routerパッケージのバージョン3から、History APIを標準で使うことを検討しています。

      +

      + 特に驚いた点は、ハッシュURLの数がAngularページでは少ないのとは対照的に、ReactページでのハッシュURLの数が多くなっている点です。 両方のフレームワークはハッシュURLに依存せず、代わりにリンク時にHistory APIhttps://developer.mozilla.org/en-US/docs/Web/API/Historyが標準となっているルーティングパッケージの採用を推奨しています。 Vue.jsはvue-routerパッケージのバージョン3から、History APIを標準で使うことを検討https://github.com/vuejs/rfcs/pull/40しています。 +

      AMP

      -

      AMP（以前は「Accelerated Mobile Pages」として知られていました）は、2015年にGoogleによってオープンソースのHTMLフレームワークとして初めて導入されました。 キャッシュ、遅延読み込み、最適化された画像などの最適化手法を使うことで、Webサイトのサイトのコンポーネントと基盤構造を提供することで、ユーザーに高速な体験を提供します。 特に、Googleは検索エンジンにもこれを採用し、AMPページも独自のCDNから提供されています。 この機能は後にSigned HTTP Exchangesという名前の標準提案になりました。

      +

      + AMP（以前は「Accelerated Mobile Pages」として知られていました）は、2015年にGoogleによってオープンソースのHTMLフレームワークとして初めて導入されました。 キャッシュ、遅延読み込み、最適化された画像などの最適化手法を使うことで、Webサイトのサイトのコンポーネントと基盤構造を提供することで、ユーザーに高速な体験を提供します。 特に、Googleは検索エンジンにもこれを採用し、AMPページも独自のCDNから提供されています。 この機能は後にSigned HTTP Exchangeshttps://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.htmlという名前の標準提案になりました。 +

      にも関わらず、AMPバージョンへのリンクが含まれるモバイルホームページはわずか0.62%しかありません。 このプロジェクトの可視性を考慮しても、これは採用率が比較的低い事が示されています。 ただし、今回のホームページに焦点を宛てた分析なので、他のページタイプの採用率は見ていません、記事ページを配信する場合はAMPのほうが有利な場合が多いでしょう。

      セキュリティ

      -

      近年、WebがデフォルトでHTTPSに移行するという強力なオンラインの変化がありました。 HTTPSでは、例えばユーザー入力データが安全に送信されないパブリックWi-FiネットワークでもWebサイトのトラフィックが傍受されるのを防ぎます。GoogleはサイトでHTTPSを採用するよう推進しており、ランキングシグナルとしてHTTPSを作りました。Chromeはブラウザで非HTTPSページを非セキュアとしてラベル付けすることでセキュアなページへの移行もサポートしています。

      -

      HTTPSの重要性とその採用方法に関するGoogleの詳細な情報と手引については、HTTPSが重要な理由をご覧ください。

      +

      + 近年、WebがデフォルトでHTTPSに移行するという強力なオンラインの変化がありました。 HTTPSでは、例えばユーザー入力データが安全に送信されないパブリックWi-FiネットワークでもWebサイトのトラフィックが傍受されるのを防ぎます。GoogleはサイトでHTTPSを採用するよう推進しており、ランキングシグナルとしてHTTPShttps://webmasters.googleblog.com/2014/08/https-as-ranking-signal.htmlを作りました。Chromeはブラウザで非HTTPSページを非セキュアhttps://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/としてラベル付けすることでセキュアなページへの移行もサポートしています。 +

      +

      + HTTPSの重要性とその採用方法に関するGoogleの詳細な情報と手引については、HTTPSが重要な理由https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-httpsをご覧ください。 +

      現在、デスクトップ用Webサイトの67.06%がHTTPS経由で配信されています。 Webサイトの半分以下がまだHTTPSに移行しておらず、ユーザーに安全でないページを提供しています。 これはかなりの数です。 移行は大変な作業になる場合が多く、そのために採用率が高くない可能性がありますが、HTTPSの移行に必要なのは大抵の場合SSL証明書と.htaccessファイルの簡単な変更です。  HTTPSに切り替えない理由はありません。

      -

      Googleの透明性レポートでは、Google以外の上位100ドメインでhttpsの採用率は90%であると報告されています(これは世界中のWebサイトトラフィックの25%です)。 この数字と私たちの数字の違いから、比較的小規模なサイトはゆるやかにHTTPSを採用しているという事実によって説明できます。

      +

      + Googleの透明性レポートhttps://transparencyreport.google.com/https/overviewでは、Google以外の上位100ドメインでhttpsの採用率は90%であると報告されています(これは世界中のWebサイトトラフィックの25%です)。 この数字と私たちの数字の違いから、比較的小規模なサイトはゆるやかにHTTPSを採用しているという事実によって説明できます。 +

      セキュリティの状態の詳細については、セキュリティの章を御覧ください。

      結論

      分析の結果、ほとんどのWebサイトでは基礎がしっかりしている事が判明しました。ホームページはクロール可能で、インデックス付け可能で、検索エンジンの結果ページでのランキングに必要な主要コンテンツが存在しています。 Webサイトを所有する人々がSEOを熟知しているわけではなく、ベストプラクティスの指針などは言うまでもありません。つまり、これらの非常に多くのサイトが基本をカバーしていることは非常に頼もしいことです。

      しかし、SEOとアクセシビリティのより高度な面のいくつかに関しては、予想していたよりも多くのサイトが注目していません。 サイトの速度については、特にモバイルのときに多くのWebサイトが苦労している要因の一つになっており、これは大きな問題です。なぜなら速度はUXの最大の要因の1つで、ランキングに影響を与える可能性があるためです。 HTTPS経由でまだ提供されていないWebサイトの数も、セキュリティの重要性を考慮してユーザーデータを安全に保つという点に問題があるように見えます。

      私達全員がSEOのベストプラクティスを学んだり、業界の発展に貢献できることはたくさんあります。 これは、検索業界が進化する性質を持ちながら、その変化の速度から必要な事です。 検索エンジンは毎年数千のアルゴリズムを改善しています、Webサイトがオーガニックサーチでより多くの訪問者に届くようにしたい場合、置いていかれないようにする必要があります。

      -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":11,"title":"PWA","description":"Service Worker（登録、インストール可能性、イベント、およびファイルサイズ）、Webアプリマニフェストプロパティ、およびWorkboxを対象とする2019 Web AlmanacのPWAの章。","authors":["tomayac","jeffposnick"],"reviewers":["hyperpress","ahmadawais"],"translators":["ksakae"],"discuss":"1766","results":"https://docs.google.com/spreadsheets/d/19BI3RQc_vR9bUPPZfVsF_4gpFWLNT6P0pLcAdL-A56c/","queries":"11_PWA","published":"2019-11-11","last_updated":"2020-03-02","chapter":"pwa"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 11 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - PWA +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":11,"title":"PWA","description":"Service Worker（登録、インストール可能性、イベント、およびファイルサイズ）、Webアプリマニフェストプロパティ、およびWorkboxを対象とする2019 Web AlmanacのPWAの章。","authors":["tomayac","jeffposnick"],"reviewers":["hyperpress","ahmadawais"],"translators":["ksakae"],"discuss":"1766","results":"https://docs.google.com/spreadsheets/d/19BI3RQc_vR9bUPPZfVsF_4gpFWLNT6P0pLcAdL-A56c/","queries":"11_PWA","published":"2019-11-11","last_updated":"2020-03-02","chapter":"pwa"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -4756,16 +5305,28 @@

    - + -
    {{ self.written_by_before() }} Tom Steiner, {{ self.and() }} Jeff Posnick{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} John Teague, {{ self.and() }} Ahmad Awais{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    -

    プログレッシブWebアプリ（PWA）は、Service Worker APIなどのプラットフォームプリミティブ上に構築される新しいクラスのWebアプリケーションです。Service Workerは、ネットワークプロキシとして機能し、Webアプリの発信要求をインターセプトしプログラムまたはキャッシュされた内容で応答することによりアプリがネットワークに依存しない読み込みをサポートできるようにします。Service Workerは、プッシュ通知を受信し、対応するアプリが実行されていなくてもバックグラウンドでデータを同期できます。さらに、Service Workerは、Webアプリマニフェストと共にユーザーがデバイスのホーム画面にPWAをインストールできるようにします。

    -

    Service Workerは2014年12月にChrome 40で初めて実装され、プログレッシブWebアプリという用語は2015年にFrances BerrimanとAlex Russellによって作られました。Service Workerはすべての主要なブラウザでようやく実装されたため、この章の目標は実際に存在するPWAの数と、これらの新しいテクノロジーをどのように利用するかを決定します。バックグラウンド同期のような特定の高度なAPIは、現在もChromiumベースのブラウザでのみ利用できるため、追加の質問として、これらのPWAが実際に使用する機能を調べました。

    +

    + プログレッシブWebアプリ（PWA）は、Service Worker APIhttps://developer.mozilla.org/en/docs/Web/API/Service_Worker_APIなどのプラットフォームプリミティブ上に構築される新しいクラスのWebアプリケーションです。Service Workerは、ネットワークプロキシとして機能し、Webアプリの発信要求をインターセプトしプログラムまたはキャッシュされた内容で応答することによりアプリがネットワークに依存しない読み込みをサポートできるようにします。Service Workerは、プッシュ通知を受信し、対応するアプリが実行されていなくてもバックグラウンドでデータを同期できます。さらに、Service Workerは、Webアプリマニフェストhttps://developer.mozilla.org/en-US/docs/Web/Manifestと共にユーザーがデバイスのホーム画面にPWAをインストールできるようにします。 +

    +

    + Service Workerは2014年12月にChrome 40で初めて実装https://blog.chromium.org/2014/12/chrome-40-beta-powerful-offline-and.htmlされ、プログレッシブWebアプリという用語は2015年にFrances BerrimanとAlex Russellによって作られましたhttps://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/。Service Workerはすべての主要なブラウザでようやく実装されたため、この章の目標は実際に存在するPWAの数と、これらの新しいテクノロジーをどのように利用するかを決定します。バックグラウンド同期https://caniuse.com/#feat=background-syncのような特定の高度なAPIは、現在もChromiumベースのブラウザでのみ利用できるため、追加の質問として、これらのPWAが実際に使用する機能を調べました。 +

    Service Worker

    Service Workerの登録とインストール可能性

    @@ -4775,22 +5336,37 @@

    - 図2.デスクトップおよびモバイルのService Workerの経時的なインストール。 + 図2.デスクトップおよびモバイルのService Workerの経時的なインストール。
    図 2.デスクトップおよびモバイルのService Workerの経時的なインストール。

    -

    これはあまり印象的でないかもしれませんが、Chromeプラットフォームステータスからのトラフィックデータを考慮すると、Service Workerがすべてのページロードの約15％を制御していることがわかります。トラフィックの多いサイトがますますService Workerを受け入れ始めています。

    +

    + これはあまり印象的でないかもしれませんが、Chromeプラットフォームステータスからのトラフィックデータを考慮すると、Service Workerがすべてのページロードの約15％https://www.chromestatus.com/metrics/feature/timeline/popularity/990を制御していることがわかります。トラフィックの多いサイトがますますService Workerを受け入れ始めています。 +

    15%
    -
    図 3.Service Workerを登録するページのページビューの割合。 （出典：Chromeプラットフォームステータス） (出典: Chromeプラットフォームステータス)
    +
    + 図 3.Service Workerを登録するページのページビューの割合。 （出典：Chromeプラットフォームステータス） (出典: Chromeプラットフォームステータスhttps://www.chromestatus.com/metrics/feature/timeline/popularity/990) +
    -

    Lighthouseは、ページがインストールプロンプトの対象かどうかを確認します。モバイルページの1.56％にインストール可能なマニフェストがあります。

    - インストール体験をコントロールするために、全デスクトップの0.82％と全モバイルページの0.94％がOnBeforeInstallPromptインターフェイスを使用します。現在、サポートはChromiumベースのブラウザに限定されています。 + Lighthouseは、ページがインストールプロンプトhttps://developers.google.com/web/tools/lighthouse/audits/install-promptの対象かどうかを確認します。モバイルページの1.56％にインストール可能なマニフェストhttps://web.dev/installable-manifest/があります。 +

    +

    + インストール体験をコントロールするために、全デスクトップの0.82％と全モバイルページの0.94％がOnBeforeInstallPromptインターフェイスhttps://w3c.github.io/manifest/#beforeinstallpromptevent-interfaceを使用します。現在、サポートはChromiumベースのブラウザに限定されていますhttps://caniuse.com/#feat=web-app-manifest。

    Service Workerイベント

    -

    Service Workerでは、いくつかのイベントをリッスンできます。

    +

    + Service Workerでは、いくつかのイベントをリッスンできますhttps://developers.google.com/web/fundamentals/primers/service-workers/lifecycle。 +

    • install, Service Workerのインストール時に発生します。
    • activate, Service Workerのアクティベーション時に発生します。
      • @@ -4803,7 +5379,7 @@

      - 図4. Service Workerイベントの人気。 + 図4. Service Workerイベントの人気。
      図 4. Service Workerイベントの人気。
      @@ -4813,19 +5389,22 @@

      - 図5. Service Workerの転送サイズの分布。 + 図5. Service Workerの転送サイズの分布。
      図 5. Service Workerの転送サイズの分布。

      - デスクトップのService Workerファイルの中央値は895バイトですが、モバイルでは694バイトです。すべてのパーセンタイルを通じて、デスクトップService WorkerはモバイルService Workerよりも大きくなっています。これらの統計は、importScripts()importScripts()https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScriptsメソッドを使用して動的にインポートされたスクリプトを考慮しないため、結果は大きく歪む可能性が高いことに注意してください。

      Webアプリマニフェスト

      Webアプリマニフェストのプロパティ

      Webアプリマニフェストは、ブラウザーにWebアプリケーションと、ユーザーのモバイルデバイスまたはデスクトップにインストールされたときの動作を通知する単純なJSONファイルです。典型的なマニフェストファイルには、アプリ名、使用するアイコン、起動時に開く開始URLなどに関する情報が含まれています。検出されたすべてのマニフェストの1.54％のみが無効なJSONであり、残りは正しく解析されました。

      -

      Web App Manifest仕様で定義されているさまざまなプロパティを調べ、非標準の独自プロパティも検討しました。仕様によると、次のプロパティが許可されています。

      +

      + Web App Manifest仕様https://w3c.github.io/manifest/#webappmanifest-dictionaryで定義されているさまざまなプロパティを調べ、非標準の独自プロパティも検討しました。仕様によると、次のプロパティが許可されています。 +

      • dir
      • lang
        • @@ -4849,7 +5428,7 @@

        - 図6. Webアプリマニフェストプロパティの人気。 + 図6. Webアプリマニフェストプロパティの人気。
        図 6. Webアプリマニフェストプロパティの人気。
        @@ -4859,7 +5438,7 @@

        - 図7. Webアプリマニフェストのdisplayプロパティの使用法。 + 図7. Webアプリマニフェストのdisplayプロパティの使用法。
        図 7. Webアプリマニフェストのdisplayプロパティの使用法。
        @@ -4869,24 +5448,33 @@

        Category

        categoriesプロパティは、Webアプリケーションが属する予想されるアプリケーションカテゴリを記述します。これは、Webアプリケーションをリストするカタログまたはアプリストアへのヒントとしてのみ意図されており、Webサイトは1つ以上の適切なカテゴリに自分自身をリストするために最善を尽くすことが期待されます。

        - 図8.上位のWebアプリマニフェストカテゴリ。 + 図8.上位のWebアプリマニフェストカテゴリ。
        図 8.上位のWebアプリマニフェストカテゴリ。

        このプロパティを利用したマニフェストはあまり多くありませんでしたが、モバイルで最も人気のあるカテゴリである「ショッピング」から「ビジネス」「テクノロジー」、そして最初の場所を均等に共有するデスクトップ上の「ウェブ」（それが意味するものは何でも）。

        アイコンのサイズ

        -

        Lighthouseには少なくとも192X192ピクセルのサイズのアイコンが必要ですが、一般的なファビコン生成ツールは他のサイズのアイコンも大量に作成します。

        +

        + Lighthouseには少なくとも192X192ピクセルのサイズのアイコンが必要https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-192px-iconですが、一般的なファビコン生成ツールは他のサイズのアイコンも大量に作成します。 +

        - 図9.上位のWebアプリマニフェストアイコンのサイズ。 + 図9.上位のWebアプリマニフェストアイコンのサイズ。
        図 9.上位のWebアプリマニフェストアイコンのサイズ。
        -

        Lighthouseのルールが、おそらくアイコンサイズ選択の犯人で、192ピクセルがデスクトップとモバイルの両方で最も人気があります。Googleのドキュメントで512X512を明示的に推奨していますが、これは特に目立つオプションとしては表示されてません。

        +

        + Lighthouseのルールが、おそらくアイコンサイズ選択の犯人で、192ピクセルがデスクトップとモバイルの両方で最も人気があります。Googleのドキュメントhttps://developers.google.com/web/fundamentals/web-app-manifest#iconsで512X512を明示的に推奨していますが、これは特に目立つオプションとしては表示されてません。 +

        Orientation値

        -

        orientationプロパティの有効な値は、画面方向API仕様で定義されています。現在、それらは次のとおりです。

        +

        + orientationプロパティの有効な値は、画面方向API仕様https://www.w3.org/TR/screen-orientation/#dom-orientationlocktypeで定義されています。現在、それらは次のとおりです。 +

        • "any"
        • "natural"
          • @@ -4899,100 +5487,101 @@

          Or

        - 図10.上位のWebアプリマニフェストのOrientation値。 + 図10.上位のWebアプリマニフェストのOrientation値。
        図 10.上位のWebアプリマニフェストのOrientation値。

        「portrait」オリエンテーションは両方のプラットフォームで明確な勝者であり、「any」オリエンテーションがそれに続きます。

        Workbox

        -

        Workboxは、一般的なService Workerのユースケースを支援する一連のライブラリです。たとえばWorkboxには、ビルドプロセスにプラグインしてファイルのマニフェストを生成できるツールがあり、Service Workerによって事前にキャッシュされます。 Workboxには、ランタイムキャッシング、リクエストルーティング、キャッシュの有効期限、バックグラウンド同期などを処理するライブラリが含まれています。

        - Service Worker APIの低レベルの性質を考慮すると、多くの開発者は、Service Workerロジックをより高レベルで再利用可能なコードの塊に構造化する方法としてWorkboxに注目しています。 Workboxの採用は、create-react-appやVueのPWAプラグインなど、多くの一般的なJavaScriptフレームワークスターターキットの機能として含まれることによっても促進されます。 + Workboxhttps://developers.google.com/web/tools/workboxは、一般的なService Workerのユースケースを支援する一連のライブラリです。たとえばWorkboxには、ビルドプロセスにプラグインしてファイルのマニフェストを生成できるツールがあり、Service Workerによって事前にキャッシュされます。 Workboxには、ランタイムキャッシング、リクエストルーティング、キャッシュの有効期限、バックグラウンド同期などを処理するライブラリが含まれています。 +

        +

        + Service Worker APIの低レベルの性質を考慮すると、多くの開発者は、Service Workerロジックをより高レベルで再利用可能なコードの塊に構造化する方法としてWorkboxに注目しています。 Workboxの採用は、create-react-apphttps://create-react-app.dev/やVueのPWAプラグインhttps://www.npmjs.com/package/@vue/cli-plugin-pwaなど、多くの一般的なJavaScriptフレームワークスターターキットの機能として含まれることによっても促進されます。

        HTTP Archiveは、Service Workerを登録するWebサイトの12.71％が少なくとも1つのWorkboxライブラリを使用していることを示しています。この割合は、デスクトップ（14.36％）と比較してモバイルではわずかに低い割合（11.46％）で、デスクトップとモバイルでほぼ一貫しています。

        結論

        この章の統計は、PWAがまだごく一部のサイトでしか使用されていないことを示しています。ただし、この比較的少ない使用量はトラフィックのシェアがはるかに大きい人気のあるサイトによってもたらされ、ホームページ以外のページはこれをさらに使用する可能性があります。ページのロードの15％がService Workerを使用することがわかりました。特にモバイル向けのパフォーマンスとキャッシングのより優れた制御に与える利点は、使用が増え続けることを意味するはずです。

        -

        PWAは、Chrome主導のテクノロジーと見なされることがよくあります。一部のプラットフォームでは一流のインストール可能性が遅れているものの、他のブラウザは、基盤となるテクノロジーのほとんどを実装するために最近大きく進歩しました。サポートがさらに普及するのを前向きに見る事ができます。 Maximiliano Firtmanは、Safari PWAサポートの説明など、iOSでこれを追跡する素晴らしい仕事をしています。 AppleはPWAという用語をあまり使用せず、HTML5アプリはApp Storeの外部に最適配信されると明示的に述べています。Microsoftは逆の方向に進み、アプリストアでPWAを奨励するだけでなく、Bing Webクローラーを介して検出されたPWAを自動的にショートリストに追加しました。 Googleは、信頼できるWebアクティビティを介して、Google PlayストアにWebアプリをリストする方法も提供しています。

        +

        + PWAは、Chrome主導のテクノロジーと見なされることがよくあります。一部のプラットフォームでは一流のインストール可能性が遅れているものの、他のブラウザは、基盤となるテクノロジーのほとんどを実装するために最近大きく進歩しました。サポートがさらに普及するのを前向きに見る事ができます。 Maximiliano Firtmanhttps://twitter.com/firtは、Safari PWAサポートの説明https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49など、iOSでこれを追跡する素晴らしい仕事をしています。 AppleはPWAという用語をあまり使用せず、HTML5アプリはApp Storeの外部に最適配信されると明示的に述べていますhttps://developer.apple.com/news/?id=09062019b。Microsoftは逆の方向に進み、アプリストアでPWAを奨励するだけでなく、Bing Webクローラーを介して検出されたPWAを自動的にショートリストに追加しましたhttps://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store。 Googleは、信頼できるWebアクティビティhttps://developers.google.com/web/updates/2019/02/using-twaを介して、Google PlayストアにWebアプリをリストする方法も提供しています。 +

        PWAは、ネイティブプラットフォームやアプリストアではなくWeb上でビルドおよびリリースすることを希望する開発者に道を提供します。すべてのOSとブラウザがネイティブソフトウェアと完全に同等であるとは限りませんが、改善は継続され、おそらく2020年は展開が爆発的に増加する年になるでしょうか？

        -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"II","chapter_number":12,"title":"モバイルウェブ","description":"2019年Web AlmanacのモバイルWebの章では、ページの読み込み、テキストコンテンツ、拡大縮小、ボタンやリンク、フォームへの記入のしやすさなどをカバーしています。","authors":["obto"],"reviewers":["AymenLoukil","hyperpress"],"translators":["ksakae"],"discuss":"1767","results":"https://docs.google.com/spreadsheets/d/1dPBDeHigqx9FVaqzfq7CYTz4KjllkMTkfq4DG4utE_g/","queries":"12_Mobile_Web","published":"2019-11-11","last_updated":"2020-05-20","chapter":"mobile-web"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} II {{ self.chapter() }} 12 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - モバイルウェブ +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"II","chapter_number":12,"title":"モバイルウェブ","description":"2019年Web AlmanacのモバイルWebの章では、ページの読み込み、テキストコンテンツ、拡大縮小、ボタンやリンク、フォームへの記入のしやすさなどをカバーしています。","authors":["obto"],"reviewers":["AymenLoukil","hyperpress"],"translators":["ksakae"],"discuss":"1767","results":"https://docs.google.com/spreadsheets/d/1dPBDeHigqx9FVaqzfq7CYTz4KjllkMTkfq4DG4utE_g/","queries":"12_Mobile_Web","published":"2019-11-11","last_updated":"2020-05-20","chapter":"mobile-web"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -5001,20 +5590,33 @@

    - + -
    {{ self.written_by_before() }} David Fox{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Aymen Loukil, {{ self.and() }} John Teague{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章Introduction

    2007年に少し戻ってみましょう。「モバイルウェブ」は現在、レーダー上ではほんの一瞬の出来事に過ぎませんが、それには正当な理由があります。なぜでしょうか？　モバイルブラウザはCSSをほとんどサポートしていないため、サイトの見た目がデスクトップとは全く異なります。画面は信じられないほど小さく、一度に数行のテキストしか表示できません。また、マウスの代わりとなるのは、「タブを使って移動する」ための小さな矢印キーです。言うまでもなく、携帯電話でウェブを閲覧することは本当に愛の労働です。 しかし、このすべてをちょうど変更しようとしている。

    プレゼンの途中、スティーブ・ジョブズは発表されたばかりのiPhoneを手にして座り、それまで夢見ていた方法でウェブサーフィンを始めます。大きな画面とフル機能のブラウザで、ウェブサイトをフルに表示します。そして最も重要なことは、人間に知られている最も直感的なポインターデバイスを使ってウェブサーフィンをすることです：私たちの指。小さな矢印キーを使って、これ以上のタブ操作はありません。

    -

    2007年以降、モバイルウェブは爆発的な成長を遂げました。そして13年後の現在、2019年7月のAkamai mPulseのデータによると、モバイルは全検索の 59%と全ウェブトラフィックの58.7％を占めています。モバイルはもはや余計なものでなく、人々がウェブを体験する主要な方法となっています。モバイルの重要性を考えると、私たちは訪問者にどのような体験を提供しているのでしょうか？　どこが不足しているのか？　それを探ってみましょう。

    +

    + 2007年以降、モバイルウェブは爆発的な成長を遂げました。そして13年後の現在、2019年7月のAkamai mPulsehttps://developer.akamai.com/akamai-mpulse-real-user-monitoring-solutionのデータによると、モバイルは全検索の 59%https://www.merkleinc.com/thought-leadership/digital-marketing-reportと全ウェブトラフィックの58.7％を占めています。モバイルはもはや余計なものでなく、人々がウェブを体験する主要な方法となっています。モバイルの重要性を考えると、私たちは訪問者にどのような体験を提供しているのでしょうか？　どこが不足しているのか？　それを探ってみましょう。 +

    ページの読み込み体験

    私たちが分析したモバイルウェブ体験の最初の部分は、私たちが最も身近に感じているものです。ページの読み込み体験です。しかし、今回の調査結果へ飛び込む前に、典型的なモバイルユーザーが実際にどのようなユーザーであるかについて全員が同じ見解を持っていることを確認しておきましょう。これは、これらの結果を再現するのに役立つだけでなく、これらのユーザーをよりよく理解することにもつながるからです。

    -

    まずは、典型的なモバイルユーザーがどのような電話を持っているかから始めましょう。平均的なAndroid携帯電話価格は～250ドルで、その範囲内の最も人気のある携帯電話の1つは、サムスンのギャラクシーS6です。だから、これはおそらく典型的なモバイルユーザーが使用している携帯電話の種類であり、実際にはiPhone 8よりも4倍遅いです。このユーザーは、高速な4G接続へのアクセス権を持っていませんが、むしろ2G接続（29%時間の）または3G接続（28%時間の）を使用しています。そして、これが全ての足し算になります。

    +

    + まずは、典型的なモバイルユーザーがどのような電話を持っているかから始めましょう。平均的なAndroid携帯電話価格は～250ドルhttps://web.archive.org/web/20190921115844/https://www.idc.com/getdoc.jsp?containerId=prUS45115119で、その範囲内の最も人気のある携帯電話https://web.archive.org/web/20190812221233/https://deviceatlas.com/blog/most-popular-android-smartphonesの1つは、サムスンのギャラクシーS6です。だから、これはおそらく典型的なモバイルユーザーが使用している携帯電話の種類であり、実際にはiPhone 8よりも4倍遅いです。このユーザーは、高速な4G接続へのアクセス権を持っていませんが、むしろ2G接続（29%https://www.gsma.com/r/mobileeconomy/時間の）または3G接続（28%https://www.gsma.com/r/mobileeconomy/時間の）を使用しています。そして、これが全ての足し算になります。 +

    @@ -5022,7 +5624,9 @@

    2G or 3G + + 2G or 3Ghttps://www.gsma.com/r/mobileeconomy/ + Latency @@ -5034,7 +5638,9 @@

    Galaxy S6 — 4x slower than iPhone 8 (Octane V2 score) + + Galaxy S6https://www.gsmarena.com/samsung_galaxy_s6-6849.php — 4x slowerhttps://www.notebookcheck.net/A11-Bionic-vs-7420-Octa_9250_6662.247596.0.html than iPhone 8 (Octane V2 score) + @@ -5044,17 +5650,26 @@

    JavaScriptで肥大化したページ

    -

    モバイルウェブのJavaScriptの状態が恐ろしい。HTTP Archiveの JavaScript レポートによると、モバイルサイトの中央値では、携帯電話が375KBのJavaScriptをダウンロードする必要があります。圧縮率を70％と仮定すると、携帯電話は中央値で1.25MBのJavaScriptを解析、コンパイル、実行しなければならないことになります。

    -

    なぜこれが問題なのでしょうか？　なぜなら、これだけの量のJSをロードしているサイトは、一貫してインタラクティブになるまで10秒以上かかるからです。言い換えればページは完全に読み込まれているように見えるかもしれませんが、ユーザーがボタンやメニューをクリックするとJavaScriptの実行が終了していないために、ユーザーは多少の速度低下を経験するかもしれません。最悪の場合、ユーザーは10秒以上ボタンをクリックし続けなければならず、何かが実際に起こる魔法のような瞬間を待つことになります。それがどれほど混乱し、イライラさせるかを考えてみてください。

    +

    + モバイルウェブのJavaScriptの状態が恐ろしい。HTTP Archiveの JavaScript レポートhttps://httparchive.org/reports/state-of-javascript?start=2016_05_15&end=2019_07_01&view=list#bytesJsによると、モバイルサイトの中央値では、携帯電話が375KBのJavaScriptをダウンロードする必要があります。圧縮率を70％と仮定すると、携帯電話は中央値で1.25MBのJavaScriptを解析、コンパイル、実行しなければならないことになります。 +

    +

    + なぜこれが問題なのでしょうか？　なぜなら、これだけの量のJSをロードしているサイトは、一貫してインタラクティブになるまで10秒https://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci以上かかるからです。言い換えればページは完全に読み込まれているように見えるかもしれませんが、ユーザーがボタンやメニューをクリックするとJavaScriptの実行が終了していないために、ユーザーは多少の速度低下を経験するかもしれません。最悪の場合、ユーザーは10秒以上ボタンをクリックし続けなければならず、何かが実際に起こる魔法のような瞬間を待つことになります。それがどれほど混乱し、イライラさせるかを考えてみてください。 +

    - + - 図2. JS がロードされるのを待つのがいかに苦痛であるかの例。 + 図2. JS がロードされるのを待つのがいかに苦痛であるかの例。
    図 2. JS がロードされるのを待つのがいかに苦痛であるかの例。
    -

    さらに深く掘り下げて、各ページがJavaScriptをどの程度利用しているかに焦点を当てた別の指標を見てみましょう。例えば、読み込み中のページは本当に多くのJavaScriptを必要としているのでしょうか？　私たちはこの指標をWeb bloat scoreに基づいたJavaScript Bloat Scoreと呼んでいます。その背後にある考え方は次のようなものです。

    +

    + さらに深く掘り下げて、各ページがJavaScriptをどの程度利用しているかに焦点を当てた別の指標を見てみましょう。例えば、読み込み中のページは本当に多くのJavaScriptを必要としているのでしょうか？　私たちはこの指標をWeb bloat scorehttps://www.webbloatscore.com/に基づいたJavaScript Bloat Scoreと呼んでいます。その背後にある考え方は次のようなものです。 +

    • JavaScriptは、ページの読み込みに合わせて生成と変更の両方を行うためによく使われます。
    • また、ブラウザにテキストとして配信されます。そのため、よく圧縮され、ただのページのスクリーンショットよりも速く配信されるはずです。
      • @@ -5063,25 +5678,36 @@

      *JavaScript Bloat Score*は以下のように定義されています。(JavaScriptの総サイズ)/(ビューポートのPNGスクリーンショットのサイズ)で定義されます。1.0より大きい数値は、スクリーンショットを送信するのが速いことを意味します。

      その結果は？　分析した500万以上のウェブサイトのうち75.52％がJavaScriptで肥大化していました。まだまだ先は長いですね。

      分析した500万以上のサイトすべてのスクリーンショットをキャプチャして測定できなかったことに注意してください。代わりに、1000のサイトからランダムにサンプリングして、ビューポートのスクリーンショットサイズの中央値（140KB）を見つけ各サイトのJavaScriptダウンロードサイズをこの数値と比較しました。

      -

      JavaScriptの効果をもっと詳しく知りたい方は、Addy OsmaniのThe Cost of JavaScript in 2018をチェックしてみてください。

      +

      + JavaScriptの効果をもっと詳しく知りたい方は、Addy OsmaniのThe Cost of JavaScript in 2018https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4をチェックしてみてください。 +

      サービスワーカーの使い方

      -

      ブラウザは通常、すべてのページを同じように読み込みます。いくつかのリソースのダウンロードを他のリソースよりも優先したり、同じキャッシュルールに従ったりします。サービスワーカーのおかげで、リソースがネットワーク層によってどのように処理されるかを直接制御できるようになりました。

      +

      + ブラウザは通常、すべてのページを同じように読み込みます。いくつかのリソースのダウンロードを他のリソースよりも優先したり、同じキャッシュルールに従ったりします。サービスワーカーhttps://developers.google.com/web/fundamentals/primers/service-workersのおかげで、リソースがネットワーク層によってどのように処理されるかを直接制御できるようになりました。 +

      2016年から利用可能になり、すべての主要ブラウザに実装されているにもかかわらず、利用しているサイトはわずか0.64％にとどまっています!

      読み込み中にコンテンツを移動する

      ウェブの最も美しい部分の1つは、ウェブページのロードが自然と進んでいくことです。ブラウザはできる限り早くコンテンツをダウンロードして表示するため、ユーザーはできるだけ早くあなたのコンテンツに引き込む事ができます。しかし、このことを念頭に置いてサイトを設計しないと、悪影響を及ぼす可能性があります。具体的には、リソースのロードに合わせてコンテンツの位置がずれることで、ユーザー体験の妨げになることがあります。

      - 図3. シフト内容が読者の気を散らす例 CLS合計42.59％。画像提供：LookZook + 図3. シフト内容が読者の気を散らす例 CLS合計42.59％。画像提供：LookZook
      図 3. シフト内容が読者の気を散らす例 CLS合計42.59％。画像提供：LookZook

      あなたが記事を読んでいるときに突然、画像が読み込まれ、読んでいるテキストが画面の下に押し出されたと想像してみてください。あなたは今、あなたがいた場所を探すか、ちょうど記事を読むことをあきらめなければなりません。または、おそらくさらに悪いことに、同じ場所に広告がロードされる直前にリンクをクリックし始め、代わりに広告を誤ってクリックしてしまうことになります。

      -

      では、どのようにしてサイトの移動量を測定するのでしょうか？　以前はかなり困難でしたが（不可能ではないにしても）、新しい レイアウトの不安定性API のおかげで、2ステップで測定を行うことができます。

      +

      + では、どのようにしてサイトの移動量を測定するのでしょうか？　以前はかなり困難でしたが（不可能ではないにしても）、新しい レイアウトの不安定性APIhttps://web.dev/layout-instability-api のおかげで、2ステップで測定を行うことができます。 +

      1. レイアウトの不安定性APIを使用して、各シフトがページに与える影響を追跡します。これは、ビューポート内のコンテンツがどれだけ移動したかのパーセンテージとして報告されます。

      2. -

        あなたが追跡したすべてのシフトを取り、それらを一緒に追加します。その結果が 累積レイアウトシフト(CLS)スコアと呼ばれるものです。

        +

        + あなたが追跡したすべてのシフトを取り、それらを一緒に追加します。その結果が 累積レイアウトシフトhttps://web.dev/layout-instability-api#a-cumulative-layout-shift-score(CLS)スコアと呼ばれるものです。 +

      訪問者ごとに異なるCLSを持つことができるため、Chrome UX Report (./methodology#chrome-UX-report)(CrUX)を使用してウェブ全体でこのメトリックを分析するために、すべての体験を3つの異なるバケットにまとめています。

      @@ -5103,16 +5729,25 @@

      テキストの内容

      ウェブページの第一の目標は、ユーザーが興味を持ってくれるコンテンツを配信することです。このコンテンツは、YouTubeのビデオや画像の詰め合わせかもしれませんが、多くの場合、ページ上のテキストだけかもしれません。テキストコンテンツが訪問者にとって読みやすいものであることが非常に重要であることは言うまでもありません。なぜなら、訪問者が読めなければ何も残っておらず、離脱してしまうからです。テキストが読みやすいかどうかを確認するには、色のコントラストとフォントサイズの2つが重要です。

      カラーコントラスト

      -

      サイトをデザインするとき、私たちは最適な状態で、多くの訪問者よりもはるかに優れた目を持っている傾向があります。訪問者は色盲で、テキストと背景色の区別をできない場合があります。ヨーロッパ系の人は、男性の12人に1人、女性の200人に1人が色盲です。あるいは、太陽の光が画面にまぶしさを与えている間にページを読んでいる可能性があり、同様に読みやすさが損なわれている可能性があります。

      -

      この問題を軽減するために、テキストや背景色を選択する際に従うことのできるアクセシビリティ・ガイドラインがあります。では、これらの基準を満たすにはどうすればよいのでしょうか？　すべてのテキストに十分な色のコントラストを与えているサイトは22.04％にすぎません。この値は実際には下限値であり、背景が無地のテキストのみを分析したためです。画像やグラデーションの背景は分析できませんでした。

      +

      + サイトをデザインするとき、私たちは最適な状態で、多くの訪問者よりもはるかに優れた目を持っている傾向があります。訪問者は色盲で、テキストと背景色の区別をできない場合があります。ヨーロッパ系の人は、男性の12人に1人、女性の200人に1人http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdfが色盲です。あるいは、太陽の光が画面にまぶしさを与えている間にページを読んでいる可能性があり、同様に読みやすさが損なわれている可能性があります。 +

      +

      + この問題を軽減するために、テキストや背景色を選択する際に従うことのできるアクセシビリティ・ガイドラインhttps://dequeuniversity.com/rules/axe/2.2/color-contrastがあります。では、これらの基準を満たすにはどうすればよいのでしょうか？　すべてのテキストに十分な色のコントラストを与えているサイトは22.04％にすぎません。この値は実際には下限値であり、背景が無地のテキストのみを分析したためです。画像やグラデーションの背景は分析できませんでした。 +

      - 図4. 色のコントラストが不十分なテキストがどのように見えるかの例。提供：LookZook + 図4. 色のコントラストが不十分なテキストがどのように見えるかの例。提供：LookZook
      図 4. 色のコントラストが不十分なテキストがどのように見えるかの例。提供：LookZook
      -

      他の人口統計における色覚異常の統計については、本論文を参照してください。

      +

      + 他の人口統計における色覚異常の統計については、本論文https://web.archive.org/web/20180304115406/http://www.allpsych.uni-giessen.de/karl/colbook/sharpe.pdfを参照してください。 +

      フォントサイズ

      読みやすさの第二の部分は、テキストを読みやすい大きさにすることです。これはすべてのユーザーにとって重要ですが、特に年齢層の高いユーザーにとっては重要です。フォントサイズが12px未満では読みにくくなる傾向があります。

      ウェブ上では、80.66％のウェブページがこの基準を満たしていることがわかりました。

      @@ -5131,21 +5766,27 @@

      - 図5. ズーム/スケーリングを有効または無効にしているデスクトップおよびモバイルのウェブサイトの割合。 + 図5. ズーム/スケーリングを有効または無効にしているデスクトップおよびモバイルのウェブサイトの割合。
      図 5. ズーム/スケーリングを有効または無効にしているデスクトップおよびモバイルのウェブサイトの割合。

    -

    しかし開発者はこれを悪用しすぎて、3つのサイトのほぼ1つ(32.21％)がこの機能を無効にしており、Appleは(iOS 10の時点で)ウェブ開発者がズームを無効にすることを許さなくなっています。モバイルSafariは単にタグを無視する。世界中のウェブトラフィックの11%以上を占める新しいアップルのデバイスでは、どんなサイトでもズームや拡大縮小が可能です。

    +

    + しかし開発者はこれを悪用しすぎて、3つのサイトのほぼ1つ(32.21％)がこの機能を無効にしており、Appleは(iOS 10の時点で)ウェブ開発者がズームを無効にすることを許さなくなっています。モバイルSafariは単にタグを無視するhttps://archive.org/details/ios-10-beta-release-notes。世界中のウェブトラフィックの11%https://gs.statcounter.com/以上を占める新しいアップルのデバイスでは、どんなサイトでもズームや拡大縮小が可能です。 +

    ページの回転

    モバイルデバイスでは、ユーザーが回転できるので、あなたのウェブサイトをユーザーが好む形式で閲覧できます。ただし、ユーザーはセッション中に常に同じ向きを保つわけではありません。フォームに記入するとき、ユーザーはより大きなキーボードを使用するため横向きに回転できます。また、製品を閲覧しているときには、横向きモードの方が大きい製品画像を好む人もいるでしょう。このようなユースケースがあるため、モバイルデバイスに内蔵されているこの機能をユーザーから奪わないことが非常に重要です。そして良いニュースは、この機能を無効にしているサイトは事実上見当たらないということです。この機能を無効にしているサイトは全体の87サイト（または0.0016％）のみです。これは素晴らしいことです。

    ボタンとリンク

    タップターゲット

    デスクトップではマウスのような精密なデバイスを使うことに慣れていますが、モバイルでは全く違います。モバイルでは、私たちは指と呼ばれる大きくて不正確なツールを使ってサイトにアクセスします。その不正確さゆえに、私たちは常にリンクやボタンを「タップミス」して、意図していないものをタップしています。

    -

    この問題を軽減するためにタップターゲットを適切に設計することは、指の大きさが大きく異なるために困難な場合があります。しかし現在では多くの研究が行われており、どの程度の大きさのボタンが必要で、どの程度の間隔で離す必要があるかについては安全な基準 があります。

    +

    + この問題を軽減するためにタップターゲットを適切に設計することは、指の大きさが大きく異なるために困難な場合があります。しかし現在では多くの研究が行われており、どの程度の大きさのボタンが必要で、どの程度の間隔で離す必要があるかについては安全な基準https://developers.google.com/web/tools/lighthouse/audits/tap-targets があります。 +

    - 図6. タップターゲットのサイズと間隔の基準。画像提供：LookZook + 図6. タップターゲットのサイズと間隔の基準。画像提供：LookZook
    図 6. タップターゲットのサイズと間隔の基準。画像提供：LookZook
    @@ -5159,7 +5800,10 @@

    新しい入力タイプ

    過去に、デスクトップではtextとpasswordがほとんどすべてのニーズを満たしていたため、開発者が利用できる入力タイプはtextとpasswordだけでした。しかし、モバイルデバイスではそうではありません。モバイルキーボードは信じられないほど小さく、電子メールのアドレスを入力するような単純な作業では、ユーザーは複数のキーボードを切り替える必要があります。電話番号を入力するだけの単純な作業では、デフォルトのキーボードの小さな数字を使うのは難しいかもしれません。

    -

    その後、多くの新しい入力タイプが導入され、開発者はどのようなデータが期待されるかをブラウザに知らせ、ブラウザはこれらの入力タイプに特化したカスタマイズされたキーボードを提供できるようになりました。例えば、emailのタイプは"@"記号を含む英数字キーボードをユーザに提供し、telのタイプはテンキーを表示します。

    +

    + その後、多くの新しい入力タイプhttps://developer.mozilla.org/ja/docs/Web/HTML/Element/Inputが導入され、開発者はどのようなデータが期待されるかをブラウザに知らせ、ブラウザはこれらの入力タイプに特化したカスタマイズされたキーボードを提供できるようになりました。例えば、emailのタイプは"@"記号を含む英数字キーボードをユーザに提供し、telのタイプはテンキーを表示します。 +

    メール入力を含むサイトを分析する際には、56.42％がtype="email"を使用している。同様に、電話入力では、type="tel"が36.7％の割合で使用されています。その他の新しい入力タイプの採用率はさらに低い。

    @@ -5191,7 +5835,7 @@

    入力のオートコンプリートを有効にする

    - 入力属性autocomplete は、ユーザーがワンクリックでフォームフィールドへ記入できるようにします。ユーザーは膨大な数のフォームに記入しますが、毎回全く同じ情報を記入することがよくあります。このことに気付いたブラウザは、この情報を安全に保存し、将来のページで使用できるようにし始めました。開発者がすべきことは、このautocomplete属性を使用してどの情報を正確に入力する必要があるかをブラウザに伝えるだけで、あとはブラウザが行います。 + 入力属性autocompletehttps://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete は、ユーザーがワンクリックでフォームフィールドへ記入できるようにします。ユーザーは膨大な数のフォームに記入しますが、毎回全く同じ情報を記入することがよくあります。このことに気付いたブラウザは、この情報を安全に保存し、将来のページで使用できるようにし始めました。開発者がすべきことは、このautocomplete属性を使用してどの情報を正確に入力する必要があるかをブラウザに伝えるだけで、あとはブラウザが行います。

    29.62%
    @@ -5207,76 +5851,112 @@

    結

    モバイルウェブは今では十分に長い間存在しています。子供たちの世代全体がこれまでに知っていた唯一のインターネットです。私たちは彼らにどのような経験を与えているのでしょうか？　私たちは本質的にダイヤルアップ時代に彼らを連れ戻しています。(私はAOLがまだ無料のインターネットアクセスの1000時間を提供するCDを販売していると聞いて良かった!)

    - A 1000 hour free-trial CD for America Online + A 1000 hour free-trial CD for America Online -
    図 9. 無料で1000時間の「アメリカオンライン」から。archive.org.
    +
    + 図 9. 無料で1000時間の「アメリカオンライン」から。archive.orghttps://archive.org/details/America_Online_1000_Hours_Free_for_45_Days_Version_7.0_Faster_Than_Ever_AM402R28. +

    注:

    1. モバイルに力を入れているサイトを、より小さな画面に合わせてデザインを調整しているサイトと定義しました。というか、CSSのブレークポイントが600px以下に1つ以上あるサイトを指します。

    2. -

      潜在的なユーザーとは、15歳以上の年齢層を指します。57億人。

      +

      + 潜在的なユーザーとは、15歳以上の年齢層を指します。57億人https://www.prb.org/international/geography/world。 +

    3. -

      デスクトップ検索とウェブトラフィックシェアはここ数年減少傾向にあります。

      +

      + デスクトップ検索https://www.merkleinc.com/thought-leadership/digital-marketing-reportとウェブトラフィックシェアhttps://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/#monthly-201205-201909はここ数年減少傾向にあります。 +

    4. -

      アクティブなスマートフォンの総数は、アクティブなAndroidsとiPhone（AppleとGoogleが公開している）の数を合計し、中国のネット接続された電話を考慮し少し計算して判明しました。詳細はこちら。

      +

      + アクティブなスマートフォンの総数は、アクティブなAndroidsとiPhone（AppleとGoogleが公開している）の数を合計し、中国のネット接続された電話を考慮し少し計算して判明しました。詳細はこちらhttps://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile。 +

    5. -

      16億台のデスクトップは、MicrosoftとAppleが公開している数字で計算しています。リナックスPCユーザーは含まれていません。

      +

      + 16億台のデスクトップは、Microsofthttps://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevicesとApplehttps://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-usersが公開している数字で計算しています。リナックスPCユーザーは含まれていません。 +

    -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"III","chapter_number":13,"title":"Eコマース","description":"2019年Web AlmanacのEコマースの章では、Eコマースのプラットフォーム、ペイロード、画像、サードパーティ、パフォーマンス、SEO、PWAをカバーしています。","authors":["samdutton","alankent"],"reviewers":["voltek62"],"translators":["ksakae"],"discuss":"1768","results":"https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/","queries":"13_Ecommerce","published":"2019-11-11","last_updated":"2020-05-19","chapter":"ecommerce"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} III {{ self.chapter() }} 13 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Eコマース +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"III","chapter_number":13,"title":"Eコマース","description":"2019年Web AlmanacのEコマースの章では、Eコマースのプラットフォーム、ペイロード、画像、サードパーティ、パフォーマンス、SEO、PWAをカバーしています。","authors":["samdutton","alankent"],"reviewers":["voltek62"],"translators":["ksakae"],"discuss":"1768","results":"https://docs.google.com/spreadsheets/d/1FUMHeOPYBgtVeMU5_pl2r33krZFzutt9vkOpphOSOss/","queries":"13_Ecommerce","published":"2019-11-11","last_updated":"2020-05-19","chapter":"ecommerce"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -5285,19 +5965,31 @@

    - + -
    {{ self.written_by_before() }} Sam Dutton, {{ self.and() }} Alan Kent{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Vincent Terrasi{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    この調査では、ホームページの10％近くがEコマース・プラットフォーム上にあることが判明しました。「Eコマースプラットフォーム」は、オンラインストアを作成し、運営することを可能にするソフトウェアまたはサービスのセットです。Eコマースプラットフォームのいくつかのタイプがあります。

      -
    • Shopifyのような有料サービスは、あなたのお店をホストし、あなたが始めるのを手助けしてくれます。彼らはウェブサイトのホスティング、サイトやページのテンプレート、商品データの管理、ショッピングカートや支払いを提供しています。
      • -
    • Magento Open Sourceのようなソフトウェアプラットフォームは自分で設定し、ホストし、管理できます。これらのプラットフォームは強力で柔軟性がありますが、Shopifyのようなサービスよりもセットアップや運用が複雑になることがあります。
      • -
    • Magento Commerceのようなホスト付きプラットフォームは、ホスティングがサードパーティによってサービスとして管理されていることを除いて、彼らのセルフホスティングされた対応と同じ機能を提供しています。
      • +
    • + Shopifyhttps://www.shopify.com/のような有料サービスは、あなたのお店をホストし、あなたが始めるのを手助けしてくれます。彼らはウェブサイトのホスティング、サイトやページのテンプレート、商品データの管理、ショッピングカートや支払いを提供しています。 +
      • +
    • + Magento Open Sourcehttps://magento.com/products/magento-open-sourceのようなソフトウェアプラットフォームは自分で設定し、ホストし、管理できます。これらのプラットフォームは強力で柔軟性がありますが、Shopifyのようなサービスよりもセットアップや運用が複雑になることがあります。 +
      • +
    • + Magento Commercehttps://magento.com/products/magento-commerceのようなホスト付きプラットフォームは、ホスティングがサードパーティによってサービスとして管理されていることを除いて、彼らのセルフホスティングされた対応と同じ機能を提供しています。 +
    10%
    @@ -5395,7 +6087,7 @@

    ロングテール

    - 図4. トップのEコマースプラットフォームの採用。 + 図4. トップのEコマースプラットフォームの採用。
    図 4. トップのEコマースプラットフォームの採用。
    @@ -5403,7 +6095,7 @@

    110のEコマースプラットフォームがあり、それぞれがデスクトップまたはモバイルのウェブサイトの0.1％未満を持っています。そのうち約60社は、モバイルかデスクトップのウェブサイトの0.01％未満を占めています。

    - 図5. 上位6つのEコマースプラットフォームと他の110のプラットフォームとの複合的な採用。 + 図5. 上位6つのEコマースプラットフォームと他の110のプラットフォームとの複合的な採用。
    図 5. 上位6つのEコマースプラットフォームと他の110のプラットフォームとの複合的な採用。
    @@ -5413,7 +6105,7 @@

    合計で、デスクトップページの9.7％、モバイルページの9.5％がEコマースプラットフォームを利用していました。

    - 図6. 任意のEコマースプラットフォームを使用しているページの割合。 + 図6. 任意のEコマースプラットフォームを使用しているページの割合。
    図 6. 任意のEコマースプラットフォームを使用しているページの割合。
    @@ -5423,19 +6115,23 @@

    ページの重さは、すべてのHTML、CSS、JavaScript、JSON、XML、画像、オーディオ、およびビデオを含んでいます。

    - 図7. Eコマースのページ重量の分布。 + 図7. Eコマースのページ重量の分布。
    図 7. Eコマースのページ重量の分布。
    - 図8. Eコマースページごとのリクエストの分布。 + 図8. Eコマースページごとのリクエストの分布。
    図 8. Eコマースページごとのリクエストの分布。
    -

    デスクトップEコマースプラットフォームのページの読み込み量の中央値は108リクエストと2.7MBです。すべてのデスクトップページの重量の中央値は74リクエストと1.9 MB です。言い換えれば、Eコマースページは他のウェブページよりも50％近く多くのリクエストを行い、ペイロードは約35％大きくなっています。比較すると、amazon.comのホームページは、最初のロード時に約5MBのページ重量に対して約300リクエストを行い、ebay.comは約3MBのページウェイトに対して約150リクエストを行います。Eコマースプラットフォーム上のホームページのページ重量とリクエスト数は、各パーセンタイルでモバイルの方が若干小さくなっていますが、すべてのEコマースのホームページの約10％が7MB以上をロードし200以上のリクエストをしています。

    +

    + デスクトップEコマースプラットフォームのページの読み込み量の中央値は108リクエストと2.7MBです。すべてのデスクトップページの重量の中央値は74リクエストと1.9 MB です。言い換えれば、Eコマースページは他のウェブページよりも50％近く多くのリクエストを行い、ペイロードは約35％大きくなっています。比較すると、amazon.comhttps://amazon.comのホームページは、最初のロード時に約5MBのページ重量に対して約300リクエストを行い、ebay.comhttps://ebay.comは約3MBのページウェイトに対して約150リクエストを行います。Eコマースプラットフォーム上のホームページのページ重量とリクエスト数は、各パーセンタイルでモバイルの方が若干小さくなっていますが、すべてのEコマースのホームページの約10％が7MB以上をロードし200以上のリクエストをしています。 +

    このデータは、ホームページのペイロードとスクロールなしのリクエストを含んでいます。明らかに、最初のロードに必要なはずのファイル数よりも多くのファイルを取得しているように見えるサイトがかなりの割合で存在しています(中央値は100以上)。以下のサードパーティのリクエストとバイト数も参照してください。

    Eコマース・プラットフォーム上の多くのホームページが、なぜこれほど多くのリクエストを行い、これほど大きなペイロードを持つのかをよりよく理解するために、さらに調査を行う必要があります。著者らはEコマース・プラットフォーム上のホームページで、最初のロード時に数百回のリクエストを行い、数メガバイトのペイロードを持つホームページを定期的に目にします。リクエスト数とペイロードがパフォーマンスの問題であるならば、どのようにしてそれらを減らすことができるのでしょうか？

    タイプ別のリクエストとペイロード

    @@ -5647,7 +6343,7 @@

    HTMLペイロードサイズ

    - 図11. EコマースページあたりのHTMLバイト数の分布（KB単位）。 + 図11. EコマースページあたりのHTMLバイト数の分布（KB単位）。
    図 11. EコマースページあたりのHTMLバイト数の分布（KB単位）。
    @@ -5657,14 +6353,14 @@

    画像の統計

    - 図12. Eコマースページごとの画像バイト数の分布（KB単位）。 + 図12. Eコマースページごとの画像バイト数の分布（KB単位）。
    図 12. Eコマースページごとの画像バイト数の分布（KB単位）。
    - 図13. Eコマースページごとの画像リクエストの分布。 + 図13. Eコマースページごとの画像リクエストの分布。
    図 13. Eコマースページごとの画像リクエストの分布。
    @@ -5675,24 +6371,43 @@

    1,517 KB

    図 14. モバイルEコマースページあたりの画像バイト数の中央値。
    -

    Eコマースページのかなりの割合で、大きな画像ペイロードを持ち、最初のロード時に大量の画像リクエストを行います。詳細については、HTTP ArchiveのState of Imagesレポート、およびmediaと[page weight](./page weight)の章を参照してください。

    +

    + Eコマースページのかなりの割合で、大きな画像ペイロードを持ち、最初のロード時に大量の画像リクエストを行います。詳細については、HTTP ArchiveのState of Imageshttps://httparchive.org/reports/state-of-imagesレポート、およびmediaと[page weight](./page weight)の章を参照してください。 +

    ウェブサイトの所有者は、自分のサイトを最新のデバイスで見栄えの良いものにしたいと考えています。その結果、多くのサイトでは、画面の解像度やサイズに関係なく、すべてのユーザーに同じ高解像度の製品画像を配信しています。開発者は、異なるユーザーに可能な限り最高の画像を効率的に配信できるレスポンシブ技術に気づいていない（または使いたくない）かもしれません。高解像度の画像が必ずしもコンバージョン率を高めるとは限らないことを覚えておきましょう。逆に重い画像の使いすぎは、ページの速度に影響を与える可能性が高く、それによってコンバージョン率を低下させる可能性があります。サイトレビューやイベントでの著者の経験では、開発者やその他の関係者の中には、画像に遅延ローディングを使用することにSEOなどの懸念を持っている人もいます。

    一部のサイトがレスポンシブ画像技術や遅延読み込みを使用していない理由をよりよく理解するために、より多くの分析を行う必要があります。またEコマースプラットフォームが、ハイエンドのデバイスや接続性の良いサイトに美しい画像を確実に配信すると同時に、ローエンドのデバイスや接続性の悪いサイトにも最高の体験を提供できるようなガイダンスを提供する必要があります。

    - 図15. 一般的な画像フォーマット。 + 図15. 一般的な画像フォーマット。
    図 15. 一般的な画像フォーマット。
    -

    画像サービスやCDNの中には、`.jpg`や`.png`という接尾辞を持つURLであっても、WebPをサポートしているプラットフォームには自動的にWebP(JPEGやPNGではなく)を配信するものがあることに注意してください。たとえば、IMG_20190113_113201.jpgはChromeでWebP画像を返します。しかし、HTTP Archive画像フォーマットを検出する方法は、最初にMIMEタイプのキーワードをチェックしてから、ファイルの拡張子にフォールバックするというものです。つまり、HTTP ArchiveがユーザーエージェントとしてWebPをサポートしているため、上記のようなURLを持つ画像のフォーマットはWebPとして与えられることになります。

    +

    + 画像サービスやCDNの中には、`.jpg`や`.png`という接尾辞を持つURLであっても、WebPをサポートしているプラットフォームには自動的にWebP(JPEGやPNGではなく)を配信するものがあることに注意してください。たとえば、IMG_20190113_113201.jpghttps://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpgはChromeでWebP画像を返します。しかし、HTTP Archive画像フォーマットを検出する方法https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994は、最初にMIMEタイプのキーワードをチェックしてから、ファイルの拡張子にフォールバックするというものです。つまり、HTTP ArchiveがユーザーエージェントとしてWebPをサポートしているため、上記のようなURLを持つ画像のフォーマットはWebPとして与えられることになります。 +

    PNG

    Eコマースページの4つに1つの画像はPNGです。Eコマースプラットフォーム上のページでPNGのリクエストが多いのは、商品画像のためと思われます。多くのコマースサイトでは、透過性を確保するために写真画像と一緒にPNGを使用しています。

    -

    PNGフォールバックでWebPを使用することは、画像要素を介して、またはCloudinaryのような画像サービスを介してユーザーエージェントの能力検出を使用することで、はるかに効率的な代替手段となります。

    +

    + PNGフォールバックでWebPを使用することは、画像要素http://simpl.info/picturetypeを介して、またはCloudinaryhttps://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpgのような画像サービスを介してユーザーエージェントの能力検出を使用することで、はるかに効率的な代替手段となります。 +

    WebP

    -

    Eコマースプラットフォーム上の画像の1％だけがWebPであり、これはサイトレビューやパートナーの仕事での著者の経験と一致しています。WebPはSafari以外のすべての最新ブラウザでサポートされていますし、フォールバックの仕組みも充実しています。WebPは透過性をサポートしており、写真画像のためのPNGよりもはるかに効率的なフォーマットです（上記のPNGのセクションを参照してください）。

    -

    WebPをPNGのフォールバックで使用したり、無地の色の背景でWebP/JPEGを使用して透明化を可能にするため、Webコミュニティとして、より良いガイダンスや提唱を提供できます。WebPは、ガイド やツール (例:Squooshやcwebpなど)があるにもかかわらず、電子商取引プラットフォームではほとんど使用されていないようです。現在10年近く経っているWebPの利用が増えていない理由をさらに調査する必要があります。

    +

    + Eコマースプラットフォーム上の画像の1％だけがWebPであり、これはサイトレビューやパートナーの仕事での著者の経験と一致しています。WebPはSafari以外のすべての最新ブラウザでサポートされていますhttps://caniuse.com/#feat=webpし、フォールバックの仕組みも充実しています。WebPは透過性をサポートしており、写真画像のためのPNGよりもはるかに効率的なフォーマットです（上記のPNGのセクションを参照してください）。 +

    +

    + WebPをPNGのフォールバックで使用したり、無地の色の背景でWebP/JPEGを使用して透明化を可能にするため、Webコミュニティとして、より良いガイダンスや提唱を提供できます。WebPは、ガイドhttps://web.dev/serve-images-webp やツール (例:Squooshhttps://squoosh.app/やcwebphttps://developers.google.com/speed/webp/docs/cwebpなど)があるにもかかわらず、電子商取引プラットフォームではほとんど使用されていないようです。現在10年近く経っているhttps://blog.chromium.org/2010/09/webp-new-image-format-for-web.htmlWebPの利用が増えていない理由をさらに調査する必要があります。 +

    画像の寸法

    @@ -5758,35 +6473,43 @@

    サードパーティからのリクエストとバイト

    -

    多くのウェブサイト、特にオンラインストアでは、分析、A/Bテスト、顧客行動追跡、広告、ソーシャルメディアのサポートなどのためにサードパーティのコードやコンテンツを大量にロードしています。サードパーティのコンテンツは、パフォーマンスに大きな影響を与えることがあります。 Patrick Hulceのサードパーティウェブツールは、本レポートのサードパーティのリクエストを判断するために使用されており、これについてはサードパーティの章で詳しく説明しています。

    +

    + 多くのウェブサイト、特にオンラインストアでは、分析、A/Bテスト、顧客行動追跡、広告、ソーシャルメディアのサポートなどのためにサードパーティのコードやコンテンツを大量にロードしています。サードパーティのコンテンツは、パフォーマンスに大きな影響を与えるhttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascriptことがあります。 Patrick Hulcehttps://twitter.com/patrickhulceのサードパーティウェブツールhttps://github.com/patrickhulce/third-party-webは、本レポートのサードパーティのリクエストを判断するために使用されており、これについてはサードパーティの章で詳しく説明しています。 +

    - 図17. Eコマースページごとのサードパーティリクエストの分布。 + 図17. Eコマースページごとのサードパーティリクエストの分布。
    図 17. Eコマースページごとのサードパーティリクエストの分布。
    - 図18. Eコマースページあたりのサードパーティのバイト数の分布。 + 図18. Eコマースページあたりのサードパーティのバイト数の分布。
    図 18. Eコマースページあたりのサードパーティのバイト数の分布。

    Eコマースプラットフォーム上の中央値（「中規模」）のホームページでは、サードパーティのコンテンツに対するリクエストは、モバイルで17件、デスクトップで19件となっています。Eコマース・プラットフォーム上のすべてのホームページの10％は、サードパーティのコンテンツに対して50件以上のリクエストを行い、その総ペイロードは1MBを超えています。

    -

    他の研究で、サードパーティのコンテンツはパフォーマンスの大きなボトルネックになる可能性であることが指摘されています。この調査によると、17以上のリクエスト（上位10％では50以上）がEコマースページの標準となっています。

    +

    + 他の研究https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/で、サードパーティのコンテンツはパフォーマンスの大きなボトルネックになる可能性であることが指摘されています。この調査によると、17以上のリクエスト（上位10％では50以上）がEコマースページの標準となっています。 +

    プラットフォームごとのサードパーティリクエストとペイロード

    以下の表は、モバイルのみのデータを示しています。

    - 図19. 各Eコマースプラットフォームのモバイルページごとのサードパーティリクエストの分布。 + 図19. 各Eコマースプラットフォームのモバイルページごとのサードパーティリクエストの分布。
    図 19. 各Eコマースプラットフォームのモバイルページごとのサードパーティリクエストの分布。
    - 図20. 各Eコマースプラットフォームのモバイルページあたりのサードパーティのバイト数（KB）分布。 + 図20. 各Eコマースプラットフォームのモバイルページあたりのサードパーティのバイト数（KB）分布。
    図 20. 各Eコマースプラットフォームのモバイルページあたりのサードパーティのバイト数（KB）分布。
    @@ -5796,7 +6519,7 @@

    コンテンツの初回ペイント(FCP)

    - 図21. Eコマースプラットフォーム毎のFCP体験の平均分布。 + 図21. Eコマースプラットフォーム毎のFCP体験の平均分布。
    図 21. Eコマースプラットフォーム毎のFCP体験の平均分布。
    @@ -5808,94 +6531,92 @@

    Eコマースサイト以外のこのトピックの詳細については、PWAの章も参照してください。

    - 図22. モバイルEコマースページのLighthouse PWAカテゴリスコアの分布。 + 図22. モバイルEコマースページのLighthouse PWAカテゴリスコアの分布。
    図 22. モバイルEコマースページのLighthouse PWAカテゴリスコアの分布。
    -

    Eコマースのプラットフォーム上のホームページの60％以上は、0.25と0.35の間にLighthouse PWAスコアを取得します。Eコマースのプラットフォーム上のホームページの20％未満は、0.5以上のスコアを取得し、ホームページの1％未満は0.6以上のスコアを取得します。

    -

    Lighthouseは、プログレッシブWebアプリ（PWA）のスコアを0から1の間で返します。PWAの監査は、14の要件をリストアップしたBaseline PWA Checklistに基づいています。Lighthouseは、14の要件のうち11の要件について自動監査を実施しています。残りの3つは手動でしかテストできません。11の自動PWA監査はそれぞれ均等に重み付けされているため、それぞれがPWAスコアに約9ポイント寄与します。

    +

    + Eコマースのプラットフォーム上のホームページの60％以上は、0.25と0.35の間にLighthouse PWAスコアhttps://developers.google.com/web/ilt/pwa/lighthouse-pwa-analysis-toolを取得します。Eコマースのプラットフォーム上のホームページの20％未満は、0.5以上のスコアを取得し、ホームページの1％未満は0.6以上のスコアを取得します。 +

    +

    + Lighthouseは、プログレッシブWebアプリ（PWA）のスコアを0から1の間で返します。PWAの監査は、14の要件をリストアップしたBaseline PWA Checklisthttps://developers.google.com/web/progressive-web-apps/checklistに基づいています。Lighthouseは、14の要件のうち11の要件について自動監査を実施しています。残りの3つは手動でしかテストできません。11の自動PWA監査はそれぞれ均等に重み付けされているため、それぞれがPWAスコアに約9ポイント寄与します。 +

    PWA監査のうち少なくとも1つがnullスコアを取得した場合、LighthouseはPWAカテゴリ全体のスコアをnullアウトします。これは、モバイルページの2.32％が該当しました。

    -

    明らかに、大多数のEコマースページは、ほとんどのPWA チェックリスト監査 に失敗しています。どの監査が失敗しているのか、なぜ失敗しているのかをよりよく理解するために、さらに分析を行う必要があります。

    +

    + 明らかに、大多数のEコマースページは、ほとんどのPWA チェックリスト監査https://developers.google.com/web/progressive-web-apps/checklist に失敗しています。どの監査が失敗しているのか、なぜ失敗しているのかをよりよく理解するために、さらに分析を行う必要があります。 +

    結論

    Eコマースの使用法のこの包括的な研究はいくつかの興味深いデータを示し、また同じEコマースのプラットフォーム上に構築されたものの間でも、Eコマースのサイトの広いバリエーションを示しています。ここでは多くの詳細を説明しましたが、この分野ではもっと多くの分析が可能です。例えば、今年はアクセシビリティのスコアを取得していませんでした（それについての詳細はアクセシビリティの章をチェックアウトしてください）。同様に、これらのメトリクスを地域別にセグメント化することも興味深いことでしょう。この調査では、Eコマース・プラットフォームのホームページ上で246の広告プロバイダーが検出されました。さらなる調査（おそらく来年のWeb Almanacに掲載されるかもしれません）では、Eコマースプラットフォーム上で広告を表示しているサイトの割合を計算できます。この調査ではWooCommerceが非常に高い数値を記録していますので、来年の調査では一部のホスティングプロバイダーがWooCommerceをインストールしているにもかかわらず、有効にしていないために数値が膨らんでいるのではないかという興味深い統計を見ることができます。

    -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"III","chapter_number":14,"title":"CMS","description":"2019年版Web AlmanacCMS章では、CMSの採用、CMS組み合わせの構築方法、CMSを搭載したWebサイトのユーザーエクスペリエンス、CMSのイノベーションを取り上げています。","authors":["ernee","amedina"],"reviewers":["sirjonathan"],"translators":["ksakae"],"discuss":"1769","results":"https://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/","queries":"14_CMS","published":"2019-11-11","last_updated":"2020-05-05","chapter":"cms"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} III {{ self.chapter() }} 14 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - CMS +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"III","chapter_number":14,"title":"CMS","description":"2019年版Web AlmanacCMS章では、CMSの採用、CMS組み合わせの構築方法、CMSを搭載したWebサイトのユーザーエクスペリエンス、CMSのイノベーションを取り上げています。","authors":["ernee","amedina"],"reviewers":["sirjonathan"],"translators":["ksakae"],"discuss":"1769","results":"https://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/","queries":"14_CMS","published":"2019-11-11","last_updated":"2020-05-05","chapter":"cms"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -5904,13 +6625,16 @@

    - + -
    {{ self.written_by_before() }} Renee Johnson, {{ self.and() }} Alberto Medina{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Jonathan Wold{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    コンテンツ管理システム（CMS）とは、個人や組織がコンテンツを作成・管理・公開するためのシステムを総称しています。具体的には、オープンウェブを介して消費・体験できるコンテンツを作成・管理・公開することを目的としたシステムのことを指します。

    各CMSは、ユーザーがコンテンツを中心に簡単かつ効果的にウェブサイトを構築できるように、幅広いコンテンツ管理機能とそれに対応するメカニズムのサブセットを実装しています。このようなコンテンツは多くの場合、何らかのデータベースに保存されており、ユーザーはコンテンツ戦略のために必要な場所であればどこでも再利用できる柔軟性を持っています。CMSはまた、ユーザーが必要に応じてコンテンツを簡単にアップロードして管理できるようにすることを目的とした管理機能を提供します。

    @@ -5918,10 +6642,13 @@

    序章

    CMSについて考えるとき、ウェブ上にコンテンツを公開するためのプラットフォームを提供するシステムの実行可能性に関わるすべてのコンポーネントを考慮に入れる必要があります。これらのコンポーネントはすべて、CMSプラットフォームを取り巻くエコシステムを形成しており、ホスティングプロバイダ、拡張機能開発、開発代理、サイトビルダーなどが含まれています。このように、CMSというと、通常はプラットフォームそのものとそれを取り巻くエコシステムの両方を指すことになります。

    コンテンツ制作者はなぜCMSを使うのか？

    (ウェブの進化）時代の初期にはウェブのエコシステムはユーザーがウェブページのソースを見て、必要に応じてコピーペーストし画像などの個別の要素で新しいバージョンをカスタマイズするだけでクリエイターになれるという、単純な成長ループで動いていました。

    -

    ウェブが進化するにつれ、ウェブはより強力になる一方で、より複雑になりました。その結果、その単純な成長のループは破られ、誰でもクリエイターになれるような状況ではなくなってしまいました。コンテンツ制作の道を追求できる人にとっては、その道のりは険しく困難なものになってしまいました。ウェブでできることと実際にできることの差である利用可能性ギャップは着実に拡大していきました。

    +

    + ウェブが進化するにつれ、ウェブはより強力になる一方で、より複雑になりました。その結果、その単純な成長のループは破られ、誰でもクリエイターになれるような状況ではなくなってしまいました。コンテンツ制作の道を追求できる人にとっては、その道のりは険しく困難なものになってしまいました。ウェブでできることと実際にできることの差である利用可能性ギャップhttps://medinathoughts.com/2018/05/17/progressive-wordpress/は着実に拡大していきました。 +

    - 図1. 1999年から2018年までのWeb機能の増加を示すグラフ。 + 図1. 1999年から2018年までのWeb機能の増加を示すグラフ。
    図 1. 1999年から2018年までのWeb機能の増加を示すグラフ。
    @@ -5936,11 +6663,14 @@

    CMS導入図 2. CMSを搭載したウェブページの割合。

    今日では、ウェブページの40％以上が何らかのCMSプラットフォームを利用していることがわかります。40.01％がモバイル用で、39.61％がデスクトップ用です。

    -

    他にもW3TechsのようにCMSプラットフォームの市場シェアを追跡しているデータセットがあり、CMSプラットフォームを利用したウェブページの割合が50％を超えていることを反映しています。さらに、これらのデータはCMSプラットフォームが成長しており、場合によっては前年比12％の成長率を記録しています。弊社の分析とW3Techの分析との乖離は、調査方法の違いによって説明できるかもしれません。我々の分析については、方法論のページを参照してください。

    +

    + 他にもW3Techshttps://w3techs.com/technologies/history_overview/content_managementのようにCMSプラットフォームの市場シェアを追跡しているデータセットがあり、CMSプラットフォームを利用したウェブページの割合が50％を超えていることを反映しています。さらに、これらのデータはCMSプラットフォームが成長しており、場合によっては前年比12％の成長率を記録しています。弊社の分析とW3Techの分析との乖離は、調査方法の違いによって説明できるかもしれません。我々の分析については、方法論のページを参照してください。 +

    要するに、多くのCMSプラットフォームが存在するということです。下の写真は、CMSの風景を縮小したものです。

    - 図3. 上位のコンテンツ管理システム。 + 図3. 上位のコンテンツ管理システム。
    図 3. 上位のコンテンツ管理システム。
    @@ -5952,7 +6682,7 @@

    CMSの

    デスクトップとモバイルデバイスで提供されているウェブページを見てみると、何らかのCMSプラットフォームによって生成されたページとそうでないページの割合が約60-40％に分かれていることがわかります。

    - 図4. CMSを使用しているデスクトップおよびモバイルサイトの割合。 + 図4. CMSを使用しているデスクトップおよびモバイルサイトの割合。
    図 4. CMSを使用しているデスクトップおよびモバイルサイトの割合。
    @@ -5966,16 +6696,21 @@

    CMSの
  • コミュニティ
  • 他にもたくさん
    • -

    CrUXとHTTP Archiveのデータセットには、約103のCMSプラットフォームが、混在したウェブページが含まれています。これらのプラットフォームのほとんどは、相対的な市場シェアが非常に小さいものです。今回の分析では、データに反映されているウェブ上でのフットプリントという観点から、上位のCMSプラットフォームに焦点を当ててみたいと思います。完全な分析については、この章の結果のスプレッドシートを参照してください。

    +

    + CrUXとHTTP Archiveのデータセットには、約103のCMSプラットフォームが、混在したウェブページが含まれています。これらのプラットフォームのほとんどは、相対的な市場シェアが非常に小さいものです。今回の分析では、データに反映されているウェブ上でのフットプリントという観点から、上位のCMSプラットフォームに焦点を当ててみたいと思います。完全な分析については、この章の結果のスプレッドシートを参照してくださいhttps://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/edit#gid=0。 +

    - 図5. 全CMSウェブサイトに占めるトップCMSプラットフォームの割合。 + 図5. 全CMSウェブサイトに占めるトップCMSプラットフォームの割合。
    図 5. 全CMSウェブサイトに占めるトップCMSプラットフォームの割合。

    データセットに含まれる最も顕著なCMSプラットフォームを図5に示す。WordPressはモバイルサイトの74.19%、デスクトップサイトの73.47% を占めています。CMSの世界におけるWordPressの優位性は、後述するいくつかの要因に起因していますが、WordPressは主要なプレイヤーです。DrupalやJoomlaのようなオープンソースのプラットフォームと、SquarespaceやWixのようなクローズドなSaaSが上位5つのCMSを占めています。これらのプラットフォームの多様性は、多くのプラットフォームからなるCMSエコシステムを物語っています。また、興味深いのは、上位20位までの小規模CMSプラットフォームのロングテールです。企業向けに提供されているものから、業界特有の用途のために社内で開発された独自のアプリケーションまで、コンテンツ管理システムは、グループがウェブ上で管理、公開、ビジネスを行うためのカスタマイズ可能なインフラストラクチャを提供しています。

    -

    WordPressプロジェクト](https://wordpress.org/about/)は、そのミッションを「*出版の民主化*」と定義しています。その主な目標のいくつかは、使いやすさと、誰もがウェブ上でコンテンツを作成できるようにソフトウェアを無料で利用できるようにすることです。もう1つの大きな要素は、このプロジェクトが育んでいる包括的なコミュニティです。世界のほとんどの大都市ではWordPressプラットフォームを理解し、構築しようと定期的に集まり、つながりを持ち共有し、コードを書く人々のグループを見つけることができます。地域のミートアップや年次イベントに参加したり、ウェブベースのチャンネルに参加したりすることは、WordPressの貢献者、専門家、ビジネス、愛好家がそのグローバルなコミュニティに参加する方法の一部となっています。

    +

    + WordPressプロジェクト](https://wordpress.org/about/)は、そのミッションを「*出版の民主化*」と定義しています。その主な目標のいくつかは、使いやすさと、誰もがウェブ上でコンテンツを作成できるようにソフトウェアを無料で利用できるようにすることです。もう1つの大きな要素は、このプロジェクトが育んでいる包括的なコミュニティです。世界のほとんどの大都市ではWordPressプラットフォームを理解し、構築しようと定期的に集まり、つながりを持ち共有し、コードを書く人々のグループを見つけることができます。地域のミートアップや年次イベントに参加したり、ウェブベースのチャンネルに参加したりすることは、WordPressの貢献者、専門家、ビジネス、愛好家がそのグローバルなコミュニティに参加する方法の一部となっています。https://wordpress.org/about/)は、そのミッションを「*出版の民主化*」と定義しています。その主な目標のいくつかは、使いやすさと、誰もがウェブ上でコンテンツを作成できるようにソフトウェアを無料で利用できるようにすることです。もう1つの大きな要素は、このプロジェクトが育んでいる包括的なコミュニティです。世界のほとんどの大都市ではWordPressプラットフォームを理解し、構築しようと定期的に集まり、つながりを持ち共有し、コードを書く人々のグループを見つけることができます。地域のミートアップや年次イベントに参加したり、ウェブベースのチャンネルに参加したりすることは、WordPressの貢献者、専門家、ビジネス、愛好家がそのグローバルなコミュニティに参加する方法の一部となっています。 +

    WordPressの人気は参入障壁の低さと、ユーザー（オンラインと対面）がプラットフォーム上でのパブリッシングをサポートし、拡張機能（プラグイン）やテーマを開発するためのリソースが要因となっています。またWordPressのプラグインやテーマは、ウェブデザインや機能性を追求した実装の複雑さを軽減してくれるので、利用しやすく経済的です。これらの側面が、新規参入者によるリーチと採用を促進するだけでなく、長期的な使用を維持しています。

    オープンソースのWordPressプラットフォームは、ボランティア、WordPress Foundation、そしてウェブエコシステムの主要なプレイヤーによって運営されサポートされています。これらの要素を考慮すると、WordPressを主要なCMSとすることは理にかなっています。

    CMSを搭載したサイトはどのように構築されているのか

    @@ -5985,14 +6720,14 @@

    HTML、CSS、JavaScript、media（画像や動画）です。CMSプラットフォームは、これらのリソースを統合してWeb体験を作成するための強力に合理化された管理機能をユーザーに提供します。これは、これらのアプリケーションの最も包括的な側面の1つですが、より広いウェブに悪影響を及ぼす可能性があります。

    - 図6. CMSページ重量の分布。 + 図6. CMSページ重量の分布。
    図 6. CMSページ重量の分布。
    - 図7. ページあたりのCMSリクエストの分布。 + 図7. ページあたりのCMSリクエストの分布。
    図 7. ページあたりのCMSリクエストの分布。
    @@ -6108,20 +6843,23 @@

    もう一つの複雑さの層を追加します。この章の後半では、CrUXのデータを使用して、CMS空間でのユーザー体験を評価します。

    +

    + CMSの経験がこれらのリソースで飽和状態にある中で、フロントエンドのウェブサイト訪問者に与える影響を考慮しなければなりません。さらに、モバイルとデスクトップのリソース使用量を比較すると、リクエストの量と重さにはほとんど差がありません。つまり、同じ量と重量のリソースがモバイルとデスクトップの両方のCMS体験を動かしていることになります。接続速度とモバイルデバイスの品質のばらつきは、もう一つの複雑さの層https://medinathoughts.com/2017/12/03/the-perils-of-mobile-web-performance-part-iii/を追加します。この章の後半では、CrUXのデータを使用して、CMS空間でのユーザー体験を評価します。 +

    サードパーティのリソース

    リソースの特定のサブセットを強調して、CMSの世界での影響を評価してみましょう。サードパーティリソースとは、送信先サイトのドメイン名やサーバーに属さないオリジンからのリソースです。画像、動画、スクリプト、その他のリソースタイプがあります。これらのリソースは、例えばiframeを埋め込むなど、組み合わせてパッケージ化されていることもあります。当社のデータによると、デスクトップとモバイルの両方で、サードパーティのリソースの中央値は近いことがわかります。

    モバイルCMSページのサードパーティリクエストの中央値は15、重さ264.72KBでデスクトップCMSページのサードパーティリクエストの中央値は16、重さ271.56KBです。(これは「ホスティング」の一部とみなされる3Pリソースを除いたものであることに注意)。

    - 図10. CMSページにおけるサードパーティウェイト（KB）の分布。 + 図10. CMSページにおけるサードパーティウェイト（KB）の分布。
    図 10. CMSページにおけるサードパーティウェイト（KB）の分布。
    - 図11. CMSページの第三者リクエスト数の分布。 + 図11. CMSページの第三者リクエスト数の分布。
    図 11. CMSページの第三者リクエスト数の分布。
    @@ -6131,7 +6869,7 @@

    画像の統計

    - 図12. CMSページにおける画像の重み（KB）の分布。 + 図12. CMSページにおける画像の重み（KB）の分布。
    図 12. CMSページにおける画像の重み（KB）の分布。
    @@ -6144,15 +6882,22 @@

    モバイルやデスクトップのCMSページでよく見られるフォーマットは何ですか？　当社のデータによると、平均的にJPG画像が最も人気のある画像フォーマットです。次いでPNG、GIFが続き、SVG、ICO、WebPのようなフォーマットが2％強、1％強と大きく後れを取っています。

    - 図14. CMSページでの画像フォーマットの採用。 + 図14. CMSページでの画像フォーマットの採用。
    図 14. CMSページでの画像フォーマットの採用。
    -

    おそらく、これらの画像タイプの一般的な使用例を考えると、このようなセグメンテーションは驚くべきものでありません。ロゴやアイコン用のSVGは、JPEGがユビキタスであるのと同様に一般的です。WebPはまだ比較的新しい最適化されたフォーマットであり、ブラウザの普及が進んでいます。これが今後数年の間にCMS空間での使用にどのような影響を与えるかを見るのは興味深いことでしょう。

    +

    + おそらく、これらの画像タイプの一般的な使用例を考えると、このようなセグメンテーションは驚くべきものでありません。ロゴやアイコン用のSVGは、JPEGがユビキタスであるのと同様に一般的です。WebPはまだ比較的新しい最適化されたフォーマットであり、ブラウザの普及が進んでいますhttps://caniuse.com/#search=webp。これが今後数年の間にCMS空間での使用にどのような影響を与えるかを見るのは興味深いことでしょう。 +

    CMSを搭載したウェブサイトのユーザー体験

    ウェブコンテンツ制作者として成功するには、ユーザー体験がすべてです。リソースの使用量やウェブページの構成方法に関するその他の統計などの要因は、サイトを構築する際のベストプラクティスの観点から、サイトの品質を示す重要な指標となります。しかし私たちは最終的に、これらのプラットフォームで生成されたコンテンツを消費したり、利用したりする際にユーザーが実際にどのようにウェブを体験しているのかを明らかにしたいと考えています。

    -

    これを実現するために、CrUXデータセットに収録されているいくつかの利用者目線のパフォーマンス指標に向けて分析を行います。これらのメトリクスは、人として私たちが時間をどのように感じるかに何らかの形で関連しています。

    +

    + これを実現するために、CrUXデータセットに収録されているいくつかの利用者目線のパフォーマンス指標https://developers.google.com/web/fundamentals/performance/user-centric-performance-metricsに向けて分析を行います。これらのメトリクスは、人として私たちが時間をどのように感じるかhttps://paulbakaus.com/tutorials/performance/the-illusion-of-speed/に何らかの形で関連しています。 +

    @@ -6190,10 +6935,12 @@

    コンテンツの初回ペイント

    -

    コンテンツの初回ペイント は、ナビゲーションからテキストや画像などのコンテンツが最初に表示されるまでの時間を測定します。成功したFCPの経験、つまり「速い」と認定される経験とは、ウェブサイトの読み込みが正常に行われていることをユーザーへ保証するため、DOM内の要素がどれだけ速くロードされるかということです。FCPのスコアが良ければ対応するサイトが良いUXを提供していることを保証するものではありませんが、FCPが悪ければ、ほぼ確実にその逆を保証することになります。

    +

    + コンテンツの初回ペイントhttps://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint は、ナビゲーションからテキストや画像などのコンテンツが最初に表示されるまでの時間を測定します。成功したFCPの経験、つまり「速い」と認定される経験とは、ウェブサイトの読み込みが正常に行われていることをユーザーへ保証するため、DOM内の要素がどれだけ速くロードされるかということです。FCPのスコアが良ければ対応するサイトが良いUXを提供していることを保証するものではありませんが、FCPが悪ければ、ほぼ確実にその逆を保証することになります。 +

    - 図16. CMS全体のFCP経験の平均分布。 + 図16. CMS全体のFCP経験の平均分布。
    図 16. CMS全体のFCP経験の平均分布。
    @@ -6250,11 +6997,13 @@

    入力の推定待ち時間

    -

    入力の推定待ち時間 (FID) は、ユーザーが最初にサイトとやり取りをした時（リンクをクリックした時、ボタンをタップした時、カスタムのJavaScriptを使用したコントロールを使用した時など）から、ブラウザが実際にそのやり取りへ応答できるようになるまでの時間を測定します。ユーザーの視点から見た「速い」FIDとは、サイト上でのアクションからの即時フィードバックであり、停滞した体験ではありません。この遅延(痛いところ)は、ユーザーがサイトと対話しようとしたときに、サイトの読み込みの他の側面からの干渉と相関する可能性があります。

    +

    + 入力の推定待ち時間https://developers.google.com/web/updates/2018/05/first-input-delay (FID) は、ユーザーが最初にサイトとやり取りをした時（リンクをクリックした時、ボタンをタップした時、カスタムのJavaScriptを使用したコントロールを使用した時など）から、ブラウザが実際にそのやり取りへ応答できるようになるまでの時間を測定します。ユーザーの視点から見た「速い」FIDとは、サイト上でのアクションからの即時フィードバックであり、停滞した体験ではありません。この遅延(痛いところ)は、ユーザーがサイトと対話しようとしたときに、サイトの読み込みの他の側面からの干渉と相関する可能性があります。 +

    CMS領域のFIDは一般的に、デスクトップとモバイルの両方で平均的に高速なエクスペリエンスを提供する傾向にある。しかし、注目すべきは、モバイルとデスクトップの体験の間に大きな違いがあることです。

    - 図18. CMS全体のFID経験の平均分布。 + 図18. CMS全体のFID経験の平均分布。
    図 18. CMS全体のFID経験の平均分布。
    @@ -6312,34 +7061,43 @@

    Lighthouseスコア

    Lighthouse は、開発者がWebサイトの品質を評価して改善するのに役立つように設計された、オープンソースの自動化ツールです。このツールの重要な側面の1つは、パフォーマンス、アクセシビリティ、プログレッシブなWebアプリなどの観点からWebサイトの状態を評価するための監査のセットを提供することです。この章の目的のために、2つの特定の監査カテゴリに興味を持っています。PWAとアクセシビリティです。

    PWA

    -

    プログレッシブウェブアプリ (PWA)という用語は、信頼できる、速い、魅力的とみなされるウェブベースのユーザー体験を指します。Lighthouseは、0（最悪）から1（最高）の間のPWAスコアを返す一連の監査を提供しています。これらの監査は、14の要件をリストアップしたベースラインPWAチェックリストに基づいています。Lighthouseは、14の要件のうち11の要件について自動監査を実施しています。残りの3つは手動でしかテストできません。11の自動PWA監査はそれぞれ均等に重み付けされているため、それぞれがPWAスコアに約9ポイント寄与します。

    +

    + プログレッシブウェブアプリ (PWA)という用語は、信頼できるhttps://developers.google.com/web/progressive-web-apps#reliable、速いhttps://developers.google.com/web/progressive-web-apps#fast、魅力的https://developers.google.com/web/progressive-web-apps#engagingとみなされるウェブベースのユーザー体験を指します。Lighthouseは、0（最悪）から1（最高）の間のPWAスコアを返す一連の監査を提供しています。これらの監査は、14の要件をリストアップしたベースラインPWAチェックリストhttps://developers.google.com/web/progressive-web-apps/checklist#baselineに基づいています。Lighthouseは、14の要件のうち11の要件について自動監査を実施しています。残りの3つは手動でしかテストできません。11の自動PWA監査はそれぞれ均等に重み付けされているため、それぞれがPWAスコアに約9ポイント寄与します。 +

    - 図20. CMSページのLighthouse PWAカテゴリスコアの分布。 + 図20. CMSページのLighthouse PWAカテゴリスコアの分布。
    図 20. CMSページのLighthouse PWAカテゴリスコアの分布。
    - 図21. CMSごとの灯台PWAカテゴリスコアの中央値。 + 図21. CMSごとの灯台PWAカテゴリスコアの中央値。
    図 21. CMSごとの灯台PWAカテゴリスコアの中央値。

    アクセンシビリティ

    -

    アクセシブルなウェブサイトとは、障害者が利用できるように設計・開発されたサイトのことです。Lighthouseは、一連のアクセシビリティ監査を提供し、それらすべての監査の加重平均を返します（各監査の加重方法の完全なリストについては、スコアリングの詳細を参照してください）。

    +

    + アクセシブルなウェブサイトとは、障害者が利用できるように設計・開発されたサイトのことです。Lighthouseは、一連のアクセシビリティ監査を提供し、それらすべての監査の加重平均を返します（各監査の加重方法の完全なリストについては、スコアリングの詳細https://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=1567011065を参照してください）。 +

    各アクセシビリティ監査は合格か、不合格かですが他のLighthouseの監査とは異なり、アクセシビリティ監査に部分的に合格してもページはポイントをもらえません。例えば、いくつかの要素がスクリーンリーダーに優しい名前を持っていて他の要素がそうでない場合、そのページはscreenreader-friendly-names監査で0点を獲得します。

    - 図22. CMSページのLighthouseアクセシビリティカテゴリスコアの分布。 + 図22. CMSページのLighthouseアクセシビリティカテゴリスコアの分布。
    図 22. CMSページのLighthouseアクセシビリティカテゴリスコアの分布。
    - 図23. CMSごとのLighthouseアクセシビリティカテゴリスコアの中央値。 + 図23. CMSごとのLighthouseアクセシビリティカテゴリスコアの中央値。
    図 23. CMSごとのLighthouseアクセシビリティカテゴリスコアの中央値。
    @@ -6491,79 +7249,73 @@

    また、ホスティングプロバイダーや代理店が企業の顧客に焦点を当てた戦略のためのツールボックスとして、CMSやその他の統合技術を使用した総合的なソリューションとしてデジタルエクスペリエンスプラットフォーム（DXP）を提供しているのも見受けられます。これらのイノベーションは、ユーザー（とそのエンドユーザー）がこれらのプラットフォームのコンテンツを作成し、消費する際に最高のUXを得ることを可能にするターンキーのCMSベースのソリューションを作成するための努力を示しています。目的は、デフォルトでの優れたパフォーマンス、豊富な機能、優れたホスティング環境です。

    結論

    CMS空間は最も重要な意味を持っています。これらのアプリケーションが力を発揮するウェブの大部分と様々なデバイスや接続でページを作成し、それに遭遇するユーザーの数は、些細なことであってはなりません。この章やこのWeb Almanacに掲載されている他の章が、この空間をより良いものにするためのより多くの研究と技術革新を促してくれることを願っています。深い調査を行うことで、これらのプラットフォームがウェブ全体に提供する強み、弱み、機会について、より良いコンテキストを提供できます。コンテンツ管理システムは、オープン・ウェブの完全性を維持するために影響を与えることができます。コンテンツ管理システムを前進させていきましょう！

    -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":15,"title":"圧縮","description":"HTTP圧縮、アルゴリズム、コンテンツタイプ、ファーストパーティとサードパーティの圧縮および機会をカバーする2019 Web Almanacの圧縮の章。","authors":["paulcalvano"],"reviewers":["obto","yoavweiss"],"translators":["ksakae"],"discuss":"1770","results":"https://docs.google.com/spreadsheets/d/1IK9kaScQr_sJUwZnWMiJcmHEYJV292C9DwCfXH6a50o/","queries":"15_Compression","published":"2019-11-11","last_updated":"2020-05-19","chapter":"compression"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 15 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - 圧縮 +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":15,"title":"圧縮","description":"HTTP圧縮、アルゴリズム、コンテンツタイプ、ファーストパーティとサードパーティの圧縮および機会をカバーする2019 Web Almanacの圧縮の章。","authors":["paulcalvano"],"reviewers":["obto","yoavweiss"],"translators":["ksakae"],"discuss":"1770","results":"https://docs.google.com/spreadsheets/d/1IK9kaScQr_sJUwZnWMiJcmHEYJV292C9DwCfXH6a50o/","queries":"15_Compression","published":"2019-11-11","last_updated":"2020-05-19","chapter":"compression"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -6572,13 +7324,16 @@

    - + -
    {{ self.written_by_before() }} Paul Calvano{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} David Fox, {{ self.and() }} Yoav Weiss{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    HTTP圧縮は、元の表現よりも少ないビットを使用して情報をエンコードできる技術です。 Webコンテンツの配信に使用すると、Webサーバーはクライアントに送信されるデータ量を削減できます。これにより、クライアントの利用可能な帯域幅の効率が向上し、ページの重さが軽減され、Webパフォーマンスが向上します。

    圧縮アルゴリズムは、多くの場合、非可逆または可逆に分類されます。

    @@ -6589,9 +7344,10 @@

    この章では、テキストベースのコンテンツがWeb上でどのように圧縮されるかを検討します。非テキストベースのコンテンツの分析は、メディアの章の一部を形成します。

    HTTP圧縮の仕組み

    - クライアントがHTTPリクエストを作成する場合、多くの場合、デコード可能な圧縮アルゴリズムを示すAccept-Encodingヘッダーが含まれます。サーバーは、示されたエンコードのいずれかを選択してサポートし、圧縮されたレスポンスを提供できます。圧縮されたレスポンスにはContent-Encodingヘッダーが含まれるため、クライアントはどの圧縮が使用されたかを認識できます。また、提供されるリソースのMIMEタイプを示すために、Content-TypeAccept-Encodinghttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encodingヘッダーが含まれます。サーバーは、示されたエンコードのいずれかを選択してサポートし、圧縮されたレスポンスを提供できます。圧縮されたレスポンスにはContent-Encodinghttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encodingヘッダーが含まれるため、クライアントはどの圧縮が使用されたかを認識できます。また、提供されるリソースのMIMEhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_typesタイプを示すために、Content-Typehttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Typeヘッダーがよく使用されます。

    以下の例では、クライアントはgzip、brotli、およびdeflate圧縮のサポートを示してます。サーバーは、text/htmlドキュメントを含むgzip圧縮された応答を返すことにしました。

    @@ -6604,11 +7360,28 @@

    圧縮アルゴリズム

    -

    IANAは、Accept-EncodingおよびContent-Encodingヘッダーで使用できる有効なHTTPコンテンツエンコーディングのリストを保持しています。これらには、gzip、deflate、br（brotli）などが含まれます。これらのアルゴリズムの簡単な説明を以下に示します。

    +

    + IANAは、Accept-EncodingおよびContent-Encodingヘッダーで使用できる有効なHTTPコンテンツエンコーディングのリストhttps://www.iana.org/assignments/http-parameters/http-parameters.xml#content-codingを保持しています。これらには、gzip、deflate、br（brotli）などが含まれます。これらのアルゴリズムの簡単な説明を以下に示します。 +

    HTTPレスポンスの約38％はテキストベースの圧縮で配信されます。これは驚くべき統計のように思えるかもしれませんが、データセット内のすべてのHTTP要求に基づいていることに留意してください。画像などの一部のコンテンツは、これらの圧縮アルゴリズムの恩恵を受けません。次の表は、各コンテンツエンコーディングで処理されるリクエストの割合をまとめたものです。

    @@ -6702,7 +7475,7 @@

    - 図2.デスクトップページでの圧縮アルゴリズムの採用。 + 図2.デスクトップページでの圧縮アルゴリズムの採用。
    図 2.デスクトップページでの圧縮アルゴリズムの採用。
    @@ -6710,7 +7483,11 @@

    多くのWebサーバーのデフォルトにもかかわらず、Nginxは依然として低すぎることが多いレベル1のままです。 +
  • + 少なくとも、テキストベースのアセットに対してgzip圧縮レベル6を有効にします。これは、計算コストと圧縮率の間の公平なトレードオフを提供し、多くのWebサーバーのデフォルトhttps://paulcalvano.com/index.php/2018/07/25/brotli-compression-how-much-will-it-reduce-your-content/にもかかわらず、Nginxは依然として低すぎることが多いレベル1のままですhttp://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_comp_level。 +
  • brotliおよびprecompressリソースをサポートできる場合は、brotliレベル11に圧縮します。これはgzipよりも計算コストが高くなります。したがって、遅延を避けるためには、事前圧縮が絶対に必要です。
  • brotliをサポートでき、事前圧縮できない場合は、brotliレベル5に圧縮します。このレベルでは、gzipと比較してペイロードが小さくなり、同様の計算オーバーヘッドが発生します。
    • @@ -6719,7 +7496,7 @@

    - 図3.上位25の圧縮コンテンツタイプ。 + 図3.上位25の圧縮コンテンツタイプ。
    図 3.上位25の圧縮コンテンツタイプ。
    @@ -6727,7 +7504,7 @@

    - 図4.トップ8を除く圧縮コンテンツタイプ + 図4.トップ8を除く圧縮コンテンツタイプ
    図 4.トップ8を除く圧縮コンテンツタイプ
    @@ -6737,14 +7514,14 @@

    - 図5.デスクトップのコンテンツタイプによる圧縮。 + 図5.デスクトップのコンテンツタイプによる圧縮。
    図 5.デスクトップのコンテンツタイプによる圧縮。

    - 図6.モバイルのコンテンツタイプによる圧縮。 + 図6.モバイルのコンテンツタイプによる圧縮。
    図 6.モバイルのコンテンツタイプによる圧縮。
    @@ -6752,14 +7529,14 @@

    - 図7.コンテンツタイプによる圧縮のデスクトップ割合。 + 図7.コンテンツタイプによる圧縮のデスクトップ割合。
    図 7.コンテンツタイプによる圧縮のデスクトップ割合。

    - 図8.コンテンツタイプによる圧縮のモバイル割合。 + 図8.コンテンツタイプによる圧縮のモバイル割合。
    図 8.コンテンツタイプによる圧縮のモバイル割合。
    @@ -6829,10 +7606,14 @@

    図 9.デバイスタイプ別のファーストパーティとサードパーティの圧縮。

    圧縮の機会を見分ける

    -

    GoogleのLighthouseツールを使用すると、ユーザーはWebページに対して一連の監査を実行できます。テキスト圧縮監査は、サイトが追加のテキストベースの圧縮の恩恵を受けることができるかどうかを評価します。これは、リソースを圧縮し、オブジェクトのサイズを少なくとも10％と1,400バイト削減できるかどうかを評価することでこれを行います。スコアに応じて、圧縮可能な特定のリソースのリストとともに、結果に圧縮の推奨事項を表示する場合があります。

    +

    + GoogleのLighthousehttps://developers.google.com/web/tools/lighthouseツールを使用すると、ユーザーはWebページに対して一連の監査を実行できます。テキスト圧縮監査https://developers.google.com/web/tools/lighthouse/audits/text-compressionは、サイトが追加のテキストベースの圧縮の恩恵を受けることができるかどうかを評価します。これは、リソースを圧縮し、オブジェクトのサイズを少なくとも10％と1,400バイト削減できるかどうかを評価することでこれを行います。スコアに応じて、圧縮可能な特定のリソースのリストとともに、結果に圧縮の推奨事項を表示する場合があります。 +

    - 図10.Lighthouse圧縮の提案 + 図10.Lighthouse圧縮の提案
    図 10.Lighthouse圧縮の提案
    @@ -6840,7 +7621,7 @@

    HTTP ArchiveはLighthouse監査を実行するため、すべてのサイトのスコアを集計して、より多くのコンテンツを圧縮する機会があるかどうかを知ることができます。全体として、ウェブサイトの62％がこの監査に合格しており、ウェブサイトのほぼ23％が40を下回っています。これは、120万を超えるウェブサイトが追加のテキストベースの圧縮を有効にすることを意味します。

    - 図11. Lighthouseの「テキスト圧縮を有効にする」監査スコア。 + 図11. Lighthouseの「テキスト圧縮を有効にする」監査スコア。
    図 11. Lighthouseの「テキスト圧縮を有効にする」監査スコア。
    @@ -6848,7 +7629,7 @@

    - 図12.潜在的なバイト削減を監査するLighthouseの「テキスト圧縮を有効にする」 + 図12.潜在的なバイト削減を監査するLighthouseの「テキスト圧縮を有効にする」
    図 12.潜在的なバイト削減を監査するLighthouseの「テキスト圧縮を有効にする」
    @@ -6857,50 +7638,73 @@

    HTTP圧縮は、Webコンテンツのサイズを削減するために広く使用されている非常に貴重な機能です。 gzipとbrotliの両方の圧縮が使用される主要なアルゴリズムであり、圧縮されたコンテンツの量はコンテンツの種類によって異なります。 Lighthouseなどのツールは、コンテンツを圧縮する機会を発見するのに役立ちます。

    多くのサイトがHTTP圧縮をうまく利用していますが、特にWebが構築されているtext/html形式については、まだ改善の余地があります！　同様に、font/ttf、application/json、text/xml、text/plain、image/svg+xml、image/x-iconのようなあまり理解されていないテキスト形式は、多くのWebサイトで見落とされる余分な構成を取る場合があります。

    Webサイトは広くサポートされており、簡単に実装で処理のオーバーヘッドが低いため、少なくともすべてのテキストベースのリソースにgzip圧縮を使用する必要があります。 brotli圧縮を使用するとさらに節約できますが、リソースを事前に圧縮できるかどうかに基づいて圧縮レベルを慎重に選択する必要があります。

    -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":16,"title":"キャッシング","description":"2019 Web Almanacのキャッシュの章は、キャッシュコントロール、有効期限、TTL、有効性、変化、Cookieの設定、アプリケーションキャッシュ、Service Worker、および機会について説明します。","authors":["paulcalvano"],"reviewers":["obto","bkardell"],"translators":["ksakae"],"discuss":"1771","results":"https://docs.google.com/spreadsheets/d/1mnq03DqrRBwxfDV05uEFETK0_hPbYOynWxZkV3tFgNk/","queries":"16_Caching","published":"2019-11-11","last_updated":"2020-05-19","chapter":"caching"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 16 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - キャッシング +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":16,"title":"キャッシング","description":"2019 Web Almanacのキャッシュの章は、キャッシュコントロール、有効期限、TTL、有効性、変化、Cookieの設定、アプリケーションキャッシュ、Service Worker、および機会について説明します。","authors":["paulcalvano"],"reviewers":["obto","bkardell"],"translators":["ksakae"],"discuss":"1771","results":"https://docs.google.com/spreadsheets/d/1mnq03DqrRBwxfDV05uEFETK0_hPbYOynWxZkV3tFgNk/","queries":"16_Caching","published":"2019-11-11","last_updated":"2020-05-19","chapter":"caching"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -6909,20 +7713,26 @@

    - + -
    {{ self.written_by_before() }} Paul Calvano{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} David Fox, {{ self.and() }} Brian Kardell{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    キャッシングは、以前にダウンロードしたコンテンツの再利用を可能にする手法です。コストのかかるネットワークリクエストを回避することにより、パフォーマンスが大幅に向上します。また、Webサイトのオリジンインフラストラクチャへのトラフィックを削減することで、アプリケーションの拡張にも役立ちます。「最速のリクエストはあなたがする必要のないものです」という古い格言があり、キャッシュはリクエストを行わなくて済むようにするための重要な方法の1つです。

    Webコンテンツのキャッシュには、3つの基本原則があります。可能な限りキャッシュする、できる限りキャッシュする、エンドユーザーのできるだけ近くでキャッシュする。

    可能な限りキャッシュする。 キャッシュできる量を検討する場合、レスポンスが静的か動的かを理解することが重要です。静的なレスポンスとして提供される要求は、リソースとそれを要求するユーザーとの間に1対多の関係があるため、通常はキャッシュ可能です。動的に生成されたコンテンツはより微妙である可能性があり、慎重に検討する必要があります。

    できるだけ長くキャッシュする。リソースをキャッシュする時間の長さは、キャッシュされるコンテンツの機密性に大きく依存します。バージョン管理されたJavaScriptリソースは非常に長い時間キャッシュされる可能性がありますが、バージョン管理されていないリソースはユーザーが最新バージョンを取得できるように、より短いキャッシュ期間を必要とする場合があります。

    エンドユーザーのできるだけ近くでキャッシュする。エンドユーザーの近くでコンテンツをキャッシュすると、待ち時間がなくなり、ダウンロード時間が短縮されます。たとえば、リソースがエンドユーザーのブラウザにキャッシュされている場合、リクエストはネットワークに送信されず、ダウンロード時間はマシンのI/Oと同じくらい高速です。初めての訪問者、またはキャッシュにエントリがない訪問者の場合、通常、キャッシュされたリソースが返される場所はCDNになります。ほとんどの場合、オリジンサーバーと比較して、ローカルキャッシュかCDNからリソースをフェッチする方が高速です。

    -

    通常、Webアーキテクチャには複数のキャッシュ層が含まれます。たとえば、HTTPリクエストは次の場所にキャッシュされる可能性があります。

    +

    + 通常、Webアーキテクチャには複数のキャッシュ層https://blog.yoav.ws/tale-of-four-caches/が含まれます。たとえば、HTTPリクエストは次の場所にキャッシュされる可能性があります。 +

    • エンドユーザーのブラウザ
    • ユーザーのブラウザーのService Workerキャッシュ
      • @@ -6938,7 +7748,11 @@

      4.2（新しさ）および4.3（検証）でより詳細にカバーしています。

      +

      + Webブラウザーがクライアントにレスポンスを送信するとき、通常リソースにキャッシュ可能か、キャッシュする期間、リソースの古さを示すヘッダーが含まれます。 RFC 7234は、これをセクション4.2（新しさ）https://tools.ietf.org/html/rfc7234#section-4.2および4.3（検証）https://tools.ietf.org/html/rfc7234#section-4.3でより詳細にカバーしています。 +

      通常、有効期間を伝えるために使用されるHTTPレスポンスヘッダーは次のとおりです。

      • Cache-Control キャッシュの生存期間（つまり、有効期間）を設定できます。
        • @@ -6967,19 +7781,26 @@

        -

        RedBot.orgというツールにURLを入力すると、レスポンスのヘッダーを元としたキャッシュ方法の詳細な説明が表示できます。たとえば、上記のURLのテストは次のような内容を出力します。

        +

        + RedBot.orghttps://redbot.org/というツールにURLを入力すると、レスポンスのヘッダーを元としたキャッシュ方法の詳細な説明が表示できます。たとえば、上記のURLのテストhttps://redbot.org/?uri=https%3A%2F%2Fhttparchive.org%2Fstatic%2Fjs%2Fmain.jsは次のような内容を出力します。 +

        - 図1. RedBotからのCache-Control情報。 + 図1. RedBotからのCache-Control情報。
        図 1. ロボットからのCache-Control情報
        -

        レスポンスにキャッシュヘッダーが存在しない場合、クライアントはレスポンスをヒューリスティクスにキャッシュできます。ほとんどのクライアントは、RFCの推奨ヒューリスティックバリエーションを実装します。これは、Last-Modifiedから経過した時間の10％です。ただし、レスポンスを無期限にキャッシュする可能性もあります。そのため、特定のキャッシュルールを設定して、キャッシュ可能性を確実に制御することが重要です。

        +

        + レスポンスにキャッシュヘッダーが存在しない場合、クライアントはレスポンスをヒューリスティクスにキャッシュできますhttps://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/。ほとんどのクライアントは、RFCの推奨ヒューリスティックバリエーションを実装します。これは、Last-Modifiedから経過した時間の10％です。ただし、レスポンスを無期限にキャッシュする可能性もあります。そのため、特定のキャッシュルールを設定して、キャッシュ可能性を確実に制御することが重要です。 +

        レスポンスの72％はCache-Controlヘッダーで提供され、レスポンスの56％はExpiresヘッダーで提供されます。ただし、レスポンスの27％はどちらのヘッダーも使用していないため、ヒューリスティックキャッシュの対象となります。これは、デスクトップとモバイルサイトの両方で一貫しています。

        - 図2. HTTP Cache-ControlおよびExpiresヘッダーの存在 + 図2. HTTP Cache-ControlおよびExpiresヘッダーの存在
        図 2. HTTP Cache-ControlおよびExpiresヘッダーの存在
        @@ -6994,7 +7815,7 @@

        残りのレスポンスは、ブラウザーのキャッシュに保存できません。

        - 図3.キャッシュ可能なレスポンスの分布。 + 図3.キャッシュ可能なレスポンスの分布。
        図 3.キャッシュ可能なレスポンスの分布。
        @@ -7109,7 +7930,7 @@

        以下の図5でコンテンツタイプごとのキャッシュ可能性を詳細に調べると、すべてのHTMLレスポンスの約半分がキャッシュ不可と見なされていることがわかります。さらに、画像とスクリプトの16％はキャッシュ不可です。

        - 図5.デスクトップのコンテンツタイプごとのキャッシュ可能性の分布。 + 図5.デスクトップのコンテンツタイプごとのキャッシュ可能性の分布。
        図 5.デスクトップのコンテンツタイプごとのキャッシュ可能性の分布。
        @@ -7117,7 +7938,7 @@

        モバイルの同じデータを以下に示します。ご覧のとおり、コンテンツタイプのキャッシュ可能性はデスクトップとモバイルで一貫しています。

        - 図6.モバイルのコンテンツタイプ別のキャッシュ可能性の分布。 + 図6.モバイルのコンテンツタイプ別のキャッシュ可能性の分布。
        図 6.モバイルのコンテンツタイプ別のキャッシュ可能性の分布。
        @@ -7135,13 +7956,16 @@

        - 図7. Cache-ControlとExpiresヘッダーの使用法。 + 図7. Cache-ControlとExpiresヘッダーの使用法。
        図 7. Cache-ControlとExpiresヘッダーの使用法。

        Cache-Controlディレクティブ

        -

        HTTP/1.1仕様には、Cache-Controlレスポンスヘッダーで使用できる複数のディレクティブが含まれており、以下で詳しく説明します。1つのレスポンスで複数を使用できることに注意してください。

        +

        + HTTP/1.1仕様https://tools.ietf.org/html/rfc7234#section-5.2.1には、Cache-Controlレスポンスヘッダーで使用できる複数のディレクティブが含まれており、以下で詳しく説明します。1つのレスポンスで複数を使用できることに注意してください。 +

        @@ -7208,7 +8032,7 @@

        - 図9.モバイルでのCache-Controlディレクティブの使用。 + 図9.モバイルでのCache-Controlディレクティブの使用。
        図 9.モバイルでのCache-Controlディレクティブの使用。
        @@ -7217,9 +8041,17 @@

        2017年に導入され、FirefoxおよびSafariでサポートされています。その使用率は3.4％に拡大し、Facebook、Googleのサードパーティのレスポンスで広く使用されています。 +
      • + immutableディレクティブは比較的新しく、2017年に導入https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebookされ、FirefoxおよびSafariでサポートhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibilityされています。その使用率は3.4％に拡大し、Facebook、Googleのサードパーティのレスポンスhttps://discuss.httparchive.org/t/cache-control-immutable-a-year-later/1195で広く使用されています。 +

      -

      このリストに表示される別の興味深いディレクティブセットは、pre-checkとpost-checkです。これらは、Cache-Controlレスポンスヘッダーの2.2％（約780万件のレスポンス）で使用されます。このヘッダーのペアは、バックグラウンドで検証を提供するためにInternet Explorer 5で導入されたものですが、Webサイトによって正しく実装されることはほとんどありませんでした。これらのヘッダーを使用したレスポンスの99.2％は、pre-check=0とpost-check=0の組み合わせを使用していました。これらのディレクティブの両方が0に設定されている場合、両方のディレクティブは無視されます。したがって、これらのディレクティブは正しく使用されなかったようです！

      +

      + このリストに表示される別の興味深いディレクティブセットは、pre-checkとpost-checkです。これらは、Cache-Controlレスポンスヘッダーの2.2％（約780万件のレスポンス）で使用されます。このヘッダーのペアは、バックグラウンドで検証を提供するためにInternet Explorer 5で導入されたhttps://blogs.msdn.microsoft.com/ieinternals/2009/07/20/internet-explorers-cache-control-extensions/ものですが、Webサイトによって正しく実装されることはほとんどありませんでした。これらのヘッダーを使用したレスポンスの99.2％は、pre-check=0とpost-check=0の組み合わせを使用していました。これらのディレクティブの両方が0に設定されている場合、両方のディレクティブは無視されます。したがって、これらのディレクティブは正しく使用されなかったようです！ +

      ロングテールでは、レスポンスの0.28％で1,500を超える間違ったディレクティブが使用されています。これらはクライアントによって無視され、「nocache」「s-max-age」「smax-age」「maxage」などのスペルミスが含まれます。「max-stale」「proxy-public」「surrogate-control」など存在しないディレクティブも多数あります。

      Cache-Control: no-store, no-cache and max-age=0

      レスポンスがキャッシュ可能でない場合、Cache-Control no-storeディレクティブを使用する必要があります。このディレクティブを使用しない場合、レスポンスはキャッシュ可能です。

      @@ -7235,10 +8067,13 @@

      キャッシュTTLとリソースの経過時間はどのように比較されますか？

      これまで、Webサーバーがキャッシュ可能なものをクライアントに通知する方法と、キャッシュされる期間について説明してきました。キャッシュルールを設計するときは、提供しているコンテンツの古さを理解することも重要です。

      キャッシュTTLを選択するときは、「これらのアセットをどのくらいの頻度で更新しますか？」と自問してください。そして「彼らのコンテンツの感度は何ですか？」。たとえば、ヒーローのイメージがたまに更新される場合、非常に長いTTLでキャッシュします。 JavaScriptリソースが頻繁に変更されることが予想される場合は、バージョン管理して長いTTLでキャッシュするか、短いTTLでキャッシュします。

      -

      以下のグラフは、コンテンツタイプごとのリソースの相対的な年を示しています。ここで、より詳細な分析を読むことができます。 HTMLは最も短い年齢のコンテンツタイプである傾向があり、伝統的にキャッシュ可能なリソース（スクリプト、CSS、およびフォント）の非常に大きな割合が1年以上古いです！

      +

      + 以下のグラフは、コンテンツタイプごとのリソースの相対的な年を示しています。ここで、より詳細な分析https://discuss.httparchive.org/t/analyzing-resource-age-by-content-type/1659を読むことができます。 HTMLは最も短い年齢のコンテンツタイプである傾向があり、伝統的にキャッシュ可能なリソース（スクリプト、CSS、およびフォント）の非常に大きな割合が1年以上古いです！ +

      - 図10.コンテンツタイプ別のリソース年分布。 + 図10.コンテンツタイプ別のリソース年分布。
      図 10.コンテンツタイプ別のリソース年分布。
      @@ -7316,7 +8151,7 @@

      - 図12.デスクトップWebサイトのLast-ModifiedおよびETa`ヘッダーを介した鮮度の検証の採用。 + 図12.デスクトップWebサイトのLast-ModifiedおよびETa`ヘッダーを介した鮮度の検証の採用。
      図 12.デスクトップWebサイトのLast-ModifiedおよびETagヘッダーを介した鮮度の検証の採用。
      @@ -7344,7 +8179,7 @@

      - 図13.レスポンスヘッダーの無効な日付形式。 + 図13.レスポンスヘッダーの無効な日付形式。
      図 13.レスポンスヘッダーの無効な日付形式。
      @@ -7368,7 +8203,7 @@

      以下のグラフは、上位10個のVaryヘッダー値の人気を示しています。 Accept-EncodingはVaryの使用の90％を占め、User-Agent（11％）、Origin（9％）、Accept（3％）が残りの大部分を占めています。

      - 図14.Varyヘッダーの使用率。 + 図14.Varyヘッダーの使用率。
      図 14.Varyヘッダーの使用率。
      @@ -7377,30 +8212,45 @@

      レスポンスがキャッシュされると、そのヘッダー全体もキャッシュにスワップされます。これが、DevToolsを介してキャッシュされたレスポンスを検査するときにレスポンスヘッダーを表示できる理由です。

      - 図15.キャッシュされたリソースのChrome開発ツール。 + 図15.キャッシュされたリソースのChrome開発ツール。
      図 15.キャッシュされたリソースのChrome開発ツール。
      -

      しかし、レスポンスにSet-Cookieがある場合はどうなりますか？ RFC 7234セクション8によると、Set-Cookieレスポンスヘッダーはキャッシングを禁止しません。これは、キャッシュされたエントリがSet-Cookieでキャッシュされている場合、それが含まれている可能性があることを意味します。 RFCでは、適切なCache-Controlヘッダーを構成して、レスポンスのキャッシュ方法を制御することを推奨しています。

      +

      + しかし、レスポンスにSet-Cookieがある場合はどうなりますか？ RFC 7234セクション8https://tools.ietf.org/html/rfc7234#section-8によると、Set-Cookieレスポンスヘッダーはキャッシングを禁止しません。これは、キャッシュされたエントリがSet-Cookieでキャッシュされている場合、それが含まれている可能性があることを意味します。 RFCでは、適切なCache-Controlヘッダーを構成して、レスポンスのキャッシュ方法を制御することを推奨しています。 +

      Set-Cookieを使用してレスポンスをキャッシュすることのリスクの1つは、Cookieの値を保存し、後続の要求に提供できることです。 Cookieの目的によっては、心配な結果になる可能性があります。たとえば、ログインCookieまたはセッションCookieが共有キャッシュに存在する場合、そのCookieは別のクライアントによって再利用される可能性があります。これを回避する1つの方法は、Cache-Control``プライベートディレクティブを使用することです。これにより、クライアントブラウザーによるレスポンスのキャッシュのみが許可されます。

      キャッシュ可能なレスポンスの3％にSet-Cookieヘッダーが含まれています。これらのレスポンスのうち、プライベートディレクティブを使用しているのは18％のみです。残りの82％には、パブリックおよびプライベートキャッシュサーバーでキャッシュできるSet-Cookieを含む530万のHTTPレスポンスが含まれています。

      - 図16. Set-Cookieレスポンスのキャッシュ可能なレスポンス。 + 図16. Set-Cookieレスポンスのキャッシュ可能なレスポンス。
      図 16. Set-Cookieレスポンスのキャッシュ可能なレスポンス。

      AppCacheおよびService Worker

      -

      アプリケーションキャッシュまたはAppCacheはHTML5の機能であり、開発者はブラウザがキャッシュするリソースを指定し、オフラインユーザーが利用できるようにできます。この機能は廃止されており、Web標準からも削除され、ブラウザーのサポートは減少しています。実際、使われているのが見つかった場合、Firefox v44 +は、開発者に対して代わりにService Workerを使用することを推奨しています。 Chrome 70は、アプリケーションキャッシュをセキュリティで保護されたコンテキストのみに制限します。業界では、このタイプの機能をService Workerに実装する方向へ移行しており、ブラウザサポートは急速に成長しています。

      -

      実際、HTTP Archiveトレンドレポートの1つは、以下に示すService Workerの採用を示しています。

      +

      + アプリケーションキャッシュまたはAppCacheはHTML5の機能であり、開発者はブラウザがキャッシュするリソースを指定し、オフラインユーザーが利用できるようにできます。この機能は廃止されており、Web標準からも削除https://html.spec.whatwg.org/multipage/offline.html#offlineされ、ブラウザーのサポートは減少しています。実際、使われているのが見つかった場合、Firefox v44 +は、開発者に対して代わりにService Workerを使用することを推奨していますhttps://developer.mozilla.org/ja-JP/docs/Web/API/Service_Worker_API/Using_Service_Workers。 Chrome 70は、アプリケーションキャッシュをセキュリティで保護されたコンテキストのみに制限しますhttps://www.chromestatus.com/feature/5714236168732672。業界では、このタイプの機能をService Workerに実装する方向へ移行しており、ブラウザサポートhttps://caniuse.com/#feat=serviceworkersは急速に成長しています。 +

      +

      + 実際、HTTP Archiveトレンドレポートの1つは、以下に示すService Workerhttps://httparchive.org/reports/progressive-web-apps#swControlledPagesの採用を示しています。 +

      - 図17.Service Workerが制御するページの時系列。 + 図17.Service Workerが制御するページの時系列。 -
      図 17.Service Workerが制御するページの時系列。 (引用: HTTP Archive)
      +
      + 図 17.Service Workerが制御するページの時系列。 (引用: HTTP Archivehttps://httparchive.org/reports/progressive-web-apps#swControlledPages) +

      採用率はまだウェブサイトの1％を下回っていますが、2017年1月から着実に増加しています。プログレッシブWebアプリの章では、人気サイトでの使用によりこのグラフが示唆するよりも多く使用されているという事実を含め、上記のグラフでは1回のみカウントされます。

      次の表では、AppCacheとService Workerの使用状況の概要を確認できます。 32,292のWebサイトでService Workerが実装されていますが、1,867のサイトでは非推奨のAppCache機能が引き続き使用されています。

      @@ -7484,18 +8334,25 @@

      図 19. AppCacheを使用するWebサイト数とHTTP/HTTPSによるService Workerの使用量。

      キャッシングの機会を特定する

      -

      GoogleのLighthouseツールを使用すると、ユーザーはWebページに対して一連の監査を実行できます。キャッシュポリシー監査では、サイトが追加のキャッシュの恩恵を受けることができるかどうかを評価します。これは、コンテンツの経過時間（Last-Modifiedヘッダー経由）をキャッシュTTLと比較し、リソースがキャッシュから提供される可能性を推定することによりこれを行います。スコアに応じて、結果にキャッシュの推奨事項が表示され、キャッシュできる特定のリソースのリストが表示される場合があります。

      +

      + GoogleのLighthousehttps://developers.google.com/web/tools/lighthouseツールを使用すると、ユーザーはWebページに対して一連の監査を実行できます。キャッシュポリシー監査https://developers.google.com/web/tools/lighthouse/audits/cache-policyでは、サイトが追加のキャッシュの恩恵を受けることができるかどうかを評価します。これは、コンテンツの経過時間（Last-Modifiedヘッダー経由）をキャッシュTTLと比較し、リソースがキャッシュから提供される可能性を推定することによりこれを行います。スコアに応じて、結果にキャッシュの推奨事項が表示され、キャッシュできる特定のリソースのリストが表示される場合があります。 +

      - 図20.キャッシュポリシーの改善の可能性を強調したLighthouseレポート。 + 図20.キャッシュポリシーの改善の可能性を強調したLighthouseレポート。
      図 20.キャッシュポリシーの改善の可能性を強調したLighthouseレポート。
      -

      Lighthouseは、監査ごとに0％〜100％の範囲のスコアを計算し、それらのスコアは全体のスコアに組み込まれます。キャッシングスコアは、潜在的なバイト節約に基づいています。 Lighthouseの結果を調べると、キャッシュポリシーでどれだけのサイトがうまく機能しているかを把握できます。

      +

      + Lighthouseは、監査ごとに0％〜100％の範囲のスコアを計算し、それらのスコアは全体のスコアに組み込まれます。キャッシングスコアhttps://developers.google.com/web/tools/lighthouse/audits/cache-policyは、潜在的なバイト節約に基づいています。 Lighthouseの結果を調べると、キャッシュポリシーでどれだけのサイトがうまく機能しているかを把握できます。 +

      - 図21.モバイルWebページの「Use Long Cache TTL」監査のLighthouseスコアの分布。 + 図21.モバイルWebページの「Use Long Cache TTL」監査のLighthouseスコアの分布。
      図 21.モバイルWebページの「Use Long Cache TTL」監査のLighthouseスコアの分布。
      @@ -7504,58 +8361,85 @@

      - 図22. Lighthouseキャッシング監査による潜在的なバイト節約の分布。 + 図22. Lighthouseキャッシング監査による潜在的なバイト節約の分布。
      図 22. Lighthouseキャッシング監査による潜在的なバイト節約の分布。

      結論

      キャッシングは非常に強力な機能であり、ブラウザ、プロキシ、その他の仲介者（CDNなど）がWebコンテンツを保存し、エンドユーザーへ提供できるようにします。これにより、往復時間が短縮され、コストのかかるネットワーク要求が最小限に抑えられるため、パフォーマンス上のメリットは非常に大きくなります。

      -

      キャッシュも非常に複雑なトピックです。キャッシュエントリを検証するだけでなく、新鮮さを伝えることができるHTTPレスポンスヘッダーは多数あります。Cache-Controlディレクティブは、非常に多くの柔軟性と制御を提供します。ただし、開発者は、それがもたらす間違いの追加の機会に注意する必要があります。キャッシュ可能なリソースが適切にキャッシュされていることを確認するためにサイトを定期的に監査することをお勧めします。LighthouseやREDbotなどのツールは、分析の簡素化に役立ちます。

      -
    +

    + キャッシュも非常に複雑なトピックです。キャッシュエントリを検証するだけでなく、新鮮さを伝えることができるHTTPレスポンスヘッダーは多数あります。Cache-Controlディレクティブは、非常に多くの柔軟性と制御を提供します。ただし、開発者は、それがもたらす間違いの追加の機会に注意する必要があります。キャッシュ可能なリソースが適切にキャッシュされていることを確認するためにサイトを定期的に監査することをお勧めします。Lighthousehttps://developers.google.com/web/tools/lighthouseやREDbothttps://redbot.org/などのツールは、分析の簡素化に役立ちます。 +

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":17,"title":"CDN","description":"CDNの採用と使用法、RTTとTLSの管理、HTTP/2の採用、キャッシング、および共通ライブラリとコンテンツCDNをカバーする2019 Web AlmanacのCDNの章。","authors":["andydavies","colinbendell"],"reviewers":["yoavweiss","paulcalvano","pmeenan","enygren"],"translators":["ksakae"],"discuss":"1772","results":"https://docs.google.com/spreadsheets/d/1Y7kAxjxUl8puuTToe6rL3kqJLX1ftOb0nCcD8m3lZBw/","queries":"17_CDN","published":"2019-11-11","last_updated":"2020-05-19","chapter":"cdn"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 17 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - CDN +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":17,"title":"CDN","description":"CDNの採用と使用法、RTTとTLSの管理、HTTP/2の採用、キャッシング、および共通ライブラリとコンテンツCDNをカバーする2019 Web AlmanacのCDNの章。","authors":["andydavies","colinbendell"],"reviewers":["yoavweiss","paulcalvano","pmeenan","enygren"],"translators":["ksakae"],"discuss":"1772","results":"https://docs.google.com/spreadsheets/d/1Y7kAxjxUl8puuTToe6rL3kqJLX1ftOb0nCcD8m3lZBw/","queries":"17_CDN","published":"2019-11-11","last_updated":"2020-05-19","chapter":"cdn"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -7564,15 +8448,21 @@

    - + -
    {{ self.written_by_before() }} Andy Davies, {{ self.and() }} Colin Bendell{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Yoav Weiss, Paul Calvano, Patrick Meenan, {{ self.and() }} Erik Nygren{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    -

    「コンテンツ配信ネットワーク」は、Webサイトの読み込みを高速化するためのSteve Soudersによる独自の推奨事項の1つでした。昨今でも有効なアドバイスです。Web Almanacのこの章ではSteveの推奨事項がどの程度広く採用されているか、サイトがコンテンツ配信ネットワーク（CDN）をどのように使用しているか、およびそれらが使用している機能のいくつかを検討します。

    +

    + 「コンテンツ配信ネットワーク」は、Webサイトの読み込みを高速化するためのSteve Soudersによる独自の推奨事項http://stevesouders.com/examples/rules.phpの1つでした。昨今でも有効なアドバイスです。Web Almanacのこの章ではSteveの推奨事項がどの程度広く採用されているか、サイトがコンテンツ配信ネットワーク（CDN）をどのように使用しているか、およびそれらが使用している機能のいくつかを検討します。 +

    基本的にCDNは待ち時間（パケットがネットワーク上の2つのポイント間、たとえば訪問者のデバイスからサーバーに移動する時間）を短縮します、待ち時間はページの読み込み速度の重要な要素です。

    CDNは、2つの方法で待機時間を短縮します。ユーザーに近い場所からコンテンツを提供すること、2番目はエンドユーザーに近いTCP接続を終了することです。

    歴史的にユーザーからバイトへの論理パスが短くなるように、CDNはバイトのキャッシュまたはコピーに使用されていました。多くの人が要求するファイルは、origin（サーバー）から一度取得してユーザーに近いサーバーへ保存できるため、転送時間を節約できます。

    @@ -7582,7 +8472,10 @@

    導入

  • CDNを使用して動的コンテンツ（ベースHTMLページ、API応答など）をプロキシすることにより、ブラウザーとCDN自身のネットワークとの間の遅延が短縮され、元の速度に戻ることができます。
  • 一部のCDNは、ページを最適化してダウンロードとレンダリングを高速化する変換を提供するか、画像を最適化して表示するデバイスに適したサイズ（画像の大きさとファイルサイズの両方）に変換します。
  • セキュリティの観点から、悪意のあるトラフィックとボットは要求がoriginへ到達する前にCDNによって除外される可能性があり、その幅広い顧客ベースによりCDNが新しい脅威をより早く発見して対応できることを意味します。
    • -
  • エッジコンピューティングの台頭により、サイトは訪問者の近くで独自のコードを実行できるようになりパフォーマンスが向上し、originの負荷が軽減されました。
    • +
  • + エッジコンピューティングhttps://en.wikipedia.org/wiki/Edge_computingの台頭により、サイトは訪問者の近くで独自のコードを実行できるようになりパフォーマンスが向上し、originの負荷が軽減されました。 +

    • 最後にCDNもまた、originサーバーがサポートしていない場合でもエッジからブラウザーまでHTTP/2、TLS1.3、またはIPv6を有効にできるなどoriginでの変更を必要とせずにサイトが新しいテクノロジーを採用できるようにします。

    警告と免責事項

    @@ -7590,10 +8483,16 @@

    方法には多くの制限があります。これらには以下が含まれます。

    • シミュレートされたネットワーク遅延：Web Almanacは、トラフィックを総合的に形成する専用ネットワーク接続を使用します。
      • -
    • 単一の地理的場所：テストは単一のデータセンターから実行されるため、多くのCDNベンダーの地理的分布をテストすることはできません。
      • +
    • + 単一の地理的場所：テストは単一のデータセンターhttps://httparchive.org/faq#how-is-the-data-gatheredから実行されるため、多くのCDNベンダーの地理的分布をテストすることはできません。 +
    • キャッシュの有効性：各CDNは独自の技術を使用しており、多くの場合、セキュリティ上の理由により、キャッシュのパフォーマンスは公開されていません。
    • ローカライゼーションと国際化：地理的分布と同様に言語、地理固有のドメインの影響もテストに対して不透明です。
      • -
    • CDN検出は、主にDNS解決とHTTPヘッダーを介して行われます。ほとんどのCDNは、DNS CNAMEを使用してユーザーを最適なデータセンターにマッピングします。ただし、一部のCDNはAnyCast IPを使用するか、DNSチェインを隠す委任されたドメインからのA+AAAA応答を直接使用します。それ以外の場合、Webページは複数のCDNを使用して、WebPageTestのシングルリクエストパスから隠されているベンダー間でバランスを取ります。これらはすべて、測定の有効性を制限します。
      • +
    • + CDN検出https://github.com/WPO-Foundation/wptagent/blob/master/internal/optimization_checks.py#L51は、主にDNS解決とHTTPヘッダーを介して行われます。ほとんどのCDNは、DNS CNAMEを使用してユーザーを最適なデータセンターにマッピングします。ただし、一部のCDNはAnyCast IPを使用するか、DNSチェインを隠す委任されたドメインからのA+AAAA応答を直接使用します。それ以外の場合、Webページは複数のCDNを使用して、WebPageTestのシングルリクエストパスから隠されているベンダー間でバランスを取ります。これらはすべて、測定の有効性を制限します。 +

    最も重要なことは、これらの結果は潜在的な使用率を反映しているが、実際の影響を反映していないことです。 YouTubeは「ShoesByColin」よりも人気がありますが、使用率を比較するとどちらも同じ値として表示されます。

    これを念頭に置いて、CDNのコンテキストで測定されなかったいくつかの意図的な統計があります。

    @@ -7608,7 +8507,7 @@

    歴史的に、CDNはCSS、JavaScript、画像などの静的リソース専用に使用されていました。これらのリソースはおそらくバージョン管理され（パスに一意の番号を含む）、長期的にキャッシュされます。このようにして、ベースHTMLドメインと比較して、サブドメインまたは兄弟ドメインでのCDNの採用が増加することを期待する必要があります。従来のデザインパターンでは、www.shoesbycolin.comがデータセンター（又はorigin）から直接HTMLを提供し、static.shoesbycolin.comがCDNを使用することを想定していました。

    - 図 1. CDN使用量 vs. originがホストするリソース + 図 1. CDN使用量 vs. originがホストするリソース
    図 1. CDN使用量 vs. originがホストするリソース
    @@ -7622,7 +8521,7 @@

    注：これにはトラフィックや使用量は反映されず、それらを使用するサイトの数のみが反映されます。

    - ベースHTMLページの提供に使用される最も人気のあるCDN + ベースHTMLページの提供に使用される最も人気のあるCDN
    図 2: HTML CDNの使用
    @@ -7747,7 +8646,7 @@

    - サブドメインから提供されるリソースに使用される最も一般的なCDN + サブドメインから提供されるリソースに使用される最も一般的なCDN
    図 4.サブドメインリソースのCDNの使用。
    @@ -7872,7 +8771,7 @@

    - サードパーティのリソースで使用される最も人気のあるCDN + サードパーティのリソースで使用される最も人気のあるCDN
    図 6.サードパーティのリソースCDN使用。
    @@ -7995,7 +8894,11 @@

    図 7.サードパーティのリクエストの上位25のリソースCDN。

    RTTとTLS管理

    -

    CDNは、Webサイトのパフォーマンスのために単純なキャッシング以上のものを提供できます。多くのCDNは、コンテンツのキャッシュを禁止する法的要件またはその他のビジネス要件がある場合、動的またはパーソナライズされたコンテンツのパススルーモードもサポートします。 CDNの物理的な配布を利用すると、エンドユーザーのTCP RTTのパフォーマンスが向上します。他の人が指摘したように、RTTを減らすことは、帯域幅を増やすことに比べてWebページのパフォーマンスを向上させる最も効果的な手段です。

    +

    + CDNは、Webサイトのパフォーマンスのために単純なキャッシング以上のものを提供できます。多くのCDNは、コンテンツのキャッシュを禁止する法的要件またはその他のビジネス要件がある場合、動的またはパーソナライズされたコンテンツのパススルーモードもサポートします。 CDNの物理的な配布を利用すると、エンドユーザーのTCP RTTのパフォーマンスが向上します。他の人が指摘したようにhttps://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/、RTTを減らすことは、帯域幅を増やすことに比べてWebページのパフォーマンスを向上させる最も効果的な手段ですhttps://hpbn.co/primer-on-latency-and-bandwidth/。 +

    この方法でCDNを使用すると、次の2つの方法でページのパフォーマンスを改善できます。

    1. @@ -8010,7 +8913,7 @@

      これらのチャートを解釈する際の注意事項：実際のTLSネゴシエーションのパフォーマンスに影響する多くの要因があるため、ベンダーを比較するとき、桁の違いに焦点を合わせることが重要です。これらのテストは、制御された条件下で単一のデータセンターから完了したものであり、インターネットおよびユーザーエクスペリエンスの変動を反映していません。

      - CDNによって分類された初期HTML要求のTLSネゴシエーション時間の分布 + CDNによって分類された初期HTML要求のTLSネゴシエーション時間の分布
      図 8. HTML TLSネゴシエーション時間。
      @@ -8183,25 +9086,37 @@

      リソース要求（同一ドメインおよびサードパーティを含む）の場合、TLSネゴシエーション時間が長くなり、差異が増加します。これは、ネットワークの飽和とネットワークの輻輳のためと予想されます。サードパーティの接続が確立されるまでに（リソースヒントまたはリソースリクエストにより）、ブラウザはレンダリングと他の並列リクエストの実行でビジー状態となります。これにより、ネットワーク上で競合が発生します。この欠点にもかかわらず、originソリューションを使用するよりもCDNを使用するサードパーティリソースに明らかな利点があります。

      - CDNによって分類されたサイトリソースのTLSネゴシエーション時間の分布 + CDNによって分類されたサイトリソースのTLSネゴシエーション時間の分布
      図 10.リソースTLSネゴシエーション時間。

      TLSハンドシェイクのパフォーマンスは、さまざまな要因の影響を受けます。これらには、RTT、TLSレコードサイズ、およびTLS証明書サイズが含まれます。 RTTはTLSハンドシェイクに最大の影響を与えますが、TLSパフォーマンスの2番目に大きな要因はTLS証明書のサイズです。

      -

      TLSハンドシェイクの最初のラウンドトリップ中に、サーバーは証明書を添付します。この証明書は、次へ進む前にクライアントによって検証されます。この証明書交換では、サーバーは検証可能な証明書チェインを含む場合があります。この証明書の交換後、通信を暗号化するために追加のキーが確立されます。ただし、証明書の長さとサイズはTLSネゴシエーションのパフォーマンスに悪影響を与え、場合によってはクライアントライブラリをクラッシュさせる可能性があります。

      - 証明書の交換はTLSハンドシェイクの基礎であり、通常、エクスプロイトの攻撃対象領域を最小限に抑えるため、分離されたコードパスによって処理されます。低レベルの性質のため、バッファは通常動的に割り当てられず、固定されます。この方法では、クライアントが無制限のサイズの証明書を処理できると単純に想定することはできません。たとえば、OpenSSL CLIツールとSafariはhttps://10000-sans.badssl.comTLSハンドシェイクhttps://hpbn.co/transport-layer-security-tls/#tls-handshakeの最初のラウンドトリップ中に、サーバーは証明書を添付します。この証明書は、次へ進む前にクライアントによって検証されます。この証明書交換では、サーバーは検証可能な証明書チェインを含む場合があります。この証明書の交換後、通信を暗号化するために追加のキーが確立されます。ただし、証明書の長さとサイズはTLSネゴシエーションのパフォーマンスに悪影響を与え、場合によってはクライアントライブラリをクラッシュさせる可能性があります。 +

      +

      + 証明書の交換はTLSハンドシェイクの基礎であり、通常、エクスプロイトの攻撃対象領域を最小限に抑えるため、分離されたコードパスによって処理されます。低レベルの性質のため、バッファは通常動的に割り当てられず、固定されます。この方法では、クライアントが無制限のサイズの証明書を処理できると単純に想定することはできません。たとえば、OpenSSL CLIツールとSafariはhttps://10000-sans.badssl.comhttps://10000-sans.badssl.comに対して正常にネゴシエートできます。ただし、証明書のサイズが原因でChromeとFirefoxは失敗します。

      極端なサイズの証明書は障害を引き起こす可能性がありますが、適度に大きな証明書を送信してもパフォーマンスに影響があります。証明書は、Subject-Alternative-Name（SAN）にリストされている1つ以上のホスト名に対して有効です。 SANが多いほど、証明書は大きくなります。パフォーマンスの低下を引き起こすのは、検証中のこれらのSANの処理です。明確にするため、証明書サイズのパフォーマンスはTCPオーバーヘッドに関するものではなく、クライアントの処理パフォーマンスに関するものです。

      技術的に、TCPスロースタートはこのネゴシエーションに影響を与える可能性がありますが、そんなことはありません。 TLSレコードの長さは16KBに制限されており、通常の初期の10の輻輳ウィンドウに適合します。一部のISPはパケットスプライサーを使用し、他のツールは輻輳ウィンドウを断片化して帯域幅を人為的に絞る場合がありますが、これはWebサイトの所有者が変更または操作できるものではありません。

      ただし、多くのCDNは共有TLS証明書に依存しており、証明書のSANの多くの顧客をリストします。これはIPv4アドレスが不足しているため、必要になることがよくあります。エンドユーザーがServer-Name-Indicator（SNI）を採用する前は、クライアントはサーバーに接続し証明書を検査した後にのみ、クライアントはユーザーが探しているホスト名を示唆します（HTTPでHostヘッダーを使用する）。これにより、IPアドレスと証明書が1：1で関連付けられます。物理的な場所が多数あるCDNの場合、各場所に専用IPが必要になる可能性があり、IPv4アドレスの枯渇をさらに悪化させます。したがって、SNIをサポートしていないユーザーがまだいるWebサイトにCDNがTLS証明書を提供する最も簡単で効率的な方法は、共有証明書を提供することです。

      -

      アカマイによると、SNIの採用はまだ世界的に100％ではありません。幸いなことに、近年急速な変化がありました。最大の犯人はもはやWindows XPとVistaではなく、Androidアプリ、ボット、および企業アプリケーションです。SNI採用率が99％であっても、インターネット上の35億人のユーザーの残り1％は、Webサイトの所有者が非SNI証明書を要求する非常に魅力的な動機を生み出すことができます。別の言い方をすれば、特定製品、活動に注力してる(pure play)Webサイトは、標準ブラウザ間でほぼ100％SNIを採用できます。それでもアプリ、特にAndroidアプリでAPIまたはWebViewをサポートするためにWebサイトが使用されている場合、この分布は急速に低下する可能性があります。

      -

      ほとんどのCDNは、共有証明書の必要性とパフォーマンスのバランスをとります。ほとんどの場合、SANの数の上限は100〜150です。この制限は多くの場合、証明書プロバイダーに由来します。たとえば、LetsEncrypt、DigiCert、GoDaddyはすべて、SAN証明書を100個のホスト名に制限しますが、Comodoの制限は2,000個です。これにより、一部のCDNがこの制限を超えて、単一の証明書で800を超えるSANを使用できるようになります。 TLSパフォーマンスと証明書のSANの数には強い負の相関があります。

      +

      + アカマイによると、SNIの採用はまだ世界的に100％ではありませんhttps://datatracker.ietf.org/meeting/101/materials/slides-101-maprg-update-on-tls-sni-and-ipv6-client-adoption-00。幸いなことに、近年急速な変化がありました。最大の犯人はもはやWindows XPとVistaではなく、Androidアプリ、ボット、および企業アプリケーションです。SNI採用率が99％であっても、インターネット上の35億人のユーザーの残り1％は、Webサイトの所有者が非SNI証明書を要求する非常に魅力的な動機を生み出すことができます。別の言い方をすれば、特定製品、活動に注力してる(pure play)Webサイトは、標準ブラウザ間でほぼ100％SNIを採用できます。それでもアプリ、特にAndroidアプリでAPIまたはWebViewをサポートするためにWebサイトが使用されている場合、この分布は急速に低下する可能性があります。 +

      +

      + ほとんどのCDNは、共有証明書の必要性とパフォーマンスのバランスをとります。ほとんどの場合、SANの数の上限は100〜150です。この制限は多くの場合、証明書プロバイダーに由来します。たとえば、LetsEncrypthttps://letsencrypt.org/docs/rate-limits/、DigiCerthttps://www.websecurity.digicert.com/security-topics/san-ssl-certificates、GoDaddyhttps://www.godaddy.com/web-security/multi-domain-san-ssl-certificateはすべて、SAN証明書を100個のホスト名に制限しますが、Comodohttps://comodosslstore.com/comodo-mdc-ssl.aspxの制限は2,000個です。これにより、一部のCDNがこの制限を超えて、単一の証明書で800を超えるSANを使用できるようになります。 TLSパフォーマンスと証明書のSANの数には強い負の相関があります。 +

      - 図11. HTMLのTLS SANカウント。 + 図11. HTMLのTLS SANカウント。
      図 11. HTMLのTLS SANカウント。
      @@ -8373,7 +9288,7 @@

      - 図13.リソースSANカウント（p50）。 + 図13.リソースSANカウント（p50）。
      図 13.リソースSANカウント（p50）。
      @@ -8555,7 +9470,7 @@

      TLSの

      TLSおよびRTTのパフォーマンスにCDNを使用することに加えて、TLS暗号およびTLSバージョンのパッチ適用および採用を確実とするため、CDNがよく使用されます。一般に、メインHTMLページでのTLSの採用は、CDNを使用するWebサイトの方がはるかに高くなっています。 HTMLページの76％以上がTLSで提供されているのに対し、originホストページからは62％です。

      - 図15. HTML TLSバージョンの採用（CDNとorigin）。 + 図15. HTML TLSバージョンの採用（CDNとorigin）。
      図 15. HTML TLSバージョンの採用（CDNとorigin）。
      @@ -8563,14 +9478,14 @@

      TLSの

      各CDNは、TLSと提供される相対的な暗号とバージョンの両方に異なる採用率を提供します。一部のCDNはより積極的で、これらの変更をすべての顧客に展開しますが他のCDNはWebサイトの所有者に最新の変更をオプトインして、これらの暗号とバージョンを容易にする変更管理を提供することを要求します。

      - 図16. CDNによるHTML TLSの採用。 + 図16. CDNによるHTML TLSの採用。
      図 16. CDNによるHTML TLSの採用。
      - 図17. CDNによるサードパーティTLSの採用。 + 図17. CDNによるサードパーティTLSの採用。
      図 17. CDNによるサードパーティTLSの採用。
      @@ -8580,7 +9495,7 @@

      TLSの

      Web Almanacで使用されるChromeは、ホストが提供する最新のTLSバージョンと暗号にバイアスをかけることを強調することが重要です。また、これらのWebページは2019年7月にクロールされ、新しいバージョンを有効にしたWebサイトの採用を反映しています。

      - 図18. CDNによるHTML TLSバージョン。 + 図18. CDNによるHTML TLSバージョン。
      図 18. CDNによるHTML TLSバージョン。
      @@ -8592,14 +9507,14 @@

      HTTP/2

      注：すべてのリクエストは、HTTP/2をサポートするChromeの最新バージョンで行われました。 HTTP/1.1のみが報告される場合、これは暗号化されていない（非TLS）サーバーまたはHTTP/2をサポートしないサーバーを示します。

      - 図19. HTTP / 2の採用（CDNとorigin）。 + 図19. HTTP / 2の採用（CDNとorigin）。
      図 19. HTTP/2の採用（CDNとorigin）。
      - 図20. HTTP/2のHTML採用。 + 図20. HTTP/2のHTML採用。
      図 20. HTTP/2のHTML採用。
      @@ -8801,7 +9716,7 @@

      HTTP/2

      - 図22. HTML/2の採用：サードパーティのリソース。 + 図22. HTML/2の採用：サードパーティのリソース。
      図 22. HTML/2の採用：サードパーティのリソース。
      @@ -9009,7 +9924,7 @@

      別の便利なツールは、Vary HTTPヘッダーの使用です。このヘッダーは、キャッシュをフラグメント化する方法をCDNとブラウザーの両方に指示します。Varyヘッダーにより、originはリソースの表現が複数あることを示すことができ、CDNは各バリエーションを個別にキャッシュする必要があります。最も一般的な例は圧縮です。リソースをVary：Accept-Encodingを使用すると、CDNは同じコンテンツを、非圧縮、gzip、Brotliなどの異なる形式でキャッシュできます。一部のCDNでは、使用可能なコピーを1つだけ保持するために、この圧縮を急いで実行します。同様に、このVaryヘッダーは、コンテンツをキャッシュする方法と新しいコンテンツを要求するタイミングをブラウザーに指示します。

      - CDNから提供されるHTMLコンテンツのVaryヘッダー値の内訳 + CDNから提供されるHTMLコンテンツのVaryヘッダー値の内訳
      図 24. CDNから提供されるHTMLのVaryの使用法。
      @@ -9019,7 +9934,7 @@

      同様に、Vary：Cookieは通常、ユーザーのログイン状態またはその他のパーソナライズに基づいてコンテンツが変化することを示します。

      - 図25. HTMLとoriginとCDNから提供されるリソースのVary使用の比較。 + 図25. HTMLとoriginとCDNから提供されるリソースのVary使用の比較。
      図 25. HTMLとoriginとCDNから提供されるリソースのVary使用の比較。
      @@ -9036,7 +9951,7 @@

      s-maxageディレクティブは、応答をキャッシュできる期間をプロキシに通知します。 Web Almanacデータセット全体で、jsDelivrは複数のリソースで高いレベルの使用が見られた唯一のCDNです。これは、jsDelivrのライブラリのパブリックCDNとしての役割を考えると驚くことではありません。他のCDNでの使用は、個々の顧客、たとえばその特定のCDNを使用するサードパーティのスクリプトまたはSaaSプロバイダーによって推進されているようです。

      - 図26. CDN応答全体でのs-maxageの採用。 + 図26. CDN応答全体でのs-maxageの採用。
      図 26. CDN応答全体でのs-maxageの採用。
      @@ -9049,7 +9964,7 @@

      - 図27.パブリックコンテンツCDNの使用。 + 図27.パブリックコンテンツCDNの使用。
      図 27.パブリックコンテンツCDNの使用。
      @@ -9060,79 +9975,73 @@

      結論

      Steve SoudersによるCDNの使用の推奨は、12年前と同じように今日でも有効ですがCDNを介してHTMLコンテンツを提供しているサイトは20％のみであり、リソースにCDNを使用しているサイトは40％のみです。それらの使用法はさらに成長します。

      この分析に含まれていないCDNの採用にはいくつかの側面があります、これはデータセットの制限と収集方法が原因である場合で、他の場合は分析中に新しい研究の質問が出てきました。

      Webの進化に伴い、CDNベンダーは革新しサイトの新しいプラクティスを使用します、CDNの採用はWeb Almanacの将来のエディションでのさらなる研究のために豊富な領域のままです。

      -

    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":18,"title":"Page Weight","description":"ページの重さが重要な理由、帯域幅、複雑なページ、経時的なページの重み、ページ要求、およびファイル形式をカバーする2019 Web Almanacのページの重さの章。","authors":["tammyeverts","khempenius"],"reviewers":["paulcalvano"],"translators":["ksakae"],"discuss":"1773","results":"https://docs.google.com/spreadsheets/d/1nWOo8efqDgzmA0wt1ipplziKhlReAxnVCW1HkjuFAxU/","queries":"18_PageWeight","published":"2019-11-11","last_updated":"2020-03-02","chapter":"page-weight"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 18 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - Page Weight +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":18,"title":"Page Weight","description":"ページの重さが重要な理由、帯域幅、複雑なページ、経時的なページの重み、ページ要求、およびファイル形式をカバーする2019 Web Almanacのページの重さの章。","authors":["tammyeverts","khempenius"],"reviewers":["paulcalvano"],"translators":["ksakae"],"discuss":"1773","results":"https://docs.google.com/spreadsheets/d/1nWOo8efqDgzmA0wt1ipplziKhlReAxnVCW1HkjuFAxU/","queries":"18_PageWeight","published":"2019-11-11","last_updated":"2020-03-02","chapter":"page-weight"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -9141,13 +10050,16 @@

    - + -
    {{ self.written_by_before() }} Tammy Everts, {{ self.and() }} Katie Hempenius{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Paul Calvano{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    中央Webページのサイズは約1900KBで、74のリクエストが含まれています。悪くないですね。

    ここに中央値の問題があります：それらは問題を隠します。定義上、それらは分布の中間にのみ焦点を合わせています。全体像を理解するには、両極端のパーセンタイルを考慮する必要があります。

    @@ -9156,9 +10068,14 @@

    -

    Tim Kadlecの魅力的なオンライン計算機、[What Does My Site Cost?]（https://whatdoesmysitecost.com/）をチェックしてください。これは、世界中の国のページのコスト（1人あたりのドルと国民総所得）を計算します。それは目を見張るものです。たとえば、執筆時点で2.79MBのAmazonのホームページの費用は、モーリタニアの1人当たりGNIの1日あたり1.89％です。世界のいくつかの地域の人々が数十ページを訪問するだけで一日の賃金をあきらめなければならないとき、ワールドワイドウェブはどれほどグローバルなのでしょうか？

    +

    + Tim Kadlecの魅力的なオンライン計算機、[What Does My Site Cost?]（https://whatdoesmysitecost.com/）をチェックしてください。これは、世界中の国のページのコスト（1人あたりのドルと国民総所得）を計算します。それは目を見張るものです。たとえば、執筆時点で2.79MBのAmazonのホームページの費用は、モーリタニアの1人当たりGNIの1日あたり1.89％です。世界のいくつかの地域の人々が数十ページを訪問するだけで一日の賃金をあきらめなければならないとき、ワールドワイドウェブはどれほどグローバルなのでしょうか？https://whatdoesmysitecost.com/）をチェックしてください。これは、世界中の国のページのコスト（1人あたりのドルと国民総所得）を計算します。それは目を見張るものです。たとえば、執筆時点で2.79MBのAmazonのホームページの費用は、モーリタニアの1人当たりGNIの1日あたり1.89％です。世界のいくつかの地域の人々が数十ページを訪問するだけで一日の賃金をあきらめなければならないとき、ワールドワイドウェブはどれほどグローバルなのでしょうか？ +

    帯域幅を増やすことは、Webパフォーマンスの魔法の弾丸ではありません

    -

    より多くの人がより良いデバイスとより安価な接続にアクセスできたとしても、それは完全なソリューションではありません。帯域幅を2倍にしても、2倍速くなるわけではありません。実際、帯域幅を最大1,233％増やすと、ページが55％速くなるだけであることが実証されています。

    +

    + より多くの人がより良いデバイスとより安価な接続にアクセスできたとしても、それは完全なソリューションではありません。帯域幅を2倍にしても、2倍速くなるわけではありません。実際、帯域幅を最大1,233％増やすと、ページが55％速くなるだけであることが実証https://developer.akamai.com/blog/2015/06/09/heres-why-more-bandwidth-isnt-magic-bullet-web-performanceされています。 +

    問題は遅延です。私たちのネットワークプロトコルのほとんどは、多くの往復を必要とし、それらの各往復は遅延ペナルティを課します。遅延がパフォーマンスの問題である限り（つまり、近い将来）パフォーマンスの主な原因は、今日の典型的なWebページには数十の異なるサーバーでホストされている100程度のアセットが含まれていることです。これらのアセットの多くは、最適化されておらず、測定と監視がされていないため予測不能です。

    HTTP Archiveはどのような種類のアセットを追跡し、どの程度の重要性を持ちますか？

    HTTP Archiveが追跡するページ構成メトリックの簡単な用語集と、パフォーマンスとユーザーエクスペリエンスの観点から重要なメトリックを以下に示します。

    @@ -9177,7 +10094,10 @@

    大きくて複雑なページはビジネスに悪い場合があります

    -

    あなたが、あなたのサイト訪問者を気にしない心無いモンスターでないと仮定しましょう。しかしあなたがそうであれば、より大きく、より複雑なページを提供することもあなたを傷つけることを知っておくべきです。これは、小売サイトから100万以上のビーコンに相当する実際のユーザーデータを収集したGoogle主導の機械学習の調査結果の1つでした。

    +

    + あなたが、あなたのサイト訪問者を気にしない心無いモンスターでないと仮定しましょう。しかしあなたがそうであれば、より大きく、より複雑なページを提供することもあなたを傷つけることを知っておくべきです。これは、小売サイトから100万以上のビーコンに相当する実際のユーザーデータを収集したGoogle主導の機械学習https://www.thinkwithgoogle.com/marketing-resources/experience-design/mobile-page-speed-load-time/の調査結果の1つでした。 +

    この研究から、3つの重要なポイントがありました。

    1. @@ -9187,7 +10107,7 @@

      - 図1.変換されたセッションと変換されないセッション。 + 図1.変換されたセッションと変換されないセッション。
      図 1.変換されたセッションと変換されないセッション。
      @@ -9197,7 +10117,7 @@

      - 図2.スクリプトが増加すると変換率は低下します。 + 図2.スクリプトが増加すると変換率は低下します。
      図 2.スクリプトが増加すると変換率は低下します。
      @@ -9473,7 +10393,10 @@

      図 6. 2018年以降のデスクトップページの重みの変化。 -

      ページの重さが時間とともにどのように変化するかについての長期的な視点については、HTTP Archiveからこの時系列グラフをご覧ください。ページサイズの中央値は、HTTP Archiveが2010年11月にこのメトリックの追跡を開始して以来ほぼ一定の割合で成長しており、過去1年間に見られたページウェイトの増加はこれと一致しています。

      +

      + ページの重さが時間とともにどのように変化するかについての長期的な視点については、HTTP Archiveからこの時系列グラフhttps://httparchive.org/reports/page-weight#bytesTotalをご覧ください。ページサイズの中央値は、HTTP Archiveが2010年11月にこのメトリックの追跡を開始して以来ほぼ一定の割合で成長しており、過去1年間に見られたページウェイトの増加はこれと一致しています。 +

      ページリクエスト

      デスクトップページの中央値は74リクエストで、モバイルページの中央値は69リクエストです。これらのリクエストの大部分は画像とJavaScriptアカウントです。昨年、リクエストの量や分布に大きな変化はありませんでした。

      モバイル

      @@ -9681,7 +10604,7 @@

      - 図10. GIFファイルサイズの累積分布関数。 + 図10. GIFファイルサイズの累積分布関数。
      図 10. GIFファイルサイズの累積分布関数。
      @@ -9819,7 +10742,11 @@

      図 12. 1024バイトを超える画像の画像形式ごとのファイルサイズ。 -

      JPEG画像に比べてPNG画像のファイルサイズが小さいことは驚くべきことです。 JPEGは非可逆圧縮を使用します。非可逆圧縮によりデータが失われるため、ファイルサイズを小さくできます。一方、PNGは可逆圧縮を使用します。これによりデータが失われることはありません。これにより、より高品質で大きな画像が生成されます。ただし、このファイルサイズの違いはエンコーディングと圧縮の違いではなく、透過性のサポートによるアイコンのグラフィックのPNGの人気を反映している可能性があります。

      +

      + JPEG画像に比べてPNG画像のファイルサイズが小さいことは驚くべきことです。 JPEGは非可逆圧縮https://ja.wikipedia.org/wiki/%E9%9D%9E%E5%8F%AF%E9%80%86%E5%9C%A7%E7%B8%AEを使用します。非可逆圧縮によりデータが失われるため、ファイルサイズを小さくできます。一方、PNGは可逆圧縮https://ja.wikipedia.org/wiki/%E5%8F%AF%E9%80%86%E5%9C%A7%E7%B8%AEを使用します。これによりデータが失われることはありません。これにより、より高品質で大きな画像が生成されます。ただし、このファイルサイズの違いはエンコーディングと圧縮の違いではなく、透過性のサポートによるアイコンのグラフィックのPNGの人気を反映している可能性があります。 +

      メディア形式ごとのファイルサイズ

      MP4は、今日のWebで圧倒的に最も人気のあるビデオ形式です。人気の点では、それぞれWebMとMPEG-TSが続きます。

      このデータセットの他のテーブルの一部とは異なり、このテーブルにはほとんど満足のいく結果があります。動画はモバイルでは常に小さく表示されるのですばらしいです。さらに、MP4ビデオのサイズの中央値は、モバイルでは18KB、デスクトップでは39KBと非常に合理的です。 WebMの数値の中央値はさらに優れていますが、一度見てください。複数のクライアントとパーセンタイルでの0.29KBの重複測定は少し疑わしいです。考えられる説明の1つは、非常に小さなWebMビデオの同一のコピーが多くのページに含まれていることです。 3つの形式のうち、MPEG-TSは常にすべてのパーセンタイルで最高のファイルサイズを持っています。これは1995年にリリースされたという事実に関連している可能性があり、これらの3つのメディア形式の中で最も古いものになっています。

      @@ -9921,79 +10848,73 @@
      結論

      過去1年間で、ページのサイズは約10％増加しました。 Brotli、パフォーマンスバジェット、および基本的な画像最適化のベストプラクティスは、おそらくページウェイトを維持または改善すると同時に広く適用可能で実装が非常に簡単な3つのテクニックです。そうは言っても、近年ではページの重さの改善は、テクノロジー自体よりもベストプラクティスの採用が少ないことにより制約されています。言い換えれば、ページの重さを改善するための多くの既存のテクニックがありますが、それらが使用されなければ違いはありません。

      -
    + -
    -

    Authors

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":19,"title":"リソースヒント","description":"2019年のWeb Almanacのリソースヒントの章では、dns-prefetch、preconnect、preload、prefetch、priority hints、ネイティブの遅延ローディングの使用法をカバーしています。","authors":["khempenius"],"reviewers":["andydavies","bazzadp","yoavweiss"],"translators":["ksakae"],"discuss":"1774","results":"https://docs.google.com/spreadsheets/d/14QBP8XGkMRfWRBbWsoHm6oDVPkYhAIIpfxRn4iOkbUU/","queries":"19_Resource_Hints","published":"2019-11-11","last_updated":"2020-05-14","chapter":"resource-hints"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 19 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - リソースヒント +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":19,"title":"リソースヒント","description":"2019年のWeb Almanacのリソースヒントの章では、dns-prefetch、preconnect、preload、prefetch、priority hints、ネイティブの遅延ローディングの使用法をカバーしています。","authors":["khempenius"],"reviewers":["andydavies","bazzadp","yoavweiss"],"translators":["ksakae"],"discuss":"1774","results":"https://docs.google.com/spreadsheets/d/14QBP8XGkMRfWRBbWsoHm6oDVPkYhAIIpfxRn4iOkbUU/","queries":"19_Resource_Hints","published":"2019-11-11","last_updated":"2020-05-14","chapter":"resource-hints"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -10002,16 +10923,24 @@

    - + -
    {{ self.written_by_before() }} Katie Hempenius{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Andy Davies, Barry Pollard, {{ self.and() }} Yoav Weiss{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    + +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    序章

    -

    リソースヒント は、どのようなリソースがすぐに必要になるかについての「ヒント」をブラウザに提供します。このヒントを受け取った結果としてブラウザが取るアクションは、リソースヒントの種類によって異なります。リソースヒントは正しく使用されると、重要なアクションを先取りすることでページのパフォーマンスを向上させることができます。

    -

    例は、リソースヒントの結果としてパフォーマンスが向上しています。

    +

    + リソースヒントhttps://www.w3.org/TR/resource-hints/ は、どのようなリソースがすぐに必要になるかについての「ヒント」をブラウザに提供します。このヒントを受け取った結果としてブラウザが取るアクションは、リソースヒントの種類によって異なります。リソースヒントは正しく使用されると、重要なアクションを先取りすることでページのパフォーマンスを向上させることができます。 +

    +

    + 例https://youtu.be/YJGCZCaIZkQ?t=1956は、リソースヒントの結果としてパフォーマンスが向上しています。 +

    • Jabongは、重要なスクリプトをプリロードすることで、対話までの時間を1.5秒短縮しました。
    • Barefoot Wineは、目に見えるリンクを先読みすることで、将来のページの対話までの時間を2.7秒短縮しました。
      • @@ -10022,37 +10951,40 @@

      dns-prefetch

      - dns-prefetchdns-prefetchhttps://developer.mozilla.org/en-US/docs/Learn/Performance/dns-prefetchの役割は、初期のDNS検索を開始することである。サードパーティのDNSルックアップを完了させるのに便利です。たとえば、CDN、フォントプロバイダー、サードパーティAPIのDNSルックアップなどです。

      preconnect

      - preconnectpreconnecthttps://web.dev/uses-rel-preconnectは、DNSルックアップ、TCPハンドシェイク、TLSネゴシエーションを含む早期接続を開始します。このヒントはサードパーティとの接続を設定する際に有用である。preconnectの用途はdns-prefetchの用途と非常によく似ているが、preconnectはブラウザのサポートが少ない。しかし、IE 11のサポートを必要としないのであれば、preconnectの方が良い選択であろう。

      preload

      - preloadpreloadhttps://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbfヒントは、早期のリクエストを開始します。これは、パーサによって発見されるのが遅れてしまうような重要なリソースをロードするのに便利です。たとえば、ブラウザがスタイルシートを受信し解析したあとでしか重要な画像を発見できない場合、画像をプリロードすることは意味があるかもしれません。

      prefetch

      - prefetchprefetchhttps://calendar.perfplanet.com/2018/all-about-prefetching/は優先度の低いリクエストを開始します。これは、次の（現在のページではなく）ページの読み込みで使われるであろうリソースを読み込むのに便利です。プリフェッチの一般的な使い方は、アプリケーションが次のページロードで使われると「予測」したリソースをロードすることです。これらの予測は、ユーザーのマウスの動きや、一般的なユーザーの流れ/旅のようなシグナルに基づいているかもしれません。

      文法

      - リソースヒント使用率の97%は、リソースヒントを指定するために<link><link>https://developer.mozilla.org/ja/docs/Web/HTML/Element/linkタグを使用しています。たとえば、以下のようになります。 

      <link rel="prefetch" href="shopping-cart.js">
      -

      リソースヒント使用率のわずか3%は、リソースヒントの指定にHTTPヘッダを使用しました。たとえば、以下のようになります。

      +

      + リソースヒント使用率のわずか3%は、リソースヒントの指定にHTTPヘッダhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Linkを使用しました。たとえば、以下のようになります。 + 

      Link: <https://example.com/shopping-cart.js>; rel=prefetch

      HTTPヘッダー内のリソースヒントの使用量が非常に少ないため、本章の残りの部分では、<link>タグと組み合わせたリソースヒントの使用量の分析のみに焦点を当てています。しかし、今後、HTTP/2 Pushが採用されるようになると、HTTPヘッダーでのリソースヒントの使用量が増える可能性のあることは注目に値します。これは、HTTP/2 Pushがリソースをプッシュするためのシグナルとして、HTTPのプリロード Link ヘッダーを再利用していることに起因しています。

      リソースヒント

      @@ -10092,8 +11024,14 @@

      図 1. リソースヒントの採用。 -

      dns-prefetchの相対的な人気は驚くに値しません。これはよく知られたAPIであり（2009ではじめて登場しました）、すべての主要なブラウザでサポートされており、すべてのリソースヒントの中でもっとも「安価」なものです。dns-prefetchはDNSの検索を行うだけなので、データの消費量が非常に少なく、使用する上でのデメリットはほとんどありません。dns-prefetchはレイテンシの高い状況でもっとも有用である。

      -

      つまり、IE11以下をサポートする必要がないサイトであれば、dns-prefetchからpreconnectに切り替えるのが良いでしょう。HTTPSがユビキタスな時代には、preconnectは安価でありながら、より大きなパフォーマンスの向上をもたらします。dns-prefetchとは異なり、preconnectはDNSの検索だけでなく、TCPハンドシェイクとTLSネゴシエーションも開始することに注意してください。証明書チェーンはTLSネゴシエーション中にダウンロードされるが、これには通常数キロバイトのコストがかかります。

      +

      + dns-prefetchの相対的な人気は驚くに値しません。これはよく知られたAPIであり（2009https://caniuse.com/#feat=link-rel-dns-prefetchではじめて登場しました）、すべての主要なブラウザでサポートされており、すべてのリソースヒントの中でもっとも「安価」なものです。dns-prefetchはDNSの検索を行うだけなので、データの消費量が非常に少なく、使用する上でのデメリットはほとんどありません。dns-prefetchはレイテンシの高い状況でもっとも有用である。 +

      +

      + つまり、IE11以下をサポートする必要がないサイトであれば、dns-prefetchからpreconnectに切り替えるのが良いでしょう。HTTPSがユビキタスな時代には、preconnectは安価でありながら、より大きなパフォーマンスの向上をもたらします。dns-prefetchとは異なり、preconnectはDNSの検索だけでなく、TCPハンドシェイクとTLSネゴシエーションも開始することに注意してください。証明書チェーンhttps://knowledge.digicert.com/solution/SO16297.htmlはTLSネゴシエーション中にダウンロードされるが、これには通常数キロバイトのコストがかかります。 +

      prefetchは3%のサイトで利用されており、もっとも広く利用されていないリソースヒントである。この使用率の低さは、prefetchが現在のページの読み込みよりも後続のページの読み込みを改善するのに有用であるという事実によって説明できるかもしれません。したがって、ランディングページの改善や最初に閲覧されたページのパフォーマンスを向上させることだけに焦点を当てているサイトでは、これは見過ごされてしまうだろう。

      @@ -10140,7 +11078,10 @@

      crossorigin属性

      -

      ウェブ上に取り込まれるほとんどの「伝統的な」リソース（images、stylesheets、script）は、クロスオリジンリソース共有（CORS）を選択せずに取り込まれています。つまり、これらのリソースがクロスオリジンサーバーからフェッチされた場合、デフォルトでは同一オリジンポリシーのために、その内容をページで読み返すことができないということです。

      +

      + ウェブ上に取り込まれるほとんどの「伝統的な」リソース（images、stylesheets、script）は、クロスオリジンリソース共有（CORShttps://developer.mozilla.org/ja/docs/Web/HTTP/CORS）を選択せずに取り込まれています。つまり、これらのリソースがクロスオリジンサーバーからフェッチされた場合、デフォルトでは同一オリジンポリシーのために、その内容をページで読み返すことができないということです。 +

      場合によっては、ページはコンテンツを読む必要がある場合、CORSを使用してリソースを取得するようにオプトインできます。CORSは、ブラウザが「許可を求める」ことを可能にし、それらのクロスオリジンリソースへのアクセスを取得します。

      新しいリソースタイプ（フォント、fetch() リクエスト、ESモジュールなど）では、ブラウザはデフォルトでCORSを使用してリソースをリクエストし、サーバーがアクセス許可を与えていない場合はリクエストを完全に失敗させます。

      @@ -10180,7 +11121,10 @@

      as属性

      -

      asはpreloadリソースヒントと一緒に使用されるべき属性で、要求されたリソースの種類（画像、スクリプト、スタイルなど）をブラウザに知らせるため使用されます。これにより、ブラウザがリクエストに正しく優先順位をつけ、正しいコンテンツセキュリティポリシー(CSP)を適用するのに役立ちます。CSPはHTTPヘッダーで表現されるセキュリティメカニズムです、信頼できるソースのセーフリストを宣言することで、XSSやその他の悪意のある攻撃の影響を緩和するのに役立ちます。

      +

      + asはpreloadリソースヒントと一緒に使用されるべき属性で、要求されたリソースの種類（画像、スクリプト、スタイルなど）をブラウザに知らせるため使用されます。これにより、ブラウザがリクエストに正しく優先順位をつけ、正しいコンテンツセキュリティポリシー(CSPhttps://developers.google.com/web/fundamentals/security/csp)を適用するのに役立ちます。CSPはHTTPヘッダーで表現されるセキュリティメカニズムです、信頼できるソースのセーフリストを宣言することで、XSSやその他の悪意のある攻撃の影響を緩和するのに役立ちます。 +

      88%
      図 4. as属性を使用したリソースヒントインスタンスの割合。
      @@ -10189,7 +11133,10 @@

      将来のこと

      現時点では、現在のリソースヒントのセットを拡張する提案はありません。しかし、優先度ヒントとネイティブの遅延ローディングは、ローディングプロセスを最適化するためのAPIを提供するという点で、リソースヒントに似た精神を持つ2つの技術が提案されています。

      優先順位のヒント

      -

      優先度ヒントは、リソースのフェッチの優先度をhigh,low,autoのいずれかで表現するためのAPIです。これらは幅広いHTMLタグで利用できます。とくに<image>,<link>,<script>,<iframe>などです。

      +

      + 優先度ヒントhttps://wicg.github.io/priority-hints/は、リソースのフェッチの優先度をhigh,low,autoのいずれかで表現するためのAPIです。これらは幅広いHTMLタグで利用できます。とくに<image>,<link>,<script>,<iframe>などです。 + 

      <carousel>
@@ -10205,58 +11152,87 @@ 
      0.04%
      図 6. 優先ヒントの採用率。
      -

      優先度ヒントは実装されており、Chromiumブラウザのバージョン70以降では機能フラグを使ってテストできます。まだ実験的な技術であることを考えると、0.04%のサイトでしか使用されていないのは当然のことです。

      +

      + 優先度ヒントは実装https://www.chromestatus.com/feature/5273474901737472されており、Chromiumブラウザのバージョン70以降では機能フラグを使ってテストできます。まだ実験的な技術であることを考えると、0.04%のサイトでしか使用されていないのは当然のことです。 +

      優先度ヒントの85%は<img>タグを使用しています。優先度ヒントはほとんどがリソースの優先順位を下げるために使われます。使用率の72%はimportance="low"で、28%はimportance="high"です。

      ネイティブの遅延ローディング

      -

      ネイティブの遅延ローディングは、画面外の画像やiframeの読み込みを遅延させるためのネイティブAPIです。これにより、最初のページ読み込み時にリソースを解放し、使用されないアセットの読み込みを回避できます。以前は、この技術はサードパーティのJavaScriptライブラリでしか実現できませんでした。

      -

      ネイティブな遅延読み込みのためのAPIはこのようになります。<img src="cat.jpg" loading="lazy">.

      +

      + ネイティブの遅延ローディングhttps://web.dev/native-lazy-loadingは、画面外の画像やiframeの読み込みを遅延させるためのネイティブAPIです。これにより、最初のページ読み込み時にリソースを解放し、使用されないアセットの読み込みを回避できます。以前は、この技術はサードパーティのJavaScriptライブラリでしか実現できませんでした。 +

      +

      ネイティブな遅延読み込みのためのAPIはこのようになります。<img src="cat.jpg">.

      ネイティブな遅延ローディングは、Chromium76以上をベースにしたブラウザで利用可能です。このAPIは発表が遅すぎて今年のWeb Almanacのデータセットには含まれていませんが、来年に向けて注目しておきたいものです。

      結論

      全体的に、このデータはリソースヒントをさらに採用する余地があることを示唆しているように思われる。ほとんどのサイトでは、dns-prefetchからpreconnectに切り替えることで恩恵を受けることができるだろう。もっと小さなサブセットのサイトでは、prefetchやpreloadを採用することで恩恵を受けることができるだろう。prefetchとpreloadをうまく使うには、より大きなニュアンスがあり、それが採用をある程度制限していますが、潜在的な利益はより大きくなります。HTTP/2 Pushや機械学習技術の成熟により、preloadやprefetchの採用が増える可能性もあります。

      -

    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    -
    -
    +{% set metadata = {"part_number":"IV","chapter_number":20,"title":"HTTP/2","description":"HTTP/2、HTTP/2プッシュ、HTTP/2の問題、およびHTTP/3の採用と影響をカバーするWeb Almanac 2019のHTTP/2章","authors":["bazzadp"],"reviewers":["bagder","rmarx","dotjs"],"translators":["ksakae"],"discuss":"1775","results":"https://docs.google.com/spreadsheets/d/1z1gdS3YVpe8J9K3g2UdrtdSPhRywVQRBz5kgBeqCnbw/","queries":"20_HTTP_2","published":"2019-11-11","last_updated":"2020-05-19","chapter":"http2"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} +
    +
    - {{ self.part() }} IV {{ self.chapter() }} 20 + {{ self.part() }} {{ metadata.get('part_number') }} {{ self.chapter() }} {{ metadata.get('chapter_number') }}
    -

    - HTTP/2 +

    + {{ metadata.get('title') }} {% if metadata.get('unedited', false) %} + {{ self.unedited() }} + {% endif %}

    - {% set metadata = {"part_number":"IV","chapter_number":20,"title":"HTTP/2","description":"HTTP/2、HTTP/2プッシュ、HTTP/2の問題、およびHTTP/3の採用と影響をカバーするWeb Almanac 2019のHTTP/2章","authors":["bazzadp"],"reviewers":["bagder","rmarx","dotjs"],"translators":["ksakae"],"discuss":"1775","results":"https://docs.google.com/spreadsheets/d/1z1gdS3YVpe8J9K3g2UdrtdSPhRywVQRBz5kgBeqCnbw/","queries":"20_HTTP_2","published":"2019-11-11","last_updated":"2020-05-19","chapter":"http2"} %} {% set chapter_image_dir = ("/static/images/2019/%s" % metadata.chapter) %} - @@ -10265,16 +11241,22 @@

    - + -
    {{ self.written_by_before() }} Barry Pollard{{ self.written_by_after() }}
    -
    {{ self.reviewed_by_before() }} Daniel Stenberg, Robin Marx, {{ self.and() }} Andrew Galloni{{ self.reviewed_by_after() }}
    -
    {{ self.translated_by_before() }} Sakae Kotaro{{ self.translated_by_after() }}
    +
    {{ self.written_by_before() }} {% for author in metadata.get('authors') %} {{ config.contributors[author].name if author in config.contributors else author }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.written_by_after() }}
    +
    {{ self.reviewed_by_before() }} {% for reviewer in metadata.get('reviewers') %} {{ config.contributors[reviewer].name if reviewer in config.contributors else reviewer }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.reviewed_by_after() }}
    + + {% if metadata.get('translators') | length >= 1 %} +
    {{ self.translated_by_before() }} {% for translator in metadata.get('translators') %} {{ config.contributors[translator].name if translator in config.contributors else translator }}{% if loop.index != loop.length and loop.length != 2 %},{% endif %} {% if loop.index == loop.length - 1 %}{{ self.and() }}{% endif %} {% endfor %}{{ self.translated_by_after() }}
    + {% endif %}

    導入

    HTTP/2は、ほぼ20年ぶりになるWebのメイン送信プロトコルの初となるメジャーアップデートでした。それは多くの期待を持って到来し、欠点なしで無料のパフォーマンス向上を約束しました。それ以上に、HTTP/1.1が非効率なため強制されていたすべてのハックや回避策をやめることができました。デフォルトでパフォーマンスが向上するため、ドメインのバンドル、分割、インライン化、さらにはシャーディングなどはすべてHTTP/2の世界でアンチパターンになります。

    -

    これは、Webパフォーマンスに集中するスキルとリソースを持たない人でも、すぐにパフォーマンスの高いWebサイトにできます。しかし現実はほぼ相変わらずです。 2015年5月にRFC 7540で標準としてHTTP/2に正式承認されてから4年以上経過してます。ということでこの比較的新しい技術が現実の世界でどのように発展したかを見てみる良い機会です。

    +

    + これは、Webパフォーマンスに集中するスキルとリソースを持たない人でも、すぐにパフォーマンスの高いWebサイトにできます。しかし現実はほぼ相変わらずです。 2015年5月にRFC 7540https://tools.ietf.org/html/rfc7540で標準としてHTTP/2に正式承認されてから4年以上経過してます。ということでこの比較的新しい技術が現実の世界でどのように発展したかを見てみる良い機会です。 +

    HTTP/2とは?

    この技術に精通していない人にとって、この章のメトリックと調査結果を最大限に活用するには、ちょっとした背景が役立ちます。最近までHTTPは常にテキストベースのプロトコルでした。 WebブラウザーのようなHTTPクライアントがサーバーへのTCP接続を開き、GET /index.htmlのようなHTTPコマンドを送信して、リソースを要求します。

    これはHTTPヘッダーを追加するためにHTTP/1.0で拡張されました、なのでリクエストに加えてブラウザの種類、理解できる形式などさまざまなメタデータを含めることができます。これらのHTTPヘッダーもテキストベースであり改行文字で区切られていました。サーバーは、要求とHTTPヘッダーを1行ずつ読み取ることで着信要求を解析し、サーバーは要求されている実際のリソースに加えて独自のHTTP応答ヘッダーで応答しました。

    @@ -10282,7 +11264,10 @@

    HTTP

    特に暗号化を設定するための追加の手順を必要とするHTTPSを使用する場合、TCP接続は設定と完全な効率を得るのに時間とリソースを要するため、それ自体に問題が生じます。 HTTP/1.1はこれを幾分改善し、後続のリクエストでTCP接続を再利用できるようにしましたが、それでも並列化の問題は解決しませんでした。

    HTTPはテキストベースですが、実際、少なくとも生の形式でテキストを転送するために使用されることはほとんどありませんでした。 HTTPヘッダーがテキストのままであることは事実でしたが、ペイロード自体しばしばそうではありませんでした。 HTML、JS、CSSなどのテキストファイルは通常、gzip、brotliなどを使用してバイナリ形式に転送するため圧縮されます。画像や動画 などの非テキストファイルは、独自の形式で提供されます。その後、セキュリティ上の理由からメッセージ全体を暗号化するために、HTTPメッセージ全体がHTTPSでラップされることがよくあります。

    そのため、Webは基本的に長い間テキストベースの転送から移行していましたが、HTTPは違いました。この停滞の1つの理由は、HTTPのようなユビキタスプロトコルに重大な変更を導入することが非常に困難だったためです（以前努力しましたが、失敗しました）。多くのルーター、ファイアウォール、およびその他のミドルボックスはHTTPを理解しており、HTTPへの大きな変更に対して過剰に反応します。それらをすべてアップグレードして新しいバージョンをサポートすることは、単に不可能でした。

    -

    2009年に、GoogleはSPDYと呼ばれるテキストベースのHTTPに代わるものへ取り組んでいると発表しましたが、SPDYは非推奨です。これはHTTPメッセージがしばしばHTTPSで暗号化されるという事実を利用しており、メッセージが読み取られ途中で干渉されるのを防ぎます。

    +

    + 2009年に、GoogleはSPDYhttps://www.chromium.org/spdyと呼ばれるテキストベースのHTTPに代わるものへ取り組んでいると発表しましたが、SPDYは非推奨です。これはHTTPメッセージがしばしばHTTPSで暗号化されるという事実を利用しており、メッセージが読み取られ途中で干渉されるのを防ぎます。 +

    Googleは、最も人気のあるブラウザー（Chrome）と最も人気のあるWebサイト（Google、YouTube、Gmailなど）の1つを制御しました。 Googleのアイデアは、HTTPメッセージを独自の形式にパックし、インターネット経由で送信してから反対側でアンパックすることでした。独自の形式であるSPDYは、テキストベースではなくバイナリベースでした。これにより、単一のTCP接続をより効率的に使用できるようになり、HTTP/1.1で標準になっていた6つの接続を開く必要がなくなりHTTP/1.1の主要なパフォーマンス問題の一部が解決しました。

    現実の世界でSPDYを使用することで、ラボベースの実験結果だけでなく、実際のユーザーにとってより高性能であることを証明できました。すべてのGoogle WebサイトにSPDYを展開した後、他のサーバーとブラウザーが実装を開始し、この独自の形式をインターネット標準に標準化するときが来たため、HTTP/2が誕生しました。

    HTTP/2には次の重要な概念があります。

    @@ -10294,24 +11279,42 @@

    HTTP
  • ヘッダー圧縮
  • プッシュ
    • -

    バイナリ形式とは、HTTP/2メッセージが事前定義された形式のフレームに包まれることを意味しHTTPメッセージの解析が容易になり、改行文字のスキャンが不要になります。これは、以前のバージョンのHTTPに対して多くの脆弱性があったため、セキュリティにとってより優れています。また、HTTP/2接続を多重化できることも意味します。各フレームにはストリーム識別子とその長さが含まれているため、異なるストリームの異なるフレームを互いに干渉することなく同じ接続で送信できます。多重化により、追加の接続を開くオーバーヘッドなしで、単一のTCP接続をより効率的に使用できます。理想的にはドメインごと、または複数のドメインに対しても単一の接続を開きます！

    +

    + バイナリ形式とは、HTTP/2メッセージが事前定義された形式のフレームに包まれることを意味しHTTPメッセージの解析が容易になり、改行文字のスキャンが不要になります。これは、以前のバージョンのHTTPに対して多くの脆弱性https://www.owasp.org/index.php/HTTP_Response_Splittingがあったため、セキュリティにとってより優れています。また、HTTP/2接続を多重化できることも意味します。各フレームにはストリーム識別子とその長さが含まれているため、異なるストリームの異なるフレームを互いに干渉することなく同じ接続で送信できます。多重化により、追加の接続を開くオーバーヘッドなしで、単一のTCP接続をより効率的に使用できます。理想的にはドメインごと、または複数のドメインhttps://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/に対しても単一の接続を開きます！ +

    個別のストリームを使用すると、潜在的な利点とともにいくつかの複雑さが取り入れられます。 HTTP/2は異なるストリームが異なるレートでデータを送信できるようにするフロー制御の概念を必要としますが、以前応答は1つに1つだけで、これはTCPフロー制御によって接続レベルで制御されていました。同様に、優先順位付けでは複数のリクエストを一緒に送信できますが、最も重要なリクエストではより多くの帯域幅を取得できます。

    -

    最後に、HTTP/2には、ヘッダー圧縮とHTTP/2プッシュという2つの新しい概念が導入されました。ヘッダー圧縮により、セキュリティ上の理由からHTTP/2固有のHPACK形式を使用して、これらのテキストベースのHTTPヘッダーをより効率的に送信できました。 HTTP/2プッシュにより、要求への応答として複数の応答を送信できるようになり、クライアントが必要と認識する前にサーバーがリソースを「プッシュ」できるようになりました。プッシュは、CSSやJavaScriptなどのリソースをHTMLに直接インライン化して、それらのリソースが要求されている間、ページが保持されないようにするというパフォーマンスの回避策を解決することになっています。 HTTP/2を使用するとCSSとJavaScriptは外部ファイルとして残りますが、最初のHTMLと共にプッシュされるため、すぐに利用できました。これらのリソースはキャッシュされるため後続のページリクエストはこれらのリソースをプッシュしません。したがって、帯域幅を浪費しません。

    -

    急ぎ足で紹介したこのHTTP/2は、新しいプロトコルの主な歴史と概念を提供します。この説明から明らかなように、HTTP/2の主な利点は、HTTP/1.1プロトコルのパフォーマンス制限に対処することです。また、セキュリティの改善も行われました。恐らく最も重要なのは、HTTP/2以降のHTTPSを使用するパフォーマンスの問題に対処することです、HTTPSを使用しても通常のHTTPよりもはるかに高速です。 HTTPメッセージを新しいバイナリ形式に包むWebブラウザーと、反対側でWebサーバーがそれを取り出す以外は、HTTP自体の中核的な基本はほぼ同じままでした。これは、ブラウザーとサーバーがこれを処理するため、WebアプリケーションがHTTP/2をサポートするために変更を加える必要がないことを意味します。オンにすることで、無料でパフォーマンスを向上させることができるため、採用は比較的簡単です。もちろん、Web開発者がHTTP/2を最適化して、その違いを最大限に活用する方法もあります。

    +

    + 最後に、HTTP/2には、ヘッダー圧縮とHTTP/2プッシュという2つの新しい概念が導入されました。ヘッダー圧縮により、セキュリティ上の理由からHTTP/2固有のHPACKhttps://tools.ietf.org/html/rfc7541形式を使用して、これらのテキストベースのHTTPヘッダーをより効率的に送信できました。 HTTP/2プッシュにより、要求への応答として複数の応答を送信できるようになり、クライアントが必要と認識する前にサーバーがリソースを「プッシュ」できるようになりました。プッシュは、CSSやJavaScriptなどのリソースをHTMLに直接インライン化して、それらのリソースが要求されている間、ページが保持されないようにするというパフォーマンスの回避策を解決することになっています。 HTTP/2を使用するとCSSとJavaScriptは外部ファイルとして残りますが、最初のHTMLと共にプッシュされるため、すぐに利用できました。これらのリソースはキャッシュされるため後続のページリクエストはこれらのリソースをプッシュしません。したがって、帯域幅を浪費しません。 +

    +

    + 急ぎ足で紹介したこのHTTP/2は、新しいプロトコルの主な歴史と概念を提供します。この説明から明らかなように、HTTP/2の主な利点は、HTTP/1.1プロトコルのパフォーマンス制限に対処することです。また、セキュリティの改善も行われました。恐らく最も重要なのは、HTTP/2以降のHTTPSを使用するパフォーマンスの問題に対処することです、HTTPSを使用しても通常のHTTPよりもはるかに高速https://www.httpvshttps.com/です。 HTTPメッセージを新しいバイナリ形式に包むWebブラウザーと、反対側でWebサーバーがそれを取り出す以外は、HTTP自体の中核的な基本はほぼ同じままでした。これは、ブラウザーとサーバーがこれを処理するため、WebアプリケーションがHTTP/2をサポートするために変更を加える必要がないことを意味します。オンにすることで、無料でパフォーマンスを向上させることができるため、採用は比較的簡単です。もちろん、Web開発者がHTTP/2を最適化して、その違いを最大限に活用する方法もあります。 +

    HTTP/2の採用

    -

    前述のように、インターネットプロトコルはインターネットを構成するインフラストラクチャの多くに深く浸透しているため、しばしば採用を難しくする事があります。これにより、変更の導入が遅くなり、困難になります。たとえば、IPv6は20年前から存在していますが、採用に苦労しています。

    +

    + 前述のように、インターネットプロトコルはインターネットを構成するインフラストラクチャの多くに深く浸透しているため、しばしば採用を難しくする事があります。これにより、変更の導入が遅くなり、困難になります。たとえば、IPv6は20年前から存在していますが、採用に苦労しています。https://www.google.com/intl/en/ipv6/statistics.html +

    95%
    図 1. HTTP/2を使用できるグローバルユーザーの割合。
    -

    ただし、HTTP/2はHTTPSで事実上隠されていたため異なってました（少なくともブラウザーの使用例では）、ブラウザーとサーバーの両方がサポートしている限り、採用の障壁を取り除いてきました。ブラウザーのサポートはしばらく前から非常に強力であり、最新バージョンへ自動更新するブラウザーの出現により、グローバルユーザーの推定95％がHTTP/2をサポートするようになりました。

    +

    + ただし、HTTP/2はHTTPSで事実上隠されていたため異なってました（少なくともブラウザーの使用例では）、ブラウザーとサーバーの両方がサポートしている限り、採用の障壁を取り除いてきました。ブラウザーのサポートはしばらく前から非常に強力であり、最新バージョンへ自動更新するブラウザーの出現により、グローバルユーザーの推定95％がHTTP/2をサポートするようになりましたhttps://caniuse.com/#feat=http2。 +

    私たちの分析は、Chromeブラウザで約500万の上位デスクトップおよびモバイルWebサイトをテストするHTTP Archiveから提供されています。(方法論の詳細をご覧ください。)

    - 図2.要求によるHTTP/2の使用。 + 図2.要求によるHTTP/2の使用。 -
    図 2.要求によるHTTP/2の使用。(引用: HTTP Archive)
    +
    + 図 2.要求によるHTTP/2の使用。(引用: HTTP Archivehttps://httparchive.org/reports/state-of-the-web#h2) +

    結果は、HTTP/2の使用が、現在過半数のプロトコルであることを示しています。これは、正式な標準化からわずか4年後の目覚しい偉業です。要求ごとのすべてのHTTPバージョンの内訳を見ると、次のことがわかります。

    @@ -10365,9 +11368,15 @@

    QUIC（もうすぐHTTP/3として標準化される予定）を個別に追跡しないため、これらの要求は現在HTTP/2の下にリストされますが、この章の後半でそれを測定する他の方法を見ていきます。

    +

    + 現在、HTTP ArchiveはHTTP over QUIChttps://www.chromium.org/quic（もうすぐHTTP/3として標準化される予定）を個別に追跡しないため、これらの要求は現在HTTP/2の下にリストされますが、この章の後半でそれを測定する他の方法を見ていきます。 +

    リクエストの数を見ると、一般的なリクエストのため結果が多少歪んでいます。たとえば、多くのサイトはHTTP/2をサポートするGoogleアナリティクスを読み込むため、埋め込みサイト自体がHTTP/2をサポートしていない場合でもHTTP/2リクエストとして表示されます。一方、人気のあるウェブサイトはHTTP/2をサポートする傾向があり、上記の統計では1回しか測定されないため、過小評価されます（「google.com」と「obscuresite.com」には同じ重みが与えられます）。嘘、いまいましい嘘と統計です。

    -

    ただし、私たちの調査結果は、Firefoxブラウザーを介した実際の使用状況を調べるMozillaのテレメトリなど、他のソースによって裏付けられています。

    +

    + ただし、私たちの調査結果は、Firefoxブラウザーを介した実際の使用状況を調べるMozillaのテレメトリhttps://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&measure=HTTP_RESPONSE_VERSIONなど、他のソースによって裏付けられています。 +

    @@ -10532,7 +11541,10 @@

    図 6. HTTP/2に使用されるサーバー。

    -

    nginxは、最新バージョンへのインストールまたはアップグレードを容易にするパッケージリポジトリを提供しているため、ここをリードしていることについて驚くことではありません。 cloudflareは最も人気のあるCDNで、デフォルトでHTTP/2を有効にしているため、HTTP/2サイトの大部分をホストしていることについて驚くことはありません。ちなみに、cloudflareは、Webサーバーとして大幅にカスタマイズされたバージョンのnginxを使用しています。その後、Apacheの使用率は約20％であり、次に何が隠されているかを選択するサーバー、LiteSpeed、IIS、Google Servlet Engine、nginxベースのopenrestyなどの小さなプレイヤーが続きます。

    +

    + nginxは、最新バージョンへのインストールまたはアップグレードを容易にするパッケージリポジトリを提供しているため、ここをリードしていることについて驚くことではありません。 cloudflareは最も人気のあるCDNで、デフォルトでHTTP/2を有効にしているため、HTTP/2サイトの大部分をホストしていることについて驚くことはありません。ちなみに、cloudflareは、Webサーバーとして大幅にカスタマイズhttps://blog.cloudflare.com/nginx-structural-enhancements-for-http-2-performance/されたバージョンのnginxを使用しています。その後、Apacheの使用率は約20％であり、次に何が隠されているかを選択するサーバー、LiteSpeed、IIS、Google Servlet Engine、nginxベースのopenrestyなどの小さなプレイヤーが続きます。 +

    さらに興味深いのは、HTTP/2をサポートしないサーバーです。

    @@ -10675,33 +11687,50 @@

    図 8. HTTP/2を提供するために使用される各サーバーのインストールの割合。

    ApacheとIISがインストールベースのHTTP/2サポートで1​​8％、14％と遅れを取っていることは明らかです。これは（少なくとも部分的に）アップグレードがより困難であるためです。多くのサーバーがこのサポートを簡単に取得するには、多くの場合、OSの完全なアップグレードが必要です。新しいバージョンのOSが標準になると、これが簡単になることを願っています。

    -

    ここで、HTTP/2実装に関するコメントはありません（Apacheが最高の実装の1つであると思います）が、これらの各サーバーでHTTP/2を有効にすることの容易さ、またはその欠如に関する詳細です。

    +

    + ここで、HTTP/2実装に関するコメントはありません（Apacheが最高の実装の1つであると思いますhttps://twitter.com/tunetheweb/status/988196156697169920?s=20）が、これらの各サーバーでHTTP/2を有効にすることの容易さ、またはその欠如に関する詳細です。 +

    HTTP/2の影響

    HTTP/2の影響は、特にHTTP Archive方法論を使用して測定するのがはるかに困難です。理想的には、サイトをHTTP/1.1とHTTP/2の両方でクロールし、その差を測定する必要がありますがここで調査している統計では不可能です。さらに、平均的なHTTP/2サイトが平均的なHTTP/1.1サイトよりも高速であるかどうかを測定すると、ここで説明するよりも徹底的な調査を必要とする他の変数が多くなりすぎます。

    測定できる影響の1つは、現在HTTP/2の世界にいるHTTP使用の変化です。複数の接続は、限られた形式の並列化を可能にするHTTP/1.1の回避策でしたが、これは実際、HTTP/2で通常最もよく機能することの反対になります。単一の接続でTCPセットアップ、TCPスロースタート、およびHTTPSネゴシエーションのオーバーヘッドが削減され、クロスリクエストの優先順位付けが可能になります。

    - 図9.ページごとのTCP接続。 + 図9.ページごとのTCP接続。 -
    図 9.ページごとのTCP接続。 (引用: HTTP Archive)
    +
    + 図 9.ページごとのTCP接続。 (引用: HTTP Archivehttps://httparchive.org/reports/state-of-the-web#tcp) +

    HTTP Archiveは、ページあたりのTCP接続数を測定します。これは、HTTP/2をサポートするサイトが増え、6つの個別の接続の代わりに単一の接続を使用するため、徐々に減少しています。

    - 図10.ページごとの合計リクエスト。 + 図10.ページごとの合計リクエスト。 -
    図 10.ページごとの合計リクエスト。 (引用: HTTP Archive)
    +
    + 図 10.ページごとの合計リクエスト。 (引用: HTTP Archivehttps://httparchive.org/reports/state-of-the-web#reqTotal) +
    -

    より少ないリクエストを取得するためのアセットのバンドルは、バンドル、連結、パッケージ化、分割など多くの名前で行われた別のHTTP/1.1回避策でした。HTTP/2を使用する場合、リクエストのオーバーヘッドが少ないため、これはあまり必要ありませんが、注意する必要がありますその要求はHTTP/2で無料ではなく、バンドルを完全に削除する実験を行った人はパフォーマンスの低下に気付きました。ページごとにロードされるリクエストの数を時間毎に見ると、予想される増加ではなく、リクエストのわずかな減少が見られます。

    +

    + より少ないリクエストを取得するためのアセットのバンドルは、バンドル、連結、パッケージ化、分割など多くの名前で行われた別のHTTP/1.1回避策でした。HTTP/2を使用する場合、リクエストのオーバーヘッドが少ないため、これはあまり必要ありませんが、注意する必要がありますその要求はHTTP/2で無料ではなく、バンドルを完全に削除する実験を行った人はパフォーマンスの低下に気付きましたhttps://engineering.khanacademy.org/posts/js-packaging-http2.htm。ページごとにロードされるリクエストの数を時間毎に見ると、予想される増加ではなく、リクエストのわずかな減少が見られます。 +

    この減少は、おそらくパフォーマンスへの悪影響なしにバンドルを削除できない（少なくとも完全にではない）という前述の観察と、HTTP/1.1の推奨事項に基づく歴史的な理由で現在多くのビルドツールがバンドルされていることに起因する可能性があります。また、多くのサイトがHTTP/1.1のパフォーマンスハッキングを戻すことでHTTP/1.1ユーザーにペナルティを課す気がないかもしれません、少なくともこれに価値があると感じる確信（または時間！）を持っていない可能性があります。

    増加するページの重みを考えると、リクエストの数がほぼ静的なままであるという事実は興味深いですが、これはおそらくHTTP/2に完全に関連しているわけではありません。

    HTTP/2プッシュ

    HTTP/2プッシュは、HTTP/2の大いに宣伝された新機能であるにもかかわらず、複雑な歴史を持っています。他の機能は基本的に内部のパフォーマンスの向上でしたが、プッシュはHTTPの単一の要求から単一の応答への性質を完全に破ったまったく新しい概念で、追加の応答を返すことができました。 Webページを要求すると、サーバーは通常どおりHTMLページで応答しますが、重要なCSSとJavaScriptも送信するため、特定のリソースへ追加の往復が回避されます。理論的には、CSSとJavaScriptをHTMLにインライン化するのをやめ、それでも同じようにパフォーマンスを向上させることができます。それを解決した後、潜在的にあらゆる種類の新しくて興味深いユースケースにつながる可能性があります。

    -

    現実は、まあ、少し残念です。 HTTP/2プッシュは、当初想定されていたよりも効果的に使用することがはるかに困難であることが証明されています。これのいくつかは、HTTP/2プッシュの動作の複雑さ、およびそれによる実装の問題によるものです。

    +

    + 現実は、まあ、少し残念です。 HTTP/2プッシュは、当初想定されていたよりも効果的に使用することがはるかに困難であることが証明されています。これのいくつかは、HTTP/2プッシュの動作の複雑さhttps://jakearchibald.com/2017/h2-push-tougher-than-i-thought/、およびそれによる実装の問題によるものです。 +

    より大きな懸念は、プッシュがパフォーマンスの問題を解決するのではなく、すぐ簡単に問題を引き起こす可能性があることです。過剰な押し込みは、本当のリスクです。多くの場合、ブラウザーは何を要求するかを決定する最適な場所にあり、要求するタイミングと同じくらい重要ですが、HTTP/2プッシュはサーバーにその責任を負わせます。ブラウザが既にキャッシュに持っているリソースをプッシュすることは、帯域幅の浪費です（私の意見ではCSSをインライン化していますが、それについてはHTTP/2プッシュよりも苦労が少ないはずです！）。

    -

    ブラウザのキャッシュのステータスについてサーバーに通知する提案は 、特にプライバシーの問題で行き詰っています。その問題がなくても、プッシュが正しく使用されない場合、他の潜在的な問題があります。たとえば、大きな画像をプッシュして重要なCSSとJavaScriptの送信を保留すると、プッシュしない場合よりもWebサイトが遅くなります。

    +

    + ブラウザのキャッシュのステータスについてサーバーに通知する提案はhttps://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0033.html 、特にプライバシーの問題で行き詰っています。その問題がなくても、プッシュが正しく使用されない場合、他の潜在的な問題があります。たとえば、大きな画像をプッシュして重要なCSSとJavaScriptの送信を保留すると、プッシュしない場合よりもWebサイトが遅くなります。 +

    またプッシュは正しく実装された場合でも、パフォーマンス向上に必ずつながるという証拠はほとんどありませんでした。これも、HTTP Archiveの実行方法（1つの状態でChromeを使用する人気サイトのクロール）の性質により、HTTP Archiveが回答するのに最適な場所ではないため、ここでは詳しく説明しません。 ただし、パフォーマンスの向上は明確でなく、潜在的な問題は現実的であると言えば十分です。

    それはさておき、HTTP/2プッシュの使用方法を見てみましょう。

    @@ -10761,10 +11790,13 @@

    図 12.使用時にプッシュされる量。

    これらの統計は、HTTP/2プッシュの増加が非常に低いことを示しています。これは、おそらく前述の問題が原因です。ただし、サイトがプッシュを使用する場合、図12に示すように1つまたは2つのアセットではなく、プッシュを頻繁に使用する傾向があります。

    -

    これは以前のアドバイスでプッシュを控えめにし、「アイドル状態のネットワーク時間を埋めるのに十分なリソースだけをプッシュし、それ以上はプッシュしない」ということでした。上記の統計は、大きなサイズの多くのリソースがプッシュされることを示しています。

    +

    + これは以前のアドバイスでプッシュを控えめにし、「アイドル状態のネットワーク時間を埋めるのに十分なリソースだけをプッシュし、それ以上はプッシュしないhttps://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0/edit」ということでした。上記の統計は、大きなサイズの多くのリソースがプッシュされることを示しています。 +

    - 図13.プッシュはどのアセットタイプに使用されますか？ + 図13.プッシュはどのアセットタイプに使用されますか？
    図 13.プッシュはどの資産タイプに使用されますか？
    @@ -10778,9 +11810,17 @@

    HTTP/2問題

    HTTP/2は主にシームレスなアップグレードであり、サーバーがサポートすると、Webサイトやアプリケーションを変更することなく切り替えることができます。 HTTP/2向けに最適化するか、HTTP/1.1回避策の使用をやめることができますが、一般的にサイトは通常、変更を必要とせずに動作します。ただし、アップグレードに影響を与える可能性のある注意点がいくつかあり、一部のサイトでこれは難しい方法であることがわかりました。

    -

    HTTP/2の問題の原因の1つは、HTTP/2の優先順位付けの不十分なサポートです。この機能により、進行中の複数の要求が接続を適切に使用できるようになります。 HTTP/2は同じ接続で実行できるリクエストの数を大幅に増やしているため、これは特に重要です。サーバーの実装では、100または128の並列リクエスト制限が一般的です。以前は、ブラウザにはドメインごとに最大6つの接続があったため、そのスキルと判断を使用してそれらの接続の最適な使用方法を決定しました。現在では、キューに入れる必要はほとんどなく、リクエストを認識するとすぐにすべてのリクエストを送信できます。これにより、優先度の低いリクエストで帯域幅が「無駄」になり、重要なリクエストが遅延する可能性はあります（また偶発的にバックエンドサーバーが使用されるよりも多くのリクエストでいっぱいになる可能性があります！）

    +

    + HTTP/2の問題の原因の1つは、HTTP/2の優先順位付けの不十分なサポートです。この機能により、進行中の複数の要求が接続を適切に使用できるようになります。 HTTP/2は同じ接続で実行できるリクエストの数を大幅に増やしているため、これは特に重要です。サーバーの実装では、100または128の並列リクエスト制限が一般的です。以前は、ブラウザにはドメインごとに最大6つの接続があったため、そのスキルと判断を使用してそれらの接続の最適な使用方法を決定しました。現在では、キューに入れる必要はほとんどなく、リクエストを認識するとすぐにすべてのリクエストを送信できます。これにより、優先度の低いリクエストで帯域幅が「無駄」になり、重要なリクエストが遅延する可能性はあります（また偶発的にバックエンドサーバーが使用されるよりも多くのリクエストでいっぱいになる可能性があります！https://www.lucidchart.com/techblog/2019/04/10/why-turning-on-http2-was-a-mistake/） +

    HTTP/2には複雑な優先順位付けモデルがあります（非常に複雑すぎるため、なぜHTTP/3で再検討されているのでしょう！）が、それを適切に尊重するサーバーはほとんどありません。これはHTTP/2の実装がスクラッチになっていないか、サーバーがより高い優先度の要求であることを認識する前に応答は既に送信されている、いわゆるバッファブロートが原因である可能性も考えられます。サーバー、TCPスタック、および場所の性質が異なるため、ほとんどのサイトでこれを測定することは困難ですがCDNを使用する場合はこれをより一貫させる必要があります。

    -

    Patrick Meenanは、優先度の高いオンスクリーンイメージを要求する前に、優先度の低いオフスクリーンイメージのロードを意図的にダウンロードしようとするサンプルテストページを作成しました。優れたHTTP/2サーバーはこれを認識し、優先度の低い画像を犠牲にして、要求後すぐに優先度の高い画像を送信できるはずです。貧弱なHTTP/2サーバーはリクエストの順番で応答し、優先順位のシグナルを無視します。 Andy Daviesには、Patrickのテスト用にさまざまなCDNのステータスを追跡するページがあります。 HTTP Archiveは、クロールの一部としてCDNが使用されるタイミングを識別しこれら2つのデータセットをマージすると、合格または失敗したCDNを使用しているページの割合を知ることができます。

    +

    + Patrick Meenanhttps://twitter.com/patmeenanは、優先度の高いオンスクリーンイメージを要求する前に、優先度の低いオフスクリーンイメージのロードを意図的にダウンロードしようとするサンプルテストページhttps://github.com/pmeenan/http2priorities/tree/master/stand-aloneを作成しました。優れたHTTP/2サーバーはこれを認識し、優先度の低い画像を犠牲にして、要求後すぐに優先度の高い画像を送信できるはずです。貧弱なHTTP/2サーバーはリクエストの順番で応答し、優先順位のシグナルを無視します。 Andy Daviesには、Patrickのテスト用にさまざまなCDNのステータスを追跡するページhttps://github.com/andydavies/http2-prioritization-issuesがあります。 HTTP Archiveは、クロールの一部としてCDNが使用されるタイミングを識別しこれら2つのデータセットをマージすると、合格または失敗したCDNを使用しているページの割合を知ることができます。 +

    @@ -10894,11 +11934,21 @@

    HTTP

    それよりも悪いのは、サーバーがエラーでアップグレードヘッダーを送信する場合です。これは、HTTP/2をサポートするバックエンドサーバーがヘッダーを送信し、HTTP1.1のみのエッジサーバーは盲目的にクライアントに転送していることが原因である可能性を考えます。 Apacheはmod_http2が有効になっているがHTTP/2が使用されていない場合にアップグレードヘッダーを発行し、そのようなApacheインスタンスの前にあるnginxインスタンスは、nginxがHTTP/2をサポートしない場合でもこのヘッダーを喜んで転送します。この偽の宣伝は、クライアントが推奨されているとおりにHTTP/2を使用しようとする（そして失敗する！）ことにつながります。

    108サイトはHTTP/2を使用していますが、アップグレードヘッダーでHTTP/2にアップグレードすることも推奨しています。デスクトップ上のさらに12,767のサイト（モバイルは15,235）では、HTTPSを使用できない場合、または既に使用されていることが明らかな場合、HTTPS経由で配信されるHTTP/1.1接続をHTTP/2にアップグレードすることをお勧めします。これらは、デスクトップでクロールされた430万サイトとモバイルでクロールされた530万サイトのごく少数ですが、依然として多くのサイトに影響を与える問題であることを示しています。ブラウザはこれを一貫して処理しません。Safariは特にアップグレードを試み、混乱してサイトの表示を拒否します。

    これはすべて、http1.0、http：//1.1、または-all、+ TLSv1.3、+ TLSv1.2へのアップグレードを推奨するいくつかのサイトに入る前です。ここで進行中のWebサーバー構成には明らかに間違いがあります！

    -

    私たちが見ることのできるさらなる実装の問題があります。たとえば、HTTP/2はHTTPヘッダー名に関してはるかに厳密でありスペース、コロン、またはその他の無効なHTTPヘッダー名で応答するとリクエスト全体を拒否します。ヘッダー名も小文字に変換されます。これは、アプリケーションが特定の大文字化を前提とする場合、驚くことになります。 HTTP/1.1ではヘッダー名で大文字と小文字が区別されないと明記されているため、これは以前保証されていませんでしたが、一部はこれに依存してます。 HTTP Archiveを使用してこれらの問題を特定することもできます、それらの一部はホームページには表示されませんが、今年は詳しく調査しませんでした。

    +

    + 私たちが見ることのできるさらなる実装の問題があります。たとえば、HTTP/2はHTTPヘッダー名に関してはるかに厳密でありスペース、コロン、またはその他の無効なHTTPヘッダー名で応答するとリクエスト全体を拒否します。ヘッダー名も小文字に変換されます。これは、アプリケーションが特定の大文字化を前提とする場合、驚くことになります。 HTTP/1.1ではヘッダー名で大文字と小文字が区別されないhttps://tools.ietf.org/html/rfc7230#section-3.2と明記されているため、これは以前保証されていませんでしたが、一部はこれに依存してます。 HTTP Archiveを使用してこれらの問題を特定することもできます、それらの一部はホームページには表示されませんが、今年は詳しく調査しませんでした。 +

    HTTP/3

    -

    世界はまだ止まっておらず、HTTP/2が5歳の誕生日を迎えてないにも関わらず、人々はすでにそれを古いニュースとみなしており後継者であるHTTP/3にもっと興奮しています。 HTTP/3はHTTP/2の概念に基づいていますが、HTTPが常に使用しているTCP接続を介した作業から、QUICと呼ばれるUDPベースのプロトコルに移行します。これにより、パケット損失が大きくTCPの保証された性質によりすべてのストリームが保持され、すべてのストリームが抑制される場合、HTTP/2がHTTP/1.1より遅い1つのケースを修正できます。また、両方のハンドシェイクで統合するなど、TCPとHTTPSの非効率性に対処することもできます。実際、実装が難しいと証明されているTCPの多くのアイデアをサポートします（TCP高速オープン、0-RTTなど）。

    +

    + 世界はまだ止まっておらず、HTTP/2が5歳の誕生日を迎えてないにも関わらず、人々はすでにそれを古いニュースとみなしており後継者であるHTTP/3にもっと興奮しています。 HTTP/3https://tools.ietf.org/html/draft-ietf-quic-httpはHTTP/2の概念に基づいていますが、HTTPが常に使用しているTCP接続を介した作業から、QUIChttps://datatracker.ietf.org/wg/quic/about/と呼ばれるUDPベースのプロトコルに移行します。これにより、パケット損失が大きくTCPの保証された性質によりすべてのストリームが保持され、すべてのストリームが抑制される場合、HTTP/2がHTTP/1.1より遅い1つのケースを修正できます。また、両方のハンドシェイクで統合するなど、TCPとHTTPSの非効率性に対処することもできます。実際、実装が難しいと証明されているTCPの多くのアイデアをサポートします（TCP高速オープン、0-RTTなど）。 +

    HTTP/3は、TCPとHTTP/2の間のオーバーラップもクリーンアップします（たとえば両方のレイヤーでフロー制御は実装されます）が、概念的にはHTTP/2と非常に似ています。 HTTP/2を理解し、最適化したWeb開発者は、HTTP/3をさらに変更する必要はありません。ただし、TCPとQUICの違いははるかに画期的であるため、サーバーオペレータはさらに多くの作業を行う必要があります。 HTTP/3のロールアウトはHTTP/2よりもかなり長くかかる可能性があり、最初はCDNなどの分野で特定の専門知識を持っている人に限定されます。

    -

    QUICは長年にわたってGoogleによって実装されており、SPDYがHTTP/2へ移行する際に行ったのと同様の標準化プロセスを現在行っています。 QUICにはHTTP以外にも野心がありますが、現時点では現在使用中のユースケースです。この章が書かれたように、HTTP/3はまだ正式に完成していないか、まだ標準として承認されていないにもかかわらず、Cloudflare、Chrome、FirefoxはすべてHTTP/3サポートを発表しました。これは最近までQUICサポートがGoogleの外部にやや欠けていたため歓迎され、同様の標準化段階からのSPDYおよびHTTP/2サポートに確実に遅れています。

    +

    + QUICは長年にわたってGoogleによって実装されており、SPDYがHTTP/2へ移行する際に行ったのと同様の標準化プロセスを現在行っています。 QUICにはHTTP以外にも野心がありますが、現時点では現在使用中のユースケースです。この章が書かれたように、HTTP/3はまだ正式に完成していないか、まだ標準として承認されていないにもかかわらず、Cloudflare、Chrome、FirefoxはすべてHTTP/3サポートhttps://blog.cloudflare.com/http3-the-past-present-and-future/を発表しました。これは最近までQUICサポートがGoogleの外部にやや欠けていたため歓迎され、同様の標準化段階からのSPDYおよびHTTP/2サポートに確実に遅れています。 +

    HTTP/3はTCPではなくUDPでQUICを使用するため、HTTP/3の検出はHTTP/2の検出よりも大きな課題になります。 HTTP/2では、主にHTTPSハンドシェイクを使用できますが、HTTP/3は完全に異なる接続となるため、ここは選択肢ではありません。またHTTP/2はアップグレードHTTPヘッダーを使用してブラウザーにHTTP/2サポートを通知します、HTTP/2にはそれほど有用ではありませんでしたが、QUICにはより有用な同様のメカニズムが導入されています。代替サービスHTTPヘッダー（alt-svc）は、この接続で使用できる代替プロトコルとは対照的に、まったく異なる接続で使用できる代替プロトコルを宣伝します。これは、アップグレードHTTPヘッダーの使用目的です。

    8.38%
    @@ -10908,44 +11958,65 @@

    HTTP/3

    結論

    HTTP Archiveプロジェクトで利用可能な統計のこの分析は、HTTPコミュニティの私たちの多くがすでに認識していることを示しています。HTTP/2はここにあり、非常に人気であることが証明されています。リクエスト数の点ではすでに主要なプロトコルですが、それをサポートするサイトの数の点ではHTTP/1.1を完全に追い抜いていません。インターネットのロングテールは、よく知られた大量のサイトよりもメンテナンスの少ないサイトで顕著な利益を得るために指数関数的に長い時間がかかることを意味します。

    また、一部のインストールでHTTP/2サポートを取得するのが（まだ！）簡単ではないことについても説明しました。サーバー開発者、OSディストリビューター、およびエンドカスタマーはすべて、それを容易にするためプッシュすることを関与します。ソフトウェアをOSに関連付けると、常に展開時間が長くなります。実際、QUICのまさにその理由の1つは、TCPの変更を展開することで同様の障壁を破ることです。多くの場合、WebサーバーのバージョンをOSに結び付ける本当の理由はありません。 Apache（より人気のある例の1つを使用する）は、古いOSでHTTP/2サポートを使用して実行されますがサーバーに最新バージョンを取得することは、現在の専門知識やリスクを必要としません。 nginxはここで非常にうまく機能し、一般的なLinuxフレーバーのリポジトリをホストしてインストールを容易にします。Apacheチーム（またはLinuxディストリビューションベンダー）が同様のものを提供しない場合、Apacheの使用は苦労しながら縮小し続けます、最新バージョンには最高のHTTP/2実装の1つがあります、関連性を保持し古くて遅い（古いインストールに基づいて）という評判を揺るがします。 IISは通常、Windows側で優先されるWebサーバーであるため、IISの問題はそれほど多くないと考えています。

    -

    それ以外は、HTTP/2は比較的簡単なアップグレードパスであるため、既に見た強力な支持を得ています。ほとんどの場合、これは痛みなく追加が可能で、ほぼ手間をかけずにパフォーマンスが向上し、サーバーでサポートされるとほとんど考慮しなくて済むことが判明しました。しかし、（いつものように）悪魔は細部にいて、サーバー実装間のわずかな違いによりHTTP/2の使用が良くも悪くも最終的にエンドユーザーの体験に影響します。また、新しいプロトコルで予想されるように、多くのバグやセキュリティの問題もありました。

    +

    + それ以外は、HTTP/2は比較的簡単なアップグレードパスであるため、既に見た強力な支持を得ています。ほとんどの場合、これは痛みなく追加が可能で、ほぼ手間をかけずにパフォーマンスが向上し、サーバーでサポートされるとほとんど考慮しなくて済むことが判明しました。しかし、（いつものように）悪魔は細部にいて、サーバー実装間のわずかな違いによりHTTP/2の使用が良くも悪くも最終的にエンドユーザーの体験に影響します。また、新しいプロトコルで予想されるように、多くのバグやセキュリティの問題https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.mdもありました。 +

    HTTP/2のような新しいプロトコルの強力で最新のメンテナンスされた実装を使用していることを確認することで、これらの問題を確実に把握できます。ただし、それには専門知識と管理が必要です。 QUICとHTTP/3のロールアウトはさらに複雑になり、より多くの専門知識が必要になります。おそらくこれは、この専門知識を持っており、サイトからこれらの機能に簡単にアクセスできるCDNのようなサードパーティのサービスプロバイダーに委ねるのが最善でしょうか？　ただ、専門家に任せたとしても、これは確実でありません（優先順位付けの統計が示すように）。しかし、サーバープロバイダーを賢明に選択して、優先順位が何であるかを確認すれば実装が容易になります。

    その点については、CDNがこれらの問題に優先順位を付ければ素晴らしいと思います（間違いなく意図的です！）、HTTP/3での新しい優先順位付け方法の出現を疑っていますが、多くは固執します。来年は、HTTPの世界でさらに興味深い時代になるでしょう。

    -
    + -
    -

    Author

    +
    + {% for author in metadata.get('authors') %} {% if loop.index == 1 %} +

    + + {% if loop.length == 1 %}{{ self.author() }}{% endif -%} {% if loop.length > 1 and loop.index == 1 %}{{ self.authors() }}{% endif %} + +

    -
    +
    {% endblock %} diff --git a/src/tools/generate/generate_ebooks.js b/src/tools/generate/generate_ebooks.js index a601316bd65..eba27192235 100644 --- a/src/tools/generate/generate_ebooks.js +++ b/src/tools/generate/generate_ebooks.js @@ -13,16 +13,24 @@ const update_links = (chapter) => { let body = chapter.body; // Replace current chapter links to full anchor link (e.g. #introduction -> #javascript-introduction) body = body.replace(/href="#/g,'href="#' + chapter.metadata.chapter + '-'); + // Replace aria-labelledby ids to full id (e.g. aria-labelledby="fig-1..." -> aria-labelledby="javascript-fig-1...") + body = body.replace(/aria-labelledby="fig([0-9_-])/g,'aria-labelledby="' + chapter.metadata.chapter + '-fig$1'); + // Replace aria-describedby ids to full id (e.g. aria-describedby="fig-1" -> aria-describedby="javascript-fig-1") + body = body.replace(/aria-describedby="fig([0-9_-])/g,'aria-describedby="' + chapter.metadata.chapter + '-fig$1'); // Replace current chapter fig ids to full id (e.g. id="fig-1" -> id="javascript-fig-1") body = body.replace(/id="fig([0-9_-])/g,'id="' + chapter.metadata.chapter + '-fig$1'); - // Replace current chapter header ids to full id (e.g.

    ->

    ) - body = body.replace(/ ->

    ) + body = body.replace(/ #javascript-fig-1) body = body.replace(/ #javascript) body = body.replace(/(.*?)<\/a>/g,'href="$1"$2>$3$1'); // Replace figure image links to full site, to avoid 127.0.0.1:8080 links body = body.replace(/