Highlights from Chrome Dev Summit 2018
Earlier this week, I was able to attend Chrome Dev Summit in San Francisco. This was my second time attending the event, the first being in 2016 (you can read about my highlights from that event too). This year's event was one of the best tech conferences I’ve been to in a while, jam-packed with well-thought out sessions and amazing people.
I learned a lot from the sessions and will likely write about some of the topics in more detail, but I wanted to share a few of the projects and topics I found the most interesting.
Navigation transitions (again, but this time with Portals) #
In 2016, Jake Archibald previewed a highly speculative API that could enable page transitions in the way native mobile applications do, with a new navigate event on the window. Although the specification as Jake presented it two years ago never came to fruition, the idea was continued and re-imaged.
Portals are the new proposal for seamless page transitions on the web. A <portal> element is similar to an <iframe>, but is always top-level and can be navigated into and out of. The proposal is still in its early stages and will likely change, but here’s how it could work.
First, we create a new portal element on the page. This can be created via the <portal> HTML element itself or via JavaScript.
<portal id="myPortal" src="https://bitsofco.de"></portal>Next, we can respond to a users click (or any) event by animating the portal window in any way we like. It wasn’t clear from the presentation or the documentation exactly how the animations would work, so hopefully that is something that will be cleared up soon.
navigateButton.addEventListener(('click') => {
// insert fancy animations here
});Finally, we activate the new portal, replacing the current top-level browsing context with the portal.
navigateButton.addEventListener(('click') => {
// ...
myPortal.activate();
});Like Jake's original proposal, Portals may not be the answer to our problem of navigating on the web, but I’m happy that there are some proposals being put forth to get us that much closer to the actual solution.
Squoosh - A 15kb JS-powered web application #
My favourite session of the conference was Jake and Mariko’s talk on how they built Squoosh, a web application for image compression. I would highly recommend you watch it yourself, as they go into great detail on all the steps they took and best practices they followed to ensure that the app was only 15kb on first load!
To do this, they leveraged on a number of tools, technologies, and best practices, including:
- Preact as a lightweight, 3kb framework
- Webpack for code splitting
- Web Workers for parallel tasks
- Dynamically importing Javascript modules
Unified performance analysis with PageSpeed and Lighthouse APIs #
Historically, measuring the performance of a website was split among various tools that could (and probably would) give differing results. Going forward, all of Google’s tooling for measuring performance across all the various products will now be backed by the new PageSpeed API (version 5), which is essentially a Lighthouse API.
Although the various products could still be useful at different stages -PageSpeed Insights for Benchmarking, the Lighthouse CLI for development, the Search Console for SEO monitoring - they are now all powered by the same testing tool and will deliver the same reliable results.
Native lazyloading in Chrome #
Chrome will soon support a lazyload attribute on resources such as images! This attribute will tell the browser to only load the resource when it is needed, for example when it is scrolled into view.
<img lazyload src="path/to/image.png">This is already available in Internet Explorer and Edge, but it’s great to see it come to more browsers. Right now, this feature can be enabled in Chrome behind a flag (chrome://flags/#enable-lazy-image-loading)
There were many more talks with many more bits of useful information I didn’t mention here. As always, you can re-watch all the sessions on the Chrome Developers YouTube Channel.