profile
viewpoint
Addy Osmani addyosmani Google Mountain View, California https://www.addyosmani.com Engineering Manager at Google working on Chrome & Web Platform

addyosmani/backbone-fundamentals 9464

:book: A creative-commons book on Backbone.js for beginners and advanced users alike

addyosmani/a11y 1653

Accessibility audit tooling for the web (beta)

addyosmani/backbone-boilerplates 493

Backbone.js stack boilerplates demonstrating integration with Express, Ruby, PHP, Grails and more.

aaronfrost/grunt-traceur 206

This is a grunt task for adding a grunt task to compiler ES6 JS into ES3 JS using Traceur Compiler

addyosmani/backbone-mobile-search 158

A Backbone.js + jQuery Mobile sample app using AMD for separation of modules, Require.js for dependency management + template externalisation and Underscore for templating

addyosmani/angular1-dribbble-pwa 102

Angular 1 Dribbble Progressive Web App demo

addyosmani/backbonejs-gallery 73

A Backbone, Underscore and jQuery Templates based image gallery (early early beta)

addyosmani/a11y-webapp 45

A11y WebApp built with Polymer (WIP)

addyosmani/backbone-koans-qunit 44

Backbone Koans for QUnit

addyosmani/backbone-aura 38

Backbone Aura

PR closed GoogleChrome/accessibility-developer-tools

Fix table audits

This pull request fixes two things regarding table auditing:

  1. The table checks never ran, they were forgotten in the QUnit HTML :warning:. This is fixed in 9095d4f.
  2. The table checks failed with an 'undefined' is not an object (evaluating 'headerRow.children') on some pages. This is due to the fact that the auditor assumes a complete table. If the markup is broken however, let's say an empty <table></table> without a single <tr> then there are no rows. This is fixed via 4f899db.
+18 -0

6 comments

3 changed files

joscha

pr closed time in 3 days

PR closed GoogleChrome/accessibility-developer-tools

fix: `isLargeFont` should not die on documents without body

In some rare cases document.body is not defined. In these cases the isLargeFont method dies due to

TypeError: 'null' is not an object (evaluating 'window.getComputedStyle(document.body, null).fontSize')

This PR fixes this and adds one test for isLargeFont (was added to make sure there is no regression)

+8 -1

6 comments

2 changed files

joscha

pr closed time in 3 days

PR closed addyosmani/ember-progressive-webapp

Update to latest deps

Performance differences with Lighthouse now that time to interaction is tracked:

screen shot 2016-10-13 at 6 00 20 pm

The differences here are pretty stark. Although TTI should really be closer to 2s, it's getting to a point where it's much closer to that mark. Ember have said they're still working on compatibility fixes for Glimmer 2 initially and perf later. Will be interesting to see how much better this gets over time.

+17 -10

2 comments

2 changed files

addyosmani

pr closed time in 3 days

issue closedaddyosmani/preact-hn

Bug with Offline Mode (replaceState)

#3 uncovered another small bug. When the Settings menu has been toggled, offline mode is

triggering this.replaceState exceptions in StoryListItem.js:

5453

closed time in 11 days

addyosmani

issue closedPolymer/tools

Add Lighthouse integration

Description

Polymer CLI currently offers a first-class experience for scaffolding PWAs. Something it doesn't include out of the box is the ability to audit these PWAs to make sure you know if you're staying on a fast path performance/feature wise or have slipped up from version to version.

Adding support for Lighthouse via a polymer audit flag could enable this pretty easily.

image

Lighthouse can be consumed as a Node module if Polymer requires more custom reporting (feel free to call or reuse CLI code). Similarly, if you wanted to just spawn and call out to Lighthouse that would work too.

Dev vs production

It's probably more valuable auditing the app at a point when it's closer to being production ready. It may be worth looking at what considerations this requires (e.g how close to prod is polymer serve going to be, should we find a way to encourage testing a deploy etc). This becomes interesting as folks look at different ways of using PRPL, deploying with preload or H/2 Push etc.

Other ideas

One could also extend polymer.json to support mapping an audit configuration to Lighthouse config in case folks want to also save audit assets or control whether CPU throttling or device emulation get used. Something like this:

{
	"entrypoint": "index.html",
	"shell": "src/my-app/my-app.html",
	"audit": {
          "disableDeviceEmulation": true,
	  "disableCPUThrottling": false,
	  "saveArtifacts": true
	}
}

Custom audits

If at some point Polymer wanted to write their own gathering audits for Lighthouse that provide further insight into perf/patterns folks should avoid that could also be an interesting next step. You could imagine the report including hints like use <slot> instead of <content>, 2.0 removes :root selector etc.

Thoughts?

closed time in 11 days

addyosmani

issue closedGoogleChromeLabs/discovery

Production Web Apps Performance Study Q4/16 - Q1/17

Goals

  • Understand the cost of JS Parse/Compile/FunctionCall times on apps
  • Discover how quickly apps become interactive on average mobile hardware
  • Learn how much JavaScript apps are shipping down on desktop + mobile

Sample information 6000+ production sites using one of React, Angular 1.0, Ember, Polymer, jQuery or Vue.js. Site URLs were obtained from a combination of Libscore.io, BigQuery, BuiltWith-style sites, framework wikis. Sample sets were 10% eye-balled to verify usage of frameworks. Sets not reliable were discarded from the final study.

URLs: https://docs.google.com/a/google.com/spreadsheets/d/1_gqtaEwjoJGbekgeEaYLbUyR4kcp5E7uZuMHYgLJjGY/edit?usp=sharing

Trivia: All in all, 85,000 WebPageTest results were generated as part of this study. Yipes.

Tools used in study WebPageTest.org (with enhancements such a JS cost, TTI, aggregated V8 statistics added thanks to Pat Meenan as the project progressed), Catapult (internal Google tool), Chrome Tracing.

Summary observations

metrics comparison

breakdowns

mobile-desktop-stury

screen shot 2017-02-06 at 5 19 56 pm

This data may be useful to developers as it shows:

  • Real, production apps using their favorite stacks can be much more expensive on mobile than they might think.
  • Closer attention to lower parse times and time-to-interactive points is likely required if you're choosing something off the shelf.
  • Some, but not all, apps are shipping larger bundles. Where this is the case invest in code-splitting & reducing how much JS is used.

Where are the medians and aggregates?

The primary goals of this study were to highlight trends looking at the different data-sets available to me as a whole. Initially, I focused on summarizing this data at a per-framework level (e.g React apps in set 1 exhibited characteristic A). After reviewing this with the Chrome team, we decided presenting per-framework breakdowns were more susceptible to the takeaway being "oh, so I should just use framework X over Y because it is 2% better" instead of the important takeaways about parse/compile being a problem we all face.

To that end, the below charts are generated locally by fetching each of the WebPageTest reports for data-sets, iterating over a particular dimension (e.g Time-to-interactive, JS parse time) and getting the medians for different sets that are then plumbed into either Google Sheets or Numbers for charting. If you wish to recreate that setup yourself, you can grab the CSVs from the below reports.

Raw WebPageTest runs - Round 2 (January, 2017)

  • Ember production sites, Moto G4, 3G: https://www.webpagetest.org/result/170122_XX_TQD/ with runtime call stats
  • Ember production sites, desktop, cable: https://www.webpagetest.org/result/170122_RM_3GW/ with runtime call stats
  • Sites from the React Wiki, Moto G4, 3G: https://www.webpagetest.org/result/161218_05_c8320bc70144d48df218f230701ec2b8/
  • Sites from the React Wiki, Desktop, cable: https://www.webpagetest.org/result/170113_XJ_17TN/ (with runtime call stats)
  • Sites from the React Wiki, Nexus 5: https://www.webpagetest.org/result/170116_Z6_9GS/
  • Sites from the React Wiki, iPhone 6, cable: https://www.webpagetest.org/result/170116_MV_8VQ/
  • Libscore React apps, Moto G4, 3G: https://www.webpagetest.org/result/161218_GD_297def2a6c8e5bcf355566577d4ed7b9/
  • Libscore React apps, Desktop, cable: https://www.webpagetest.org/result/170114_TD_V4Z/
  • React + Webpack usage survey sites, Moto G4, 3G: https://www.webpagetest.org/result/170115_HM_EYT/
  • React + Webpack usage survey sites, Desktop, cable: https://www.webpagetest.org/result/170114_WN_V01/
  • Subset of Libscore Angular 1.0 apps, G4, 3G: https://www.webpagetest.org/result/170115_SZ_Z5N/
  • Subset of Libscore Angular 1.0 apps, desktop, cable, runtime call stats: https://www.webpagetest.org/result/170114_25_1DC/
  • Libscore jQuery apps, G4, 3G: https://www.webpagetest.org/result/161218_A4_20acbeb009bd0a44527d3e4d93f1de2a/
  • Vue.js production apps, G4, 3G: https://www.webpagetest.org/result/170115_HE_10EN/
  • Vue.js production apps, desktop, cable: https://www.webpagetest.org/result/170115_KH_10F5/ (note: the Vue sets are based on less complex apps than the other sets appear to contain, but this is a personal observation. <3 Vue otherwise)
  • Polymer apps in production, G4, 3G: https://www.webpagetest.org/result/170120_59_40GD/
  • Polymer apps in production, desktop, cable: https://www.webpagetest.org/result/170120_W1_40PP/
  • Polymer (based on custom list they provided) Moto G4, 3G: https://www.webpagetest.org/result/170125_GX_G9YF/
  • Mobile Top 10 Moto G4, 3G: https://www.webpagetest.org/result/161218_TD_2fcc131f975da7e19ddb750f4991421d/
  • Mobile Top 10 Desktop, Cable (with V8 runtime call stats in traces): https://www.webpagetest.org/result/170114_VE_TSK/
  • Production Progressive Web Apps, Moto G4, 3G: https://www.webpagetest.org/result/161218_DW_b3e87329f9a5029d63b67759054fb0ce/
  • Production Progressive Web Apps, Desktop, Cable: https://www.webpagetest.org/result/170114_CE_TY5/
  • Chrome Loading team top sites, Moto G4, 3G: https://www.webpagetest.org/result/161218_RS_4be952cee9b8bede5ea16c26594ac38a/
  • Chrome Loading team top sites, Desktop, cable: https://www.webpagetest.org/result/170114_4R_TT6/
  • V8 Team Top 25, Moto G4, 3G: https://www.webpagetest.org/result/161218_Q6_b3202df8ed80da21ec73d9afcedead76/
  • V8 Team Top 25, Desktop, Cable: https://www.webpagetest.org/result/170114_Y9_TW6/

