Performance and Resilience: Stress-Testing Third Parties by CSS Wizardry

私は数週間前にGoogle Developer Dayで中国にいましたが、皆さんに私のQRCode scannerを公開していました。オフラインになるまではうまくいっていました。ユーザーがオフライン(または部分的に接続されている)の場合、カメラは起動せず、QRコードをスナップできませんでした。私は何が起こっているのか分かりませんでした。私は誤って onloadイベントでカメラを起動していました.Googleアナリティクスのリクエストはハングアップし、適時に解決されませんでした。それはそれを修正したこのコミットでした。

Because these types of assets block rendering, the browser will not paint anything to the screen until they have been downloaded (and executed/parsed). If the service that provides the file is offline, then that’s a lot of time that the browser has to spend trying to access the file, and during that period the user is left potentially looking at a blank screen. After a certain period has elapsed, the browser will eventually timeout and display the page without the asset(s) in question. How long is that certain period of time?

It’s 1 minute and 20 seconds.

If you have any render-blocking, critical, third party assets hosted on an external domain, you run the risk of showing users a blank page for 1.3 minutes.

Below, you’ll see the DOMContentLoaded and Load events on a site that has a render-blocking script hosted elsewhere. The browser was completely held up for 78 seconds, showing nothing at all until it ended up timing out.



About Me: Paul Kinlan

I lead the Chrome Developer Relations team at Google.

We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.

Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.