Addy Osmani:

Native lazy-loading for images 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 and is also supported in Chrome and Chromium-based browsers.

<iframe src="https://changelog.com" loading="lazy" width="600" height="400"></iframe>

YaS!! Lazy load all the things 💚

Addy Osmani has created an excellent resource for all developers interested in optimizing their web performance (which should be pretty much all of us).

You’ve probably heard of Puppeteer, which lets you control Chromium headlessly over the DevTools protocol. This repo shows you how to use Puppeteer to automate performance measurement, such as getting a performance trace for a page load:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  // Drag and drop this JSON file to the DevTools Performance panel!
  await page.tracing.start({path: 'profile.json'});
  await page.goto('https://pptr.dev');
  await page.tracing.stop();
  await browser.close();
})();

Which produces the results in the image below.

An update from Addy Osmani about the impact of JavaScript on the web and performance in 2019, and things you can do to impact it. Interesting because the number one items to pay attention to have changed from the conventional wisdom of a couple years back. Osmani:

One large change to the cost of JavaScript over the last few years has been an improvement in how fast browsers can parse and compile script. In 2019, the dominant costs of processing scripts are now download and CPU execution time.

This project aims to be a drop-in solution for sites to prefetch links based on what is in the user’s viewport. It also aims to be small (< 1KB minified/gzipped).

Relies on IntersectionObserver. Since prefetching is a form of progressive enhancement, unsupported browsers are no big whoop.

Hold on to your seat! This is a deep dive on improving time-to-interactive for Netflix.com on the desktop. Addy Osmani writes on the Dev Channel for the Chromium dev team regarding performance tuning of Netflix.com. They were trying to determine if React was truly necessary for the logged-out homepage to function.

Even though React’s initial footprint was just 45kB, removing React, several libraries and the corresponding app code from the client-side reduced the total amount of JavaScript by over 200kB, causing an over-50% reduction in Netflix’s time-to-interactivity for the logged-out homepage.

There’s more to this story, so dig in. Or, share your comments on their approach to reducing time-to-interactivity and if you might have done things differently.