Raw WebPageTest runs - Round 1 - Older study (December, 2016)

I put together this graphic when internally sharing the first version of this study. I decided to redo it as at least the network throttling setup from this study wasn't the same between the 2-3 web perf tooling systems used. This meant that while overall weight, time in script (parse/eval), FMP and load time were fine, the TTI numbers could not be concretely confirmed as 100% accurate. Instead, I redid the study once we added support for TTI to WebPageTest and I'd trust the numbers there (Round 2) a lot more.

screen shot 2016-12-12 at 9 18 38 am

  • Summary insights + further data from this study: https://docs.google.com/a/google.com/spreadsheets/d/1QRdYgGVdDYB7kgfFKg0-0ViUonpvt8SXxcvv0gXKsEg/edit?usp=sharing
  • React prod sites from their wiki - Moto G - https://www.webpagetest.org/result/161210_WK_aa40594011795974a4e2d26a24e0c3b6/
  • React prod sites from their wiki - iPhone - https://www.webpagetest.org/result/161210_M1_7d32c93c8dcfaaa46cef42125aec75ba/
  • Ember production sites - iPhone - https://www.webpagetest.org/result/161211_56_a8275acd05ef23932e85e1d83ceb8787/
  • Ember production sites - Moto G - https://www.webpagetest.org/result/161211_PJ_d46293b5026e8c3ca7fa85d680cf2b0d/
  • Loading team top sites - Moto G - https://www.webpagetest.org/result/161210_PC_82eaf67c4d57a8dbc533ad9c4a1ee08c/
  • Loading team top sites - iPhone - https://www.webpagetest.org/result/161210_B7_9b36e27c2eaa0cec9cd5f8353a64acaa/
  • Global top 10 mobile sites - iPhone - https://www.webpagetest.org/result/161210_93_ec315ea70330ecf03041396f21f5098f/
  • Global top 10 mobile sites - Moto G - https://www.webpagetest.org/result/161210_WD_e2f65275bd6b3950dd2b367195e4d395/
  • V8 top sites - Moto G - https://www.webpagetest.org/result/161210_MB_36ccea8a66638d08c5ea2855a04ca023/
  • V8 top sites - iPhone - https://www.webpagetest.org/result/161210_37_6bca043df3316fb6e55efdba67d4b7bf/
  • Speedometer 2 alpha - Moto G - https://www.webpagetest.org/result/161208_ET_6f0c253c8b2a92a74c8989b7fbdb8c9a/
  • Catapult tool - Libscore.io React apps - Nexus 5 - https://docs.google.com/spreadsheets/d/1C4mO62NjVSVOVTsezlPwyY_pMIDV5b0401arE9GNviA/edit?usp=sharing
  • Catapult tool - BuiltWith Angular - Nexus 5 - https://docs.google.com/spreadsheets/d/12Wb7fb15Kq9XeoAqKneGx12oD8dshe8MfCAf46lG1qQ/edit?usp=sharing
  • BigQuery - angular.module() usage - https://docs.google.com/spreadsheets/d/1xdOr1cV9JBPyqlsCcATZI-cToUh7AC3Zhp1KP1YZzdk/edit?usp=sharing
  • Catapult tool - Ember apps - Nexus 5 - https://docs.google.com/spreadsheets/d/1RwjhNnUQRkUXZXcnqj3zHISQFuiQnqhbH3qUc6owpHg/edit?usp=sharing
  • Catapult tool - Libscore jQuery apps - Nexus 5- https://docs.google.com/spreadsheets/d/10vHRVUF7WoFubki_wKCFKXvWILxva8gGbzomC-8-CqQ/edit?usp=sharing
  • Catapult tool - BigQuery - Sites using mod_pagespeed - Nexus 5 - https://docs.google.com/spreadsheets/d/1XpTMwpOkhrnpNLVfQGETqVK3TWVxIzrnGq5i1uqitb4/edit?usp=sharing
  • WebPageTest - Libscore - Angular (2000 apps): https://docs.google.com/spreadsheets/d/1OBvcDSyoKHTjdH2CALui88orDF_n-0Yi92J93LDpUjQ/edit#gid=646387798&vpid=AD1 (Median insights ~ compile 445ms, eval 1784ms, FMP 7.2s, SI: 9s. Most apps spent 4.6s in JS on startup)
  • WebPageTest - Libscore - Ember (695 apps): https://docs.google.com/spreadsheets/d/1m9eFna_Xg70c_MPG4tU9D4fOdJT9SZQ2u5fQCxEO--g/edit#gid=1536554622&vpid=AG649 (Median insights ~ compile 374ms, eval 2.7s, SI: 10s, FMP: 9s, load: 13.8s, most apps spent 6s in JS on startup)
  • WebPageTest - Libscore - React (2000 apps): https://docs.google.com/spreadsheets/d/1HliA4jUMfqd4vFLDkYoTZQRv1oM1rM_8ahBAsXYfuAE/edit#gid=1982534624&vpid=A1 (Median insights ~ compile 481ms, eval 2609ms, load: 15.5s, FMP 6.5s, SI: 8s. Most apps spent 4.5s in script on startup)

Other data sets generated (Dec, 2016)

Note: many of the below data sets were generated before we installed Moto G4s in WebPageTest and had to use the Moto G1 instead. Some of the data sets will also be using earlier versions of the time-to-interactive metric and should not be directly compared in most cases to the latest data from 2017. This is historical data that's interesting and may be worth reexploring where particular data-sets didn't end up making it to the final study results.

closed time in 11 days

addyosmani

issue closedvuejs-templates/pwa

Explore HTTP/2 Server Push manifest generation

Both polymer-cli and angular-cli are planning on adding support for automatically generating a HTTP/2 Server Push manifest if the user would like one. This can be useful for filling up "server think time" for the initial push.

https://github.com/Polymer/polymer-cli/pull/646 have their implementation up. We could use something like https://github.com/GoogleChrome/http2-push-manifest for the manifest generation on our side and wire it up as both a prompt question + run at build time.

closed time in 11 days

addyosmani

issue closedgoogle/web-starter-kit

[Discussion] Next release

It's been a while since we last tagged a release of WSK and much has changed in that time.

@jeffposnick @gauntface and I released Workbox as an evolution on sw-precache and toolbox. There's a PR switching WSK over to it in #937

@sgomes shipped Material Components Web with the Material Design team. It's unclear to me whether we should switch to using that over MDL for this project. I'd be interested in thoughts if folks have any strong opinions.

There's a backlog of PRs: https://github.com/google/web-starter-kit/pulls. Looking through some of them are additions I feel would detract from the simplicity of WSK while others like #933 look like they might be useful to bring in.

I would also like to evaluate if we can find some new blood to help maintain WSK. Many of us are juggling other projects atm and would love any help we can get.

closed time in 11 days

addyosmani

issue closedwmsmacdonald/delta-cache-browser

Demo? :)

Hey @wmsmacdonald. Over on the Chrome team we've been kicking around a few ideas for delta upgrading using Service Workers and came across your repo.

Is there a demo available where you're using delta patching + this setup/your express middleware bits together that folks can check out?

Cheers!

closed time in 11 days

addyosmani

issue closedgoogle/WebFundamentals

Expanded HTTP Caching best practices guide

Ship an expanded HTTP Caching best practices guide.

Jake has a caching best practices doc https://jakearchibald.com/2016/caching-best-practices/

Ilya has an older/existing write-up at https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

