In this week’s roundup, Apple gets into web components, how Instagram is insta-loading scripts, and some food for thought for self-hosting critical resources.
Apple deploys web components built using Stencil
The new Apple Music web app (beta) uses a JavaScript framework (Ember.js) but also standard web components such as <apple-music-video-player></apple-music-video-player> that are built using Stencil, a web component compiler.
Stencil is a build-time tool that generates standard web components with minimal overhead, while providing core features such as templating, state management, and routing, as well as performance features such as code-splitting and lazy-loading.
Apple just deployed into production nearly 50 web components powering a major app they have a significant amount of revenue and strategic value riding on. You can’t say that “no one uses web components” or they are “solving problems that don‘t exist or have been solved better in user land” with a straight face anymore.
(via Max Lynch)
Instagram makes use of chunked transfer encoding and progressive HTML rendering
Instagram’s website uses HTTP chunked transfer encoding to stream the contents of the HTML document to the browser as each part of the page is generated on the server.
We can flush the HTML
to the browser almost immediately … This allows the browser to start downloading scripts and stylesheets while the server is busy generating the dynamic data in the rest of the page.
They also use this technique to flush JSON data to the page in <script> elements. The client script waits for this data (using Promise) instead of requesting it via XHR.
(via Glenn Conner)
Consider self-hosting your critical resources
One section of University of Notre Dame’s website used to load jQuery from Google’s CDN, which could result in very long loading times (100+ seconds) when visiting the site from China. They’ve resolved the issue by self-hosting jQuery instead.
(via Erik Runyon)
Read even more news in my weekly Sunday issue. Visit webplatform.news for more information.
Isn’t it more likely that Google is blocked from China? That long lead time could be a failure to load. 90 seconds looks like a standard timeout.
Actually, I Googled a little… https://edjiang.com/how-googles-cdn-prevents-your-site-from-loading-in-china-67504845cd04
Maybe browsers could detect that the request doesn’t go through because of censorship and take measures to prevent it from blocking rendering for that long. Or they could have different timeouts depending on whether the resource is render-blocking.
Having the entire page not render for 90+ seconds because a single script is blocked by the ISP is something that browsers should probably guard against… somehow.
Not all resources from Google are blocked in China. But I would assume they monitored. If it was blocked then it would never load and throw a 404 error etc.