It would be great if we could reconcile any missing guidance here onto /web. Either by updating the existing article or introducing a supplementary one 🤔

closed time in 11 days

addyosmani

issue closedgoogle/WebFundamentals

Tracking User-centric Performance Metrics

Ship a primer on new loading speed metrics (Time to consistently interactive, FMP etc)

Phil worked on https://developers.google.com/web/updates/2017/06/user-centric-performance-metrics back in May. It would be great to expand on this and turn it into our canonical reference page on modern loading metrics.

closed time in 11 days

addyosmani

issue closedgoogle/WebFundamentals

The PRPL Pattern section

Initially we were thinking:

  • Intro to PRPL
  • How PRPL works
  • PRPL app architecture
  • Deploying PRPL apps
  • Lazy loading strategies for PRPL
  • Step-by-step
    • PRPL with Preact CLI
    • PRPL with Polymer App Toolbox
    • PRPL with Webpack

If we have time, we also suggested maybe working on a PRPL performance case study.

I'll defer to the grand master of all things PRPL, @arthurevans for what the final IA for this section might look like 👀

@petele I've nominally put this into the loading milestone for tracking. Let's chat further about where in the /web IA this should best fit.

closed time in 11 days

addyosmani

issue closedGoogleChromeLabs/discovery

Data-set: Sites representative of popular JavaScript loading patterns

Requirements:

  • Ordered by Alexa ranking
  • Optionally use Webpack (check Webpack JSON signature)
  • Optionally look at RequireJS usage. Is code bundled with it still being deployed?
  • Optionally use Browserify (separate run)
  • Have first-party JS where they're shipping more than 1 x JS file (separate run)

Who wanted this? V8

closed time in 11 days

addyosmani

issue closedGoogleChromeLabs/discovery

Data-set: Highly ranked Progressive Web Apps

Why?

This may be useful to help understand whether the presence of a Service Worker helps improve code caching in V8 given the heuristics are far easier to trigger when SW is present and scripts are stored from Cache Storage.

Just need to generate the list of sites and V8 can take on benchmarking from there.

closed time in 11 days

addyosmani

issue closedGoogleChromeLabs/discovery

Sites with the highest time-to-consistently interactive

Sample query from Rick:

SELECT
  JSON_EXTRACT(report, "$.audits.consistently-interactive.rawValue") AS ttci,
  JSON_EXTRACT(report, "$.audits.first-interactive.rawValue") AS ttfi,
  JSON_EXTRACT(report, "$.audits.first-meaningful-paint.rawValue") AS fmp
FROM
  [httparchive:har.latest_lighthouse_mobile]

closed time in 11 days

addyosmani

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 1a87107101dcada9c39ed1d41254e280b0a6ef85

[docs] Adds iframe lazy-loading (#3536) * Add reviewed draft * Address linting issues * address feedback: image resizing * Resize hero image * Update src/site/content/en/blog/iframe-lazy-loading/index.md Fix code-highlighting Co-authored-by: Kayce Basques <kayce@google.com> * images: update hero image * feedback: wrap lines to 80 * Revise primary showcase image * Add demo video * Update dates on content * Rephrase Facebook's widget Co-authored-by: Stoyan <ssttoo@ymail.com> * Style as screenshot * Bump date * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com> * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com> * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com> * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com> * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com> * [feedback] Remove bolding of body content * [feedback] Add note about progressive enhancement * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com> * Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Simon Pieters <zcorpan@gmail.com> * [feedback] Update Lite Mode line * [feedback] Add a note about loading=lazy/auto criteria * Add reviewers * [feedback] Add note about Chromium * [formatting] consistency with dimension quotes Co-authored-by: Kayce Basques <kayce@google.com> Co-authored-by: Stoyan <ssttoo@ymail.com> Co-authored-by: Joe Medley <jmedley@google.com> Co-authored-by: Simon Pieters <zcorpan@gmail.com>

view details

push time in 12 days

PR merged GoogleChrome/web.dev

Adds iframe lazy-loading cla: no

Reviewed by @kaycebasques in Google Docs. We'll tweak formatting, add a video demo and images here before landing.

Fixes #3500

+310 -0

12 comments

5 changed files

addyosmani

pr closed time in 12 days

issue closedGoogleChrome/web.dev

content: It's time to lazy-load offscreen iframes [2020-07-20]

  • thread
  • draft
  • next step: @addyosmani to address @kaycebasques's feedback

closed time in 12 days

kaycebasques

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 3ecf32a317535396c267f241d9ff70b30e691902

[formatting] consistency with dimension quotes

view details

push time in 12 days

PublicEvent

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 9373aa76cda32d5381efab42095b5413c34c6d86

[feedback] Add note about Chromium

view details

push time in 12 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 20d292094e3c750c0aebcdd3ac6f1bd369c4b0b9

Add reviewers

view details

push time in 12 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 462695969c0510ea4c3fe605f09aab5c24d94ca3

[feedback] Add a note about loading=lazy/auto criteria

view details

push time in 12 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-24+#updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.++This [demo](https://lazy-load.netlify.app/iframes/) of `<iframe loading=lazy>+shows lazy-loading video embeds:++<figure class="w-figure w-figure--fullbleed">+  <video controls autoplay loop muted class="w-screenshot">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.webm" type="video/webm">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.mp4" type="video/mp4">+  </video>+</figure>+++### Why should we lazy-load iframes?++Third-party embeds cover a wide range of use cases, from video players, to+social media posts, to ads. Often this content is not immediately visible in+the user's viewport. Rather, it's only seen once they scroll further down the+page. Despite this, users pay the cost of downloading data and costly+JavaScript for each frame, even if they don't scroll to it.++<figure class="w-figure">+<img src="./iframe-lazyloading.png" alt="Data-savings from using iframe+lazy-loading for an iframe. Eager loading pulls in 3MB in this example, while+lazy-loading does not pull in this code until the user scrolls closer to the+iframe.">+</figure>++Based off Chrome's research into [automatically lazy-loading offscreen iframes+for Data Saver+users](https://blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html),+lazy-loading iframes could lead to 2-3% median data savings, 1-2% [First+Contentful Paint](/fcp/) reductions at the median, and 2% [First Input+Delay](/fid/) (FID) improvements at the 95th percentile.++### How does native lazy-loading for iframes work?++The `loading` attribute allows a browser to defer loading offscreen iframes and+images until users scroll near them. `loading` supports three values:++*   `lazy`: is a good candidate for lazy-loading.+*   `eager`: is not a good candidate for lazy-loading. Load right away.+*   `auto`: browser will determine whether or not to lazily load.++{% Aside %}+`auto` is currently a non-standard value, but is the default in Chrome today.+Chrome intends on bringing a proposal for this value to the standards table.+{% endAside %}++Using the `loading` attribute on iframes works as follows:++```html+<!-- Lazy-load the iframe -->+<iframe src="https://example.com" +        loading="lazy" +        width="600" +        height="400"></iframe>++<!-- Eagerly load the iframe -->+<iframe src="https://example.com" +        width="600" +        height="400"></iframe>++<!-- or use loading="eager" to out of automatic +lazy-loading in Lite Mode -->+<iframe src="https://example.com" +        loading="eager" +        width="600" +        height="400"></iframe>+```++Not specifying the attribute at all will have the same impact as explicitly+eagerly loading the resource, except for [Lite+Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+users, where Chrome will use the `auto` value to decide whether it should be+lazy-loaded.++If you need to _dynamically_ create iframes via JavaScript, setting+`iframe.loading = 'lazy'` on the element is also+[supported](https://bugs.chromium.org/p/chromium/issues/detail?id=993273):++```js/2+var iframe = document.createElement('iframe');+iframe.src = 'https://example.com';+iframe.loading = 'lazy';+document.body.appendChild(iframe);+```++#### iframe-specific lazy-loading behavior++The loading attribute affects iframes differently than images, depending on+whether the iframe is hidden. (Hidden iframes are often used for analytics or+communication purposes.) Chrome uses the following criteria to determine+whether an iframe is hidden:

Roger. Will add a note.

addyosmani

comment created time in 12 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha fb2a01d2f0224f6a69d282697231cc457daaba41

[feedback] Update Lite Mode line

view details

push time in 12 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-24+#updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.++This [demo](https://lazy-load.netlify.app/iframes/) of `<iframe loading=lazy>+shows lazy-loading video embeds:++<figure class="w-figure w-figure--fullbleed">+  <video controls autoplay loop muted class="w-screenshot">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.webm" type="video/webm">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.mp4" type="video/mp4">+  </video>+</figure>+++### Why should we lazy-load iframes?++Third-party embeds cover a wide range of use cases, from video players, to+social media posts, to ads. Often this content is not immediately visible in+the user's viewport. Rather, it's only seen once they scroll further down the+page. Despite this, users pay the cost of downloading data and costly+JavaScript for each frame, even if they don't scroll to it.++<figure class="w-figure">+<img src="./iframe-lazyloading.png" alt="Data-savings from using iframe+lazy-loading for an iframe. Eager loading pulls in 3MB in this example, while+lazy-loading does not pull in this code until the user scrolls closer to the+iframe.">+</figure>++Based off Chrome's research into [automatically lazy-loading offscreen iframes+for Data Saver+users](https://blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html),+lazy-loading iframes could lead to 2-3% median data savings, 1-2% [First+Contentful Paint](/fcp/) reductions at the median, and 2% [First Input+Delay](/fid/) (FID) improvements at the 95th percentile.++### How does native lazy-loading for iframes work?++The `loading` attribute allows a browser to defer loading offscreen iframes and+images until users scroll near them. `loading` supports three values:++*   `lazy`: is a good candidate for lazy-loading.+*   `eager`: is not a good candidate for lazy-loading. Load right away.+*   `auto`: browser will determine whether or not to lazily load.++{% Aside %}+`auto` is currently a non-standard value, but is the default in Chrome today.+Chrome intends on bringing a proposal for this value to the standards table.+{% endAside %}++Using the `loading` attribute on iframes works as follows:++```html+<!-- Lazy-load the iframe -->+<iframe src="https://example.com" +        loading="lazy" +        width="600" +        height="400"></iframe>++<!-- Eagerly load the iframe -->+<iframe src="https://example.com" +        width="600" +        height="400"></iframe>++<!-- or use loading="eager" to out of automatic +lazy-loading in Lite Mode -->+<iframe src="https://example.com" +        loading="eager" +        width="600" +        height="400"></iframe>+```++Not specifying the attribute at all will have the same impact as explicitly+eagerly loading the resource, except for [Lite+Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+users, where Chrome will use the `auto` value to decide whether it should be+lazy-loaded.++If you need to _dynamically_ create iframes via JavaScript, setting+`iframe.loading = 'lazy'` on the element is also+[supported](https://bugs.chromium.org/p/chromium/issues/detail?id=993273):++```js/2+var iframe = document.createElement('iframe');+iframe.src = 'https://example.com';+iframe.loading = 'lazy';+document.body.appendChild(iframe);+```++#### iframe-specific lazy-loading behavior++The loading attribute affects iframes differently than images, depending on+whether the iframe is hidden. (Hidden iframes are often used for analytics or+communication purposes.) Chrome uses the following criteria to determine+whether an iframe is hidden:++*   The iframe's width and height are `4px` or smaller.+*   `display: none` or `visibility: hidden` is applied.+*   The iframe is placed off-screen using negative X or Y positioning.++If an iframe meets any of these conditions, Chrome considers it hidden and+won't lazy-load it in most cases. iframes that aren't hidden will only load+when they're within the [load-in distance+threshold](/native-lazy-loading/#load-in-distance-threshold). Chrome shows a+placeholder for lazy-loaded iframes that are still being fetched.++### What impact might we see from lazy-loading popular iframe embeds?++What if we could change the web at large so that lazy-loading offscreen iframes+was the default? It would look a little like this:++Lazy-loading YouTube video embeds (saves ~500KB on initial page load):++```html/1+<iframe src="https://www.youtube.com/embed/YJGCZCaIZkQ"+        loading="lazy" +        width="560" +        height="315" +        frameborder="0" +        allow="accelerometer; autoplay; +        encrypted-media; gyroscope; +        picture-in-picture" +        allowfullscreen></iframe>+```++**Anecdote:** when we switched to lazy-loading YouTube embeds for Chrome.com,+we saved 10 seconds off of how soon our pages could be interactive on mobile+devices. I have opened an internal bug with YouTube to discuss adding+`loading=lazy` to its embed code.++<figure class="w-figure">+<img src="./iframe-chromecom.png" alt="Chrome.com achieved a 10 second+reduction in Time To Interactive by lazy-loading offscreen iframes for their+YouTube video embed">+</figure>++{% Aside %}+If you are looking for more efficient ways to load YouTube embeds, you may be+interested in the [YouTube lite+component](https://github.com/paulirish/lite-youtube-embed).+{% endAside %}++**Lazy-loading Instagram embeds (saves >100KB gzipped on initial load):**++Instagram embeds provide a block of markup and a script, which injects an+iframe into your page. Lazy-loading this iframe avoids having to load all of+the script necessary for the embed. Given such embeds are often displayed below+the viewport in most articles, this seems like a reasonable candidate for+native lazy-loading of their iframe.++**Lazy-loading Spotify embeds (saves 514KB on initial load):**++```html+<iframe src="https://open.spotify.com/embed/album/1DFixLWuPkv3KT3TnV35m3" +        loading="lazy"+        width="300" +        height="380" +        frameborder="0" +        allowtransparency="true" +        allow="encrypted-media"></iframe>+```++Although the above embeds illustrate the potential benefits to lazy-loading+iframes for media content, there's the potential to also see these benefits for+ads.  ++### Case study: Natively lazy-loading the Facebook's social plugins++Facebook's _social plugins_ allow developers to embed Facebook content in their+web pages. There's a number of these plugins offered, such as embedded posts,+photos, videos, comments… The most popular is the [Like+plugin](https://developers.facebook.com/docs/plugins/like-button/) - a button+that shows a count of who has "liked" the page. By default, embedding the Like+plugin in a webpage (using the FB JSSDK) pulls in ~215KB of resources, 197KB of+which is JavaScript. In many cases, the plugin may appear at the end of an+article or near the end of a page, so loading it eagerly when it's offscreen+may be suboptimal.++<figure class="w-figure">+  <img class="w-screenshot" src="./fblike.png" alt="Facebook Like Button">+</figure>++Thanks to engineer Stoyan Stefanov, [all of Facebook's social plugins now+support native iframe+lazy-loading](https://developers.facebook.com/docs/plugins/like-button#settings).+Developers who opt in to lazy-loading via the plugins' `data-lazy`+configuration will now be able to avoid it loading until the user scrolls+nearby. This enables the embed to still fully function for users that need it,+while offering data-savings for those who are not scrolling all the way down a+page. We are hopeful this is the first of many embeds to explore native iframe+lazy-loading in production.++### Wait, can't browsers just automatically lazy-load offscreen iframes?++They certainly can. In Chrome 77, Chrome added support for automatically+natively lazy-loading offscreen images and iframes when a user has opted into+[Lite Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+(Data Saver mode) in Chrome for Android. ++Lite Mode users are commonly in regions of the world where network connection+quality and data savings plans are not the greatest. Every byte matters and so

That's a good suggestion! I'll update to account for this shortly.

addyosmani

comment created time in 12 days

push eventaddyosmani/tmdb-viewer

Addy Osmani

commit sha bd2cc47128a1837733872762770fa08adac82c54

[infra] update package.json

view details

push time in 12 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha c4e5fd129d331807cfce45fb61aabdfb8d69b849

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Simon Pieters <zcorpan@gmail.com>

view details

push time in 12 days

startedsindresorhus/css-in-readme-like-wat

started time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-19+updated: 2020-07-20

SGTM!

addyosmani

comment created time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-21+updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++**Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.**

Bolding removed in https://github.com/GoogleChrome/web.dev/pull/3536/commits/d28e1e80be0072d4e52bf59fa01d500947240280

addyosmani

comment created time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 4a9ee50e691f0ff0cdcf1ca385d9a016b2f1b695

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com>

view details

push time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-22+#updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++**Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.**++This video shows+a [demo](https://lazy-load.netlify.app/iframes/) of `<iframe loading=lazy>` to lazy-load video embeds:++<figure class="w-figure w-figure--fullbleed">+  <video controls autoplay loop muted class="w-screenshot">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.webm" type="video/webm">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.mp4" type="video/mp4">+  </video>+</figure>+++### Why should we lazy-load iframes?++Third-party embeds cover a wide range of use cases, from video players, to+social media posts, to ads. Often this content is not immediately visible in+the users viewport. Rather, it's only seen once they scroll further down the+page. Despite this, users pay the cost of downloading data and costly+JavaScript for each frame, even if they don't scroll to it.++<figure class="w-figure">+<img src="./iframe-lazyloading.png" alt="Data-savings from using iframe+lazy-loading for an iframe. Eager loading pulls in 3MB in this example, while+lazy-loading does not pull in this code until the user scrolls closer to the+iframe.">+</figure>++Based off Chrome's research into [automatically lazy-loading offscreen iframes+for Data Saver+users](https://blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html),+lazy-loading iframes could lead to 2-3% median data savings, 1-2% [First+Contentful Paint](/fcp/) reductions at the median, and 2% [First Input+Delay](/fid/) (FID) improvements at the 95th percentile.++### How does native lazy-loading for iframes work?++The `loading` attribute allows a browser to defer loading offscreen iframes and+images until users scroll near them. `loading` supports three values:++*   `lazy`: is a good candidate for lazy-loading.+*   `eager`: is not a good candidate for lazy-loading. Load right away.+*   `auto`: browser will determine whether or not to lazily load.++{% Aside %}+`auto` is currently a non-standard value, but is the default in Chrome today.+Chrome intends on bringing a proposal for this value to the standards table.+{% endAside %}++Using the `loading` attribute on iframes works as follows:++```html+<!-- Lazy-load the iframe -->+<iframe src="https://example.com" +        loading="lazy" +        width="600" +        height="400"></iframe>++<!-- Eagerly load the iframe -->+<iframe src="https://example.com" +        width="600" +        height="400"></iframe>++<!-- or use loading="eager" to out of automatic +lazy-loading in Lite Mode -->+<iframe src="https://example.com" +        loading="eager" +        width="600" +        height="400"></iframe>+```++Not specifying the attribute at all will have the same impact as explicitly+eagerly loading the resource, except for [Lite+Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+users, where Chrome will use the `auto` value to decide whether it should be+lazy-loaded.++If you need to _dynamically_ create iframes via JavaScript, setting+`iframe.loading = 'lazy'` on the element is also+[supported](https://bugs.chromium.org/p/chromium/issues/detail?id=993273):++```js/2+var iframe = document.createElement('iframe');+iframe.src = 'https://example.com';+iframe.loading = 'lazy';+document.body.appendChild(iframe);+```++#### iframe-specific lazy-loading behavior++The loading attribute affects iframes differently than images, depending on+whether the iframe is hidden. (Hidden iframes are often used for analytics or+communication purposes.) Chrome uses the following criteria to determine+whether an iframe is hidden:++*   The iframe's width and height are `4px` or smaller.+*   `display: none` or `visibility: hidden` is applied.+*   The iframe is placed off-screen using negative X or Y positioning.++If an iframe meets any of these conditions, Chrome considers it hidden and+won't lazy-load it in most cases. iframes that aren't hidden will only load+when they're within the [load-in distance+threshold](/native-lazy-loading/#load-in-distance-threshold). Chrome shows a+placeholder for lazy-loaded iframes that are still being fetched.++### What impact might we see from lazy-loading popular iframe embeds?++What if we could change the web at large so that lazy-loading offscreen iframes+was the default? It would look a little like this:++Lazy-loading YouTube video embeds (saves ~500KB on initial page load):++```html/1+<iframe src="https://www.youtube.com/embed/YJGCZCaIZkQ"+        loading="lazy" +        width="560" +        height="315" +        frameborder="0" +        allow="accelerometer; autoplay; +        encrypted-media; gyroscope; +        picture-in-picture" +        allowfullscreen></iframe>+```++**Anecdote:** when we switched to lazy-loading YouTube embeds for Chrome.com,+we saved 10 seconds off of how soon our pages could be interactive on mobile+devices. I have opened an internal bug with YouTube to discuss adding+`loading=lazy` to its embed code.++<figure class="w-figure">+<img src="./iframe-chromecom.png" alt="Chrome.com achieved a 10 second+reduction in Time To Interactive by lazy-loading offscreen iframes for their+YouTube video embed">+</figure>++{% Aside %}+If you are looking for more efficient ways to load YouTube embeds, you may be+interested in the [YouTube lite+component](https://github.com/paulirish/lite-youtube-embed).+{% endAside %}++**Lazy-loading Instagram embeds (saves >100KB gzipped on initial load):**++Instagram embeds provide a block of markup and a script, which injects an+iframe into your page. Lazy-loading this iframe avoids having to load all of+the script necessary for the embed. Given such embeds are often displayed below+the viewport in most articles, this seems like a reasonable candidate for+native lazy-loading of their iframe.++**Lazy-loading Spotify embeds (saves 514KB on initial load):**++```html+<iframe src="https://open.spotify.com/embed/album/1DFixLWuPkv3KT3TnV35m3" +        loading="lazy"+        width="300" +        height="380" +        frameborder="0" +        allowtransparency="true" +        allow="encrypted-media"></iframe>+```++Although the above embeds illustrate the potential benefits to lazy-loading+iframes for media content, there's the potential to also see these benefits for+ads.  ++### Case study: Natively lazy-loading the Facebook's social plugins++Facebook's _social plugins_ allow developers to embed Facebook content in their+web pages. There's a number of these plugins offered, such as embedded posts,+photos, videos, comments… The most popular is the [Like+plugin](https://developers.facebook.com/docs/plugins/like-button/) - a button+that shows a count of who has "liked" the page. By default, embedding the Like+plugin in a webpage (using the FB JSSDK) pulls in ~215KB of resources, 197KB of+which is JavaScript. In many cases, the plugin may appear at the end of an+article or near the end of a page, so loading it eagerly when it's offscreen+may be suboptimal.++<figure class="w-figure">+  <img class="w-screenshot" src="./fblike.png" alt="Facebook Like Button">+</figure>++Thanks to engineer Stoyan Stefanov, [all of Facebook's social plugins now+support native iframe+lazy-loading](https://developers.facebook.com/docs/plugins/like-button#settings).+Developers who opt in to lazy-loading via the plugins' `data-lazy`+configuration will now be able to avoid it loading until the user scrolls+nearby. This enables the embed to still fully function for users that need it,+while offering data-savings for those who are not scrolling all the way down a+page. We are hopeful this is the first of many embeds to explore native iframe+lazy-loading in production.++### Wait, can't browsers just automatically lazy-load offscreen iframes?++They certainly can. In Chrome 77, Chrome added support for automatically+natively lazy-loading offscreen images and iframes when a user has opted into+[Lite Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+(Data Saver mode) in Chrome for Android. ++Lite Mode users are commonly in regions of the world where network connection+quality and data savings plans are not the greatest. Every byte matters and so+lazy-loading iframes has the potential to make a meaningful difference for+these users.++Origins can detect what percentage of their traffic is coming from Lite Mode+users by checking the `navigator.connection.saveData` JavaScript API.++### Can I lazy-load iframes cross-browser? Yes++It is also possible to lazy-load offscreen iframes using the+[lazysizes](/use-lazysizes-to-lazyload-images/) library. ++This may be desirable if you:++*   require more custom lazy-loading thresholds than what native lazy-loading+currently offers+*   are implementing lazy-loading cross-browser

Cool! Updated in https://github.com/GoogleChrome/web.dev/pull/3536/commits/d377edb419665320b57fe4052948f48407e3ce2a

addyosmani

comment created time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha d28e1e80be0072d4e52bf59fa01d500947240280

[feedback] Remove bolding of body content

view details

Addy Osmani

commit sha d377edb419665320b57fe4052948f48407e3ce2a

[feedback] Add note about progressive enhancement

view details

push time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-21+updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++**Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.**

Okay. In the upcoming commits I will drop this formatting. Thanks for the sanity check

addyosmani

comment created time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 876898a6bfa9a6231d7485aa49e00c7cd3543d07

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com>

view details

push time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha f701286159dc4e84f9be4f26c116fa64abcd92db

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com>

view details

push time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha d9c2ace3a87330932bd9d81070c1692138a8674d

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com>

view details

push time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 6d5b6b1c9e66b33a4a6875f7c7f02da402258f10

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com>

view details

push time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-22+#updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++**Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.**++This video shows+a [demo](https://lazy-load.netlify.app/iframes/) of `<iframe loading=lazy>` to lazy-load video embeds:++<figure class="w-figure w-figure--fullbleed">+  <video controls autoplay loop muted class="w-screenshot">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.webm" type="video/webm">+    <source src="https://storage.googleapis.com/web-dev-assets/iframe-lazy-loading/lazyload-iframes-compressed.mp4" type="video/mp4">+  </video>+</figure>+++### Why should we lazy-load iframes?++Third-party embeds cover a wide range of use cases, from video players, to+social media posts, to ads. Often this content is not immediately visible in+the users viewport. Rather, it's only seen once they scroll further down the+page. Despite this, users pay the cost of downloading data and costly+JavaScript for each frame, even if they don't scroll to it.++<figure class="w-figure">+<img src="./iframe-lazyloading.png" alt="Data-savings from using iframe+lazy-loading for an iframe. Eager loading pulls in 3MB in this example, while+lazy-loading does not pull in this code until the user scrolls closer to the+iframe.">+</figure>++Based off Chrome's research into [automatically lazy-loading offscreen iframes+for Data Saver+users](https://blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html),+lazy-loading iframes could lead to 2-3% median data savings, 1-2% [First+Contentful Paint](/fcp/) reductions at the median, and 2% [First Input+Delay](/fid/) (FID) improvements at the 95th percentile.++### How does native lazy-loading for iframes work?++The `loading` attribute allows a browser to defer loading offscreen iframes and+images until users scroll near them. `loading` supports three values:++*   `lazy`: is a good candidate for lazy-loading.+*   `eager`: is not a good candidate for lazy-loading. Load right away.+*   `auto`: browser will determine whether or not to lazily load.++{% Aside %}+`auto` is currently a non-standard value, but is the default in Chrome today.+Chrome intends on bringing a proposal for this value to the standards table.+{% endAside %}++Using the `loading` attribute on iframes works as follows:++```html+<!-- Lazy-load the iframe -->+<iframe src="https://example.com" +        loading="lazy" +        width="600" +        height="400"></iframe>++<!-- Eagerly load the iframe -->+<iframe src="https://example.com" +        width="600" +        height="400"></iframe>++<!-- or use loading="eager" to out of automatic +lazy-loading in Lite Mode -->+<iframe src="https://example.com" +        loading="eager" +        width="600" +        height="400"></iframe>+```++Not specifying the attribute at all will have the same impact as explicitly+eagerly loading the resource, except for [Lite+Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+users, where Chrome will use the `auto` value to decide whether it should be+lazy-loaded.++If you need to _dynamically_ create iframes via JavaScript, setting+`iframe.loading = 'lazy'` on the element is also+[supported](https://bugs.chromium.org/p/chromium/issues/detail?id=993273):++```js/2+var iframe = document.createElement('iframe');+iframe.src = 'https://example.com';+iframe.loading = 'lazy';+document.body.appendChild(iframe);+```++#### iframe-specific lazy-loading behavior++The loading attribute affects iframes differently than images, depending on+whether the iframe is hidden. (Hidden iframes are often used for analytics or+communication purposes.) Chrome uses the following criteria to determine+whether an iframe is hidden:++*   The iframe's width and height are `4px` or smaller.+*   `display: none` or `visibility: hidden` is applied.+*   The iframe is placed off-screen using negative X or Y positioning.++If an iframe meets any of these conditions, Chrome considers it hidden and+won't lazy-load it in most cases. iframes that aren't hidden will only load+when they're within the [load-in distance+threshold](/native-lazy-loading/#load-in-distance-threshold). Chrome shows a+placeholder for lazy-loaded iframes that are still being fetched.++### What impact might we see from lazy-loading popular iframe embeds?++What if we could change the web at large so that lazy-loading offscreen iframes+was the default? It would look a little like this:++Lazy-loading YouTube video embeds (saves ~500KB on initial page load):++```html/1+<iframe src="https://www.youtube.com/embed/YJGCZCaIZkQ"+        loading="lazy" +        width="560" +        height="315" +        frameborder="0" +        allow="accelerometer; autoplay; +        encrypted-media; gyroscope; +        picture-in-picture" +        allowfullscreen></iframe>+```++**Anecdote:** when we switched to lazy-loading YouTube embeds for Chrome.com,+we saved 10 seconds off of how soon our pages could be interactive on mobile+devices. I have opened an internal bug with YouTube to discuss adding+`loading=lazy` to its embed code.++<figure class="w-figure">+<img src="./iframe-chromecom.png" alt="Chrome.com achieved a 10 second+reduction in Time To Interactive by lazy-loading offscreen iframes for their+YouTube video embed">+</figure>++{% Aside %}+If you are looking for more efficient ways to load YouTube embeds, you may be+interested in the [YouTube lite+component](https://github.com/paulirish/lite-youtube-embed).+{% endAside %}++**Lazy-loading Instagram embeds (saves >100KB gzipped on initial load):**++Instagram embeds provide a block of markup and a script, which injects an+iframe into your page. Lazy-loading this iframe avoids having to load all of+the script necessary for the embed. Given such embeds are often displayed below+the viewport in most articles, this seems like a reasonable candidate for+native lazy-loading of their iframe.++**Lazy-loading Spotify embeds (saves 514KB on initial load):**++```html+<iframe src="https://open.spotify.com/embed/album/1DFixLWuPkv3KT3TnV35m3" +        loading="lazy"+        width="300" +        height="380" +        frameborder="0" +        allowtransparency="true" +        allow="encrypted-media"></iframe>+```++Although the above embeds illustrate the potential benefits to lazy-loading+iframes for media content, there's the potential to also see these benefits for+ads.  ++### Case study: Natively lazy-loading the Facebook's social plugins++Facebook's _social plugins_ allow developers to embed Facebook content in their+web pages. There's a number of these plugins offered, such as embedded posts,+photos, videos, comments… The most popular is the [Like+plugin](https://developers.facebook.com/docs/plugins/like-button/) - a button+that shows a count of who has "liked" the page. By default, embedding the Like+plugin in a webpage (using the FB JSSDK) pulls in ~215KB of resources, 197KB of+which is JavaScript. In many cases, the plugin may appear at the end of an+article or near the end of a page, so loading it eagerly when it's offscreen+may be suboptimal.++<figure class="w-figure">+  <img class="w-screenshot" src="./fblike.png" alt="Facebook Like Button">+</figure>++Thanks to engineer Stoyan Stefanov, [all of Facebook's social plugins now+support native iframe+lazy-loading](https://developers.facebook.com/docs/plugins/like-button#settings).+Developers who opt in to lazy-loading via the plugins' `data-lazy`+configuration will now be able to avoid it loading until the user scrolls+nearby. This enables the embed to still fully function for users that need it,+while offering data-savings for those who are not scrolling all the way down a+page. We are hopeful this is the first of many embeds to explore native iframe+lazy-loading in production.++### Wait, can't browsers just automatically lazy-load offscreen iframes?++They certainly can. In Chrome 77, Chrome added support for automatically+natively lazy-loading offscreen images and iframes when a user has opted into+[Lite Mode](https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html)+(Data Saver mode) in Chrome for Android. ++Lite Mode users are commonly in regions of the world where network connection+quality and data savings plans are not the greatest. Every byte matters and so+lazy-loading iframes has the potential to make a meaningful difference for+these users.++Origins can detect what percentage of their traffic is coming from Lite Mode+users by checking the `navigator.connection.saveData` JavaScript API.++### Can I lazy-load iframes cross-browser? Yes++It is also possible to lazy-load offscreen iframes using the+[lazysizes](/use-lazysizes-to-lazyload-images/) library. ++This may be desirable if you:++*   require more custom lazy-loading thresholds than what native lazy-loading+currently offers+*   are implementing lazy-loading cross-browser

Do you have a suggestion to reword this? The nuance we are trying to convey is:

  • Native lazy-loading offers lazy-loading in a way that can be applied as a progressive enhancement. iframes with loading=lazy will continue to load per normal in browsers without native lazy-loading support
  • Folks that want to have this behavior cross-browser until it is widely supported have options like JS libraries.

Perhaps I can capture that nuance better here.

addyosmani

comment created time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-19+updated: 2020-07-20

Sure. Would you be comfortable with this landing/deploying early on Friday? I'd like to get this out before the end of the week as we have other performance announcements coming next week (elsewhere, Chromium) that I'd like to avoid keeping too close together if possible.

addyosmani

comment created time in 13 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 1f9eaf6325f5fb2093545cacd2d5449d4d75e9ec

Update src/site/content/en/blog/iframe-lazy-loading/index.md Co-authored-by: Joe Medley <jmedley@google.com>

view details

push time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-21+updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. ++```html/1+<iframe src="https://example.com"+        loading="lazy"+        width=600+        height=400></iframe>+```++**Native lazy-loading of iframes defers offscreen iframes from being loaded+until the user scrolls near them. This saves data, speeds up the loading of+other parts of the page, and reduces memory usage.**

This doesn't (imo) make sense as an aside. It's a body content summary of what the feature does. Is your concern that the content is bolded?

addyosmani

comment created time in 13 days

Pull request review commentGoogleChrome/web.dev

Adds iframe lazy-loading

+---+layout: post+title: It's time to lazy-load offscreen iframes!+subhead: Browser-level native lazy-loading for iframes is here+authors:+  - addyosmani+date: 2020-07-21+updated: 2020-07-21+hero: hero.png+alt: Phone outline with loading image and assets+description: |+  This post covers the loading attribute and how it can be used+  to control the loading of iframes.+tags:+  - blog # blog is a required tag for the article to show up in the blog.+  - performance+---++[Native lazy-loading for images](/native-lazy-loading) landed in Chrome 76 via+the `loading` attribute and later came to Firefox. We are happy to share that+**native lazy-loading for iframes** is now+[standardized](https://github.com/whatwg/html/pull/5579) and is also +supported in Chrome. 

Sure. Chromium is currently the only browser that supports native iframe lazy-loading.

addyosmani

comment created time in 13 days

issue closedpuppeteer/recorder

Scripts output are incomplete

When I record a set of actions and close Chromium, the Puppeteer Recorder script output is currently incomplete:

const {open, click, type, submit} = require('./lib/runner.js');
open('https://chrome.com', {}, async () => {
  await click('aria/button[name="Ok, Got it"]');
  await click('aria/link[name="Go to Next Section"]');

What we are missing above are the following lines:

const {open, click, type, submit} = require('./lib/runner.js');
open('https://chrome.com', {}, async () => {
  await click('aria/button[name="Ok, Got it"]');
  await click('aria/link[name="Go to Next Section"]');
+});

which would avoid this error during replay:

SyntaxError: Unexpected end of input
    at wrapSafe (internal/modules/cjs/loader.js:1063:16)
    at Module._compile (internal/modules/cjs/loader.js:1111:27)

closed time in 13 days

addyosmani

issue commentpuppeteer/recorder

Scripts output are incomplete

I believe this should be fixed now :)

addyosmani

comment created time in 13 days

pull request commentGoogleChrome/web.dev

Adds iframe lazy-loading

@kaycebasques @jpmedley This one should be good to go now. If there are any other changes you would like made, feel free to holler :)

addyosmani

comment created time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 15af81f49ee3dafc3a0465de5361bc12f51f4843

Update dates on content

view details

push time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 32107adb7e6d5482f2102d6b7b5df67fa9278f42

Add demo video

view details

push time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha c63e4e6bb7baa65ecfa372dbd475f10307d2e648

Revise primary showcase image

view details

push time in 14 days

pull request commentGoogleChrome/web.dev

Adds iframe lazy-loading

@addyosmani Can you please break the paragraphs to lines of 80 characters. It makes possible changes more granular and if there's multiple changes in a single paragraph it makes them a little easier to deal with.

Done. To the extent possible lines are not wrapped to 80 characters.

addyosmani

comment created time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 47e0d13431374dd8b8607a137521bdcfe9a52d22

feedback: wrap lines to 80

view details

push time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 84f2cea78612494bf44015ac47b9fc503ef1794f

images: update hero image

view details

Addy Osmani

commit sha 392bd319f4393b4bfa495a9a788f4c7aa2fbca10

Merge branch 'iframe-lazyloading' of https://github.com/GoogleChrome/web.dev into iframe-lazyloading

view details

push time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha b2acffcf3d612f619fd9a2bef0314d280f58d1a5

Update src/site/content/en/blog/iframe-lazy-loading/index.md Fix code-highlighting Co-authored-by: Kayce Basques <kayce@google.com>

view details

push time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 97a7798b08fd417d45f5075320dea17cf18c9f20

Resize hero image

view details

push time in 14 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 52e1feabdf182dc23d37c39acf4c3e6777ec73c5

address feedback: image resizing

view details

push time in 15 days

PR opened GoogleChrome/web.dev

Adds iframe lazy-loading DO NOT MERGE

Reviewed by @kaycebasques in Google Docs. We'll tweak formatting, add a video demo and images here before landing.

+213 -0

0 comment

5 changed files

pr created time in 15 days

create barnchGoogleChrome/web.dev

branch : iframe-lazyloading

created branch time in 15 days

delete branch GoogleChrome/web.dev

delete branch : chrome-86-lazy

delete time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 8e7c7e4cb3a095190dfdde712230af83573df921

Minor updates to native lazy-load (#3513) * Add details about improved thresholds * Add additional lazy-load images for M86 update * Align changes with latest team discussions * Minor tweak: thresholds -> threshold for image label * Add note about backported thresholds * Update section on downsides (bug fixed) * Minor tweak to Chrome versioning * Resize new images to address bot

view details

push time in 19 days

PR merged GoogleChrome/web.dev

Reviewers
Updates to native lazy-load cla: yes

This PR adds in changes to the native lazy-load for images doc to reflect recent implementation tweaks we have shipped.

+36 -12

1 comment

3 changed files

addyosmani

pr closed time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 344e04577bf59aef25e6ab5529133c0498c4cc05

Resize new images to address bot

view details

push time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha f702f30ba9ffd147a317d01c38a7886473915fef

Minor tweak to Chrome versioning

view details

push time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 8326ea8a03748fe7c9aac6b14740751c262dd618

Update section on downsides (bug fixed)

view details

push time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha f31a561b2c71278713dc3ad448ca2703945e3704

Add note about backported thresholds

view details

push time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 1e6d2c6a50fde1ce0c5254ca2f0c14fc0b72070a

Minor tweak: thresholds -> threshold for image label

view details

push time in 19 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 263df80ba296e0d42c1e30d9fc6fa94c3670d859

Align changes with latest team discussions

view details

push time in 19 days

PR opened GoogleChrome/web.dev

Updates to native lazy-load

This PR adds in changes to the native lazy-load for images doc to reflect recent implementation tweaks.

+28 -2

0 comment

3 changed files

pr created time in 19 days

create barnchGoogleChrome/web.dev

branch : chrome-86-lazy

created branch time in 19 days

delete branch GoogleChrome/web.dev

delete branch : lazy-load-updates

delete time in 22 days

PR merged GoogleChrome/web.dev

Reviewers
Updates to native lazy-loading guide cla: yes

Changes proposed in this pull request:

  • Re-focus this guide around native image lazy-loading (we'll cover iframes in more detail separately)
  • Expand guidance to better capture nuance about the Chromium implementation
  • Revise some of the FAQs and best practices

FYIs: @scott-little @domfarolino

There are still some changes I would like to land here covering CMS, but sharing progress so far.

+91 -72

3 comments

1 changed file

addyosmani

pr closed time in 22 days

pull request commentGoogleChrome/web.dev

Updates to native lazy-loading guide

I look forward to these, but for now, the changes look good.

Thank you, Dom! I have also just got word from Scott that he is comfortable with the numbers mentioned in the PR. Going to go ahead and land this.

Appreciate your reviews here, everyone!

addyosmani

comment created time in 22 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 5aa7e71b94f814cc1815de4a314b9cf647bf4714

Address feedback from Dom

view details

push time in 22 days

Pull request review commentGoogleChrome/web.dev

Updates to native lazy-loading guide

 The best practice of setting dimensions applies to `<img>` tags regardless of wh  Images will still lazy-load if dimensions are not included, but [specifying them decreases the chance of layout shift](https://www.youtube.com/watch?v=4-d_SoCHeWE). If you are unable to include dimensions for your images, lazy-loading them can be a trade-off between saving network resources and potentially being more at risk of layout shift.  -While native lazy-loading in Chromium is implemented in a way such that images are likely to be loaded once they are visible, it should be kept in mind, there is a slightly greater chance of them not being loaded yet. In this case, case missing `width` and `height` attributes on such images increase their impact on Cumulative Layout Shift.+While native lazy-loading in Chromium is implemented in a way such that images are likely to be loaded once they are visible, it should be kept in mind, there is a slightly greater chance of them not being loaded yet. In this case, missing `width` and `height` attributes on such images increase their impact on Cumulative Layout Shift.

The wording here could certainly be improved. I actually like your proposed version of this sentence. I'm going to go ahead and integrate this into the sentence as it's worded more clearly. Thanks, Dom!

addyosmani

comment created time in 22 days

issue openedpuppeteer/recorder

Support more interaction events

The full list of events I'd personally love to see are:

  • scroll
  • change
  • keydown
  • select
  • submit

Depending on how comprehensive we want to get, the list of events over in https://github.com/checkly/puppeteer-recorder/blob/master/src/code-generator/dom-events-to-record.js might also be good prior art to consult.

created time in 23 days

push eventGoogleChrome/web.dev

Addy Osmani

commit sha 19c364614f152a81d68c7fa9d0e203caadfb37d2

Address feedback from Houssein

view details

push time in 23 days

issue commentGoogleChrome/web-vitals-extension

[Feature] CrUX field data

Thanks for the reminder here, @rviscomi! Some thoughts:

  • Shall we align the UX for field insights with the current styles for CrUX data found in PSI?
  • > cache results to avoid calling the API on subsequent popup reopenings - yes! That would be great to land before we make this generally available.
  • > "inline" each tri-color histogram next to the local metrics for easier comparison - I think this could be an interesting idea but would love to work with Jiwoong to see if there's a UX mock we think could work for it. For the MVP, how would you feel about us getting out a version closer to the current PSI UX?
  • > request the URL first, and fall back to origin if it doesn't exist. I would be open to us doing this! I do think we would want to make it clear in the UI when this is happening so that its clear.
addyosmani

comment created time in 25 days

issue commentGoogleChrome/web-vitals-extension

[Feature] CrUX field data

Thanks for the reminder here, @rviscomi! Some thoughts:

  • Shall we align the UX for field insights with the current styles for CrUX data found in PSI?
  • > cache results to avoid calling the API on subsequent popup reopenings - yes! That would be great to land before we make this generally available.
  • > "inline" each tri-color histogram next to the local metrics for easier comparison - I think this could be an interesting idea but would love to work with Jiwoong to see if there's a UX mock we think could work for it. For the MVP, how would you feel about us getting out a version closer to the current PSI UX?
  • > request the URL first, and fall back to origin if it doesn't exist. I would be open to us doing this! I do think we would want to make it clear in the UI when this is happening so that its clear.
addyosmani

comment created time in 25 days

PR opened GoogleChrome/web.dev

Reviewers
Updates to native lazy-loading guide DO NOT MERGE

Changes proposed in this pull request:

  • Re-focus this guide around native image lazy-loading (we'll cover iframes in more detail separately)
  • Expand guidance to better capture nuance about the Chromium implementation
  • Revise some of the FAQs and best practices

FYIs: @scott-little @domfarolino

There are still some changes I would like to land here covering CMS, but sharing progress so far.

+92 -71

0 comment

1 changed file

pr created time in 25 days

create barnchGoogleChrome/web.dev

branch : lazy-load-updates

created branch time in 25 days

issue commentpuppeteer/recorder

Scripts output are incomplete

Thanks. I re-tested and can reproduce this behavior by closing Chromium via UI (in this case I am doing it by hitting X):

image

If I exit out of the process via CLI the last line is also omitted:

image

addyosmani

comment created time in 25 days

issue openedpuppeteer/recorder

Should navigations be made more explicit?

I attempted to use the Recorder to achieve the following:

  1. Navigate to pptr.dev
  2. Enter in a search term ("screenshot")
  3. In the results page, click on the word "selector"
  4. Be navigated to the MDN page for CSS selectors

The recorder was able to do great at steps 1-3. It was not able to capture that a navigation from the results page occurred in the script generated. This may make future debugging of scripts trickier.

Script:

const {open, click, type, submit} = require('./lib/runner.js');
open('https://pptr.dev', {}, async () => {
  await click('aria/searchbox[name="start typing to search..."]');
  await type('aria/searchbox[name="start typing to search..."]', 'screenshot');
  await click('body > search-component > search-results > search-item.selected > search-item-title');
  await click('aria/link[name="selector"]');
});

image

If I redo the flow and once I get to MDN, continue interacting with the page, it appears to be able to replay events that happen on the MDN page. I was a little surprised here as in other Puppeteer recording projects, there are explicit URLs captured when navigations are performed, whilst Puppeteer's approach to using Aria selectors seems to make this less explicit.

const {open, click, type, submit} = require('./lib/runner.js');
open('https://pptr.dev', {}, async () => {
  await click('aria/searchbox[name="start typing to search..."]');
  await type('aria/searchbox[name="start typing to search..."]', 'screen');
  await click('body > search-component > search-results > search-item.selected');
  await click('body > content-component > pptr-api > content-box:nth-child(7) > api-method:nth-child(79) > ul > li:nth-child(1)');
  await click('aria/link[name="selector"]');
  await click('aria/button[name="Close banner"]');
  await click('aria/link[name="Universal selector"]');
});

I wonder if a good middle-ground here would be generating a comment when navigations to different URLs occur? (e.g `/* Navigated to https://.... */)

created time in a month

issue openedpuppeteer/recorder

Inputs into password fields

I tried to record a user-flow for navigating to GitHub.com and entering in a username, email and password during sign-up. The script generated (with minor fix) is:

const {open, click, type, submit} = require('./lib/runner.js');
open('https://github.com', {}, async () => {
  await click('aria/textbox[name="Username"]');
  await type('aria/textbox[name="Username"]', 'puppeteermaster');
  await click('aria/textbox[name="Email"]');
  await type('aria/textbox[name="Email"]', 'puppeteer@pptr.dev');
  await click('aria/undefined[name="Password"]');
  await type('aria/undefined[name="Password"]', 'lalalalalalalalala');
});

The output appeared to have trouble with the password field, which has an area selector of undefined in the above script.

image

Expected: Screen Shot 2020-07-09 at 12 02 28 PM

Result: image

created time in a month

issue openedpuppeteer/recorder

Scripts output are incomplete

When I record a set of actions and close Chromium, the Puppeteer Recorder script output is currently incomplete:

const {open, click, type, submit} = require('./lib/runner.js');
open('https://chrome.com', {}, async () => {
  await click('aria/button[name="Ok, Got it"]');
  await click('aria/link[name="Go to Next Section"]');

What we are missing above are the following lines:

const {open, click, type, submit} = require('./lib/runner.js');
open('https://chrome.com', {}, async () => {
  await click('aria/button[name="Ok, Got it"]');
  await click('aria/link[name="Go to Next Section"]');
+});

which would avoid this error during replay:

SyntaxError: Unexpected end of input
    at wrapSafe (internal/modules/cjs/loader.js:1063:16)
    at Module._compile (internal/modules/cjs/loader.js:1111:27)

created time in a month

issue openedpuppeteer/recorder

Support writing output to disk

This is probably on your radar, but allowing a developer to specify an output path for the Puppeteer script we currently log to the console would be great for easier replay. e.g:

$ node ./lib/cli.js https://web.dev --output=web-dev.js

At present, using terminal commands to manually pipe to file is fine, but something like the above would be welcome... 😅

created time in a month

issue openedpuppeteer/recorder

web.dev search results flow

I attempted to use the recorder to do the following:

  1. Navigate to web.dev
  2. Enter "images" into the search field
  3. Click on the first result (Optimize images with Thumbor)

The first two steps complete correctly. The last step does not. I wonder if this may be due to it trying to perform the await click action prior to the fetch/render for the results DOM being ready?

const {open, click, type, submit} = require('./lib/runner.js');

open('https://web.dev', {}, async () => {
  await click('aria/searchbox[name="Search"]');
  await type('aria/searchbox[name="Search"]', 'images');
  await click('aria/link[name="Optimize images with Thumbor"]');
});

image

created time in a month

push eventaddyosmani/puppeteer-webperf

Joan León | @nucliweb

commit sha 9411b9f636241cefa35e467ff80da9894c1c209e

Optimized a few images

view details

Addy Osmani

commit sha 6b34357c81352684395ec562f7aedf19b009c8cc

Merge pull request #6 from nucliweb/feat/image-optimization Optimized a few images

view details

push time in a month

PR merged addyosmani/puppeteer-webperf

Optimized a few images

In this Pull Request

  • Optimized all images with ImageOptim

ImageOptim

+0 -0

1 comment

6 changed files

nucliweb

pr closed time in a month

pull request commentaddyosmani/puppeteer-webperf

Optimized a few images

👍

nucliweb

comment created time in a month

push eventaddyosmani/puppeteer-webperf

Oles Savluk

commit sha 96987b17180978051a9d391eec471a905c610048

[docs] fix typo in next.js link

view details

Addy Osmani

commit sha 42ee087e3fb3150ecd0d9dc6f3b4a2f56b95398b

Merge pull request #7 from olessavluk/master [docs] fix typo in next.js link of README.md

view details

push time in a month

pull request commentaddyosmani/puppeteer-webperf

[docs] fix typo in next.js link of README.md

Thanks, @olessavluk!

olessavluk

comment created time in a month

push eventaddyosmani/puppeteer-webperf

Joan León | @nucliweb

commit sha 5ba839c4289a28de854b7cab2d6747156490c019

Fixed devices

view details

Addy Osmani

commit sha 3c576d10e1099e8fea9cc0578022087807aaba73

Merge pull request #9 from nucliweb/fix/device-descriptors Fixed device descriptior

view details

push time in a month

pull request commentaddyosmani/puppeteer-webperf

Fixed device descriptior

👍 Thank you for catching this, @nucliweb!

nucliweb

comment created time in a month

PR merged addyosmani/puppeteer-webperf

Fixed device descriptior

In this Pull Request

Problem

When you run the script cumulative-layout-shift.js and largest-contentful-paint.js you get an error.

➜ node largest-contentful-paint.js
TypeError: Cannot read property 'viewport' of undefined
    at Page.emulate (/Users/joan.leon/projects/PerfReviews/.../puppeteer-webperf/node_modules/puppeteer/lib/Page.js:541:38)
    at Page.<anonymous> (/Users/joan.leon/projects/PerfReviews/.../puppeteer-webperf/node_modules/puppeteer/lib/helper.js:95:27)
    at getLCP (/Users/joan.leon/projects/PerfReviews/.../puppeteer-webperf/largest-contentful-paint.js:55:16)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
LCP is: undefined

This error is because the DeviceDescriptors export the devices inside devicesMap object.

Solution

Add the key devicesMap to get devices, like:

const phone = devices.devicesMap['Nexus 5X'];
+4 -4

1 comment

3 changed files

nucliweb

pr closed time in a month

PR merged addyosmani/puppeteer-webperf

Installed Lighthouse dependency

In this Pull Request

  • [x] installed the lighthouse dependency, needed to run lighthouse-metrics.js and lighthouse-report.js scripts.
+1541 -79

0 comment

2 changed files

nucliweb

pr closed time in a month

push eventaddyosmani/puppeteer-webperf

Joan León | @nucliweb

commit sha 4415e01f35ecba0991531859d0203694021a1555

Intalled Lighthouse dependency

view details

Addy Osmani

commit sha 39fbfcb5014c4eec28d695474b809aa6aa8f3020

Merge pull request #10 from nucliweb/feat/lighthouse-dependency Installed Lighthouse dependency

view details

push time in a month

issue commentGoogleChrome/web-vitals-extension

14 hour LCP

I'm +1 to us expanding our language around why a metric may have an inflated value, similar to how we speculate tab backgrounding may have been a cause. Is there a particular condition you think we should be using to signal showing this message?

On the lower end of the complexity spectrum, we could set an upper bound (e.g LCP > 1000s) after which this reasoning is given. On the other end, we could do some time book-keeping about the length of time a tab has been open. I'm personally leaning towards something simple... but am open to ideas :)

rviscomi

comment created time in a month

issue commentGoogleChrome/web.dev

Document CLS nuance around infinite scrolling UX patterns

Still planning to work on this, bot 😂

addyosmani

comment created time in a month

more