Many components in the browser contribute to speed

V8 is Chrome’s JavaScript and WebAssembly engine. With web pages using an increasing amount of JavaScript, a fast engine to handle it is an important cornerstone. Over the years, we worked on a new JavaScript execution pipeline for V8, launching Ignition (a new interpreter) and TurboFan (an optimizing compiler). These allowed us to improve performance on the Speedometer benchmark by 5-10%. Script streaming enabled us to parse JavaScript on a background thread as soon as it began downloading, improving page loads by up to 10%. We then added background compilation reducing main-thread compile time by up to 20%.

Our work on project Orinoco enabled concurrent garbage collection, freeing up the main thread and reducing jank. Over time, we also shifted to focusing on real-world JavaScript performance, helping us double the performance of the React.js runtime and improve performance for libraries like Vue.js, Preact, and Angular up to 40%. Parallel, concurrent, and incremental garbage collection reduced garbage collection induced jank by 100× since the initial V8 commit. We also implemented WebAssembly, enabling developers to run non-JavaScript code on the web with predictable performance, and launched the Liftoff baseline compiler to ensure fast startup times of WASM apps. These new components are just the latest in a 10-year effort that has improved V8's performance release-to-release for an improvement of 20x over the years.

V8 Bench scores for a range of Chrome releases over the years. V8 Bench is the predecessor to the old Octane benchmark. We've used it for this chart because unlike Octane, it can run in all Chrome versions, including the initial Chrome Beta.

Chrome has also played a key role in helping evolve network protocols and transport layers through SPDY, HTTP/2 and QUIC. SPDY aimed to address limitations of HTTP/1.1 and became the foundation of HTTP/2 protocol, which is now supported by all modern browsers. In parallel, the team has been actively iterating on QUIC, which aims to further improve latency and user experience and now has an active IETF effort behind it. QUIC’s benefits are noticeable for video services like YouTube. Users reported 30% fewer rebuffers when watching videos over QUIC.



Next up is Chrome's rendering pipeline. This is responsible for ensuring webpages are responsive to users and display at 60 frames per second (fps). To display content at 60fps, Chrome has 16ms to render each frame. This includes JavaScript execution, style, layout, paint and pushing pixels to the user's screen. Of this 16ms, the less Chrome uses, the more web developers have to delight their users. Improvements to our rendering pipeline have included optimizing how we identify which elements in a page need to be redrawn and better tracking visually non-overlapping sets. This reduced the time to paint new frames to the screen by up to 35%.

In 2015, a user-centric performance model called RAIL was introduced by the Chrome team. We recently updated it.


 What about memory consumption? Between Chrome 63 and 66, a ~20-30% improvement in renderer process memory usage was observed. We hope to continue exploring ways to build on this now that site-isolation has landed. Ignition and TurboFan reduced V8's overall memory footprint, slimming it down by 5-10% on all devices and platforms supported by V8. Some sleuthing this year also discovered memory leaks impacting 7% of sites on the web, which we’ve now fully fixed. Many components contribute to Chrome’s speed including the DOM, CSS and storage systems like IndexedDB. To learn more about our improvements to performance, continue keeping an eye on the Chromium Blog.



Give web developers more power to measure and optimize their web pages


 Understanding where to start with improving your site can be a tedious process. To help, we explored several tools for understanding the lab signals and real-world experience felt by your users. Over the years, the Chrome DevTools Performance panel became a powerful way to visualize the play-by-play breakdown of how web pages were displayed in a lab setting. To continue lowering the friction for finding performance opportunities sites had, we then worked on Lighthouse - a tool for analyzing the quality of your website, giving you clear measurements of your site’s performance and specific guidance for improving your users’ experience. Lighthouse can be accessed directly from inside the DevTools Audits panel, run from the command-line, or integrated with other development products like WebPageTest.
Lighthouse running in the Chrome DevTools Audits panel



To complement the lab data provided by Lighthouse, we released the Chrome User Experience Report to help developers get access to field metrics for the experience their users feel in the real-world, such as First Contentful Paint and First Input Delay. Now, developers can build out their own custom site performance reports and track progress over millions of origins using the CrUX Dashboard.

We also introduced a number of Web Platform capabilities to help developers optimize the loading of their sites. We shipped Resource Hints and <link rel=preload> to allow developers to inform the browser what resources are critical to load early on. Chrome was one of the first browsers to implement support for byte-saving approaches like Brotli for compression, WOFF2 for smaller web fonts and WebP support for images.
We’ve been excited to see an increasing number of browsers support these features over time. Chrome implemented Service Workers, enabling offline caching & network resilience for repeat visits to pages. We’re delighted to see broad modern browser support for the feature.

In fact, Google Search now uses Service Worker and navigation preload for opportunistic caching on repeat searches. This led to a 2x improvement in page load times for repeat visits.
As we look to the future, we are also excited about the potential that emerging standards like native lazy-loading for images & iframes, and image formats like AV1 have to help deliver content to users efficiently.

Enjoy more of the web on your data-plan with Chrome


Over the last 10 years, the size of web pages has been ever-increasing, but for many users coming online for the first time, data can be prohibitively expensive or painfully slow. To help, Chrome released data-conscious features over the years like Chrome’s Data Saver. Data Saver intelligently optimizes pages, saving up to 92% on data consumption.

Going ahead, we are exploring new ways to help you save data. For users on the slowest connections, we've been working on Chrome for Android, allowing for smarter page optimizations to show essential content earlier. These page transformations load far faster than the full page, and we're continuing to improve our fidelity, coverage, and performance.

We've also been experimenting with putting guardrails in place for users who are data- or network- constrained. For example, we're exploring bringing native lazy-loading to Chrome, as well as providing users the option to stop additional requests from a page when it uses a lot of data.


We’re just getting started...


 Together, these changes help developers and businesses deliver useful content to their users sooner. We know there’s still work to be done. Here’s to offering improvements to page load performance over another 10 years!


Posted by Addy Osmani, JavaScript Janitor
Labels: , , , , ,

NOTE: This article was inspired by a conversation with Darin Fisher, VP for Google Chrome, for our YouTube series “Designer vs. Developer”.

To release a browser when there were already established ones in the market was a bold move—especially when some of the major browsers were clocking over a million downloads within just hours of their release.
The community speculated about a Google browser as early as 2004, but the team actually started working on the project in 2006. With the rise in rich web applications such as Gmail, YouTube, and Google Maps, the demand for more powerful browsers became apparent. These new web apps were processor-intensive and the browsers weren’t designed to handle that level of complexity.


“In your typical browser of that day, if you were to leave Gmail running overnight, you would come back the next day and your browser would feel pretty sluggish.”
– Darin Fisher, VP Chrome

Browsers of that time mimicked what early search engines had done, diluting the focus on the core user experience. Search engines were mostly portal sites with a sea of links and a tiny input field. Google Search stripped away the clutter, offering the user a single input field, and focused on a single task.



Web browsers had created a similar problem with excessive toolbars. Whenever users installed a new app, they were offered an extra toolbar. Eventually, the browser UI dominated the user's screen real estate and left very little space for content. Chrome wanted to do what Google did with search: focus on content. The team wanted to get out of the user’s way and include features that weren’t possible before, such as draggable tabs. Even the extension system was built to ensure that the screen space for content wasn’t compromised and that the surrounding UI was minimized as much as possible.



The mantra for Chrome was the four S’s: simplicity, speed, security, and stability.

Simplicity represented the streamlined UI design and experience. Speed was about how quickly the browser responded when a user performed an action. Speed wasn’t just about load time, either. Before Chrome, browsers would often hang or fail to respond when a user tried to close a tab, had too many tabs open, or was doing something complicated on a page. Chrome worked on a multiprocessor architecture, so if the user clicked to close a tab, it would simply close.



Security was about making users feel safe on the web, protecting them from any nasties on the internet such as viruses or fake sites, and giving them control over what was happening. This tied into the final S -- Stability of the browser, ensuring that it wouldn’t randomly crash. The team put a lot of effort in making sure it supported the many quirks on the web and rendered pages in a way that web developers intended.



I asked Darin about the things he is proud of and the decisions he regretted. He mentioned the liberation of starting with the Windows version, which meant his teams could focus on building a great browser without thinking about any cross-platform issues. While it maintained the free-spirit of development for the team, to their peril, they had to recreate everything from scratch when building for mobile, MacOS and Linux - a painful but critical learning of ‘thinking long-term’ for him and the team.

The other challenge I asked him about was the dreaded “best viewed in browser X” banner message that was common in the early 2000s, indicating that site content might not show properly on some browsers (including Chrome). Today, Chrome is working with other browsers vendors, the W3C committee, and especially developers, to make sure we’re solving the right problems for the community, such as the cross-collaboration work we did when implementing CSS Grid.



What do the next ten years hold? As new computers, mobile devices, and users come online, the most likely effect will be that design patterns and trends from Asia and Africa become the standard way of experiencing digital design. Web makers in India have pioneered offline experiences, and app designers in Nigeria are developing new ways of delivering Ecommerce experiences to users on 2G networks.



So, here’s to the next ten years. Happy birthday, Chrome!



Labels: , , , ,



In the beginning, there was Firebug

Imagine for a moment that browsers didn't ship with developer tools. How would you debug JavaScript? You'd basically have 3 options:
  • Sprinkle window.alert() calls throughout your code.
  • Comment out sections of code.
  • Stare at the code for a long time until the JavaScript gods bless you with a solution.
What about layout issues? Network errors? Again, all you could really do is conduct painstaking experiments in your code. This was the reality of web development up until 2006. Then a little tool called Firebug came along and changed everything.


A screenshot of Firebug's Net panel, taken from Saying Goodbye to Firebug (source and license)

Firebug was a Firefox extension that let you debug, edit, and monitor pages in real-time. As a web developer suddenly you went from having no visibility into your pages to having what are essentially the core features of modern developer tools. The ability to understand exactly why Firefox was behaving as it was unleashed a flood of creativity on the web. Without Firebug, the Web 2.0 era wouldn't have been possible.




WebKit Web Inspector


Around the same time as Firebug’s launch, a few Google engineers started working on a project which would eventually lead to Chrome. From the start, Chrome was a mashup of different code libraries. For rendering the Chrome engineers opted for WebKit, which is the open-source project that still powers Safari to this day. An added bonus of using WebKit was that it came with a handy tool called the Web Inspector.


A screenshot of the Web Inspector, taken from Web Inspector Redesign (source and license)

Like the Net panel of Firebug, the original Web Inspector probably looks familiar. Much of its functionality lives on to this day as the Elements panel in Chrome DevTools. Web Inspector launched a few days after Firebug, and Safari was the first browser to bundle developer tooling directly into the browser.




The "Inspect Element" era


 Chrome brought many innovative ideas to the browser ecosystem, such as the omnibox that combined search and the address bar, and a multi-process architecture that prevented one hanging tab from crashing the entire browser. But the innovation we like the most was providing developer tools in every build to every user, exposed with the click of a mouse.

"Inspect Element" in 2010



Before Chrome, developer tooling was an opt-in experience. You either had to install an extension, like Firebug, or enable some flags, as is still the case in Safari today. Chrome was the first browser to make developer tooling accessible from every browser instance. We'd like to claim that we had a grand vision for creating a developer-friendly browser from the start, but the reality is that Chrome had a lot of compatibility issues in its early days (which makes sense, since no one was building for it) and we needed to give web developers an easy way to fix these issues. Web developers told us that it was a useful feature, and we kept it.


The mobile era


For the first few years of the DevTools project, we essentially added chapters to the stories that Firebug and Web Inspector started. The next big shift in how we approached DevTools happened when it became clear that smartphones were here to stay.
Our first mission in this brave new world was to enable developers to debug real mobile devices from their development machines, which we call remote debugging. DevTools was actually well-positioned to handle remote debugging, thanks to another consequence of Chrome’s multi-process architecture. Early on in the DevTools project we realized that the only way a debugger could reliably access a multi-process browser was through a client-server protocol, with the browser being the server, and the debugger being the client. When mobile Chrome came around, the protocol was already baked into it, so we just had to make the DevTools running on your development machine communicate with the Chrome running on your mobile device over the protocol. This protocol still forms the backbone of DevTools today, and is now known as the Chrome DevTools Protocol.

Remote Debugging

Remote debugging was a step in the right direction, and to this day is still the primary tool for making sure that your sites behave reasonably on real mobile devices. Over time, however, we realized that remote debugging could be a bit tedious. When you're in the early phases of building out a site or feature, you usually just need a first-order approximation of the mobile experience. This prompted us to create a set of mobile simulation features, such as:

  • Precisely emulating the mobile viewport, simulating touch-based input and device orientation.
  • Throttling the network connection to simulate 3G and CPU to simulate less-powerful mobile hardware.
  • Spoofing user agent, geolocation, accelerometer data and more.

We collectively refer to these features as Device Mode.






An early prototype of Device Mode


Device Mode in 2018


The performance era


While the mobile era unfolded, big apps like Gmail were pushing the limits of the web's capabilities. Gmail-scale bugs called for Gmail-scale tools. One of our first major contributions to the tooling ecosystem was to show a play-by-play breakdown of exactly everything that Chrome had to do in order to display a page.


The original Timeline panel, as announced in Do More with Chrome Developer Tools


The Performance panel in 2018


These tools were a step in the right direction, but in order to spot optimization opportunities you needed to learn the nitty-gritty details about how browsers work and sift through a lot of data. Lately we've been building on this foundation to provide more guided performance insights. The new Lighthouse engine powers the Audits panel, and is also available as a Node module for integration with CI systems.


Performance suggestions in the Audits panel


The Node.js era


Up until 2014 or so, we mainly thought of DevTools as a tool for building great experiences on Chrome. The rise of Node prompted us to rethink our role in the web ecosystem.
For the first few years of Node's existence, Node developers were in a situation similar to that of web developers before Firebug, or Gmail developers before the Timeline panel: the scale of Node apps outpaced the scale of Node tools. Given that Node runs on Chrome's JavaScript engine, V8, DevTools was a natural candidate to fill the gap. Support for debugging Node with DevTools landed in 2016 and includes the usual DevTools features, such as breakpoints, code stepping, blackboxing, source maps for transpiled code, and so on.
Node Connection Manager



The DevTools protocol ecosystem


The name Chrome DevTools Protocol (CDP) suggests an API that only DevTools can use. The reality is more general than that: it’s the API that enables programmatic access to Chrome. Over the last few years, we've seen a few third-party libraries and applications join the protocol ecosystem:
  • chrome-remote-interface provides low level JavaScript access to the protocol
  • Puppeteer brings it to the next level of abstraction and enables automation of the evergreen headless Chrome browser with modern JavaScript API
  • Lighthouse automates the process of finding ways to improve the performance and quality of pages

We're excited to see thousands of projects depend on these packages to enable rich interaction with Chrome. If you’re in the tooling or automation business, it’s worth checking out the protocol to see if it opens up any opportunities in your domain. For example, the VS Code and WebStorm teams both use it to enable JavaScript debugging within their respective IDEs.

What's next?


Our core mission is to build tools that help you create great experiences on the web. We very much rely on your feedback to help us determine what products or features to build.


Thank you for creating such a vibrant community. We look forward to another 10 years of building the web with you.

Posted by the Chrome DevTools team
Labels: , , ,



As the very first pages were served on the open web in 1990, people recognized that the ability to deliver dynamic content would make the web unique—you could provide information and function just by sharing a URL. The Common Gateway Interface standard released in 1993 defined a simple interface for web servers to run code in response to web requests. It brought a new era of experience and capability to computing, accessible at the click of a link. Hop forward two short years to JavaScript, then another year to frames, specifically the <iframe> tag. These innovations let developers dynamically load content into pages, brought a new level of interactivity to the web, and increased user expectations of what could be done in the browser.


Accessibility, linkability, indexability, and universal reach have always been the web’s core strengths. Alongside these super powers, users want ever richer and more-engaging experiences. “Ajax” was coined in 2005 to describe the combination of asynchronous JavaScript and XML, which shaped a more interactive, modern web. It led to the creation of such services as Google Maps, cementing the web as the best way to deliver experiences available to anyone, on any device.



2008 – 2014: Web applications, HTML5, and the start of the mobile era

Chrome saw huge progress in its early years, with a large number of what are now considered “core APIs” coming to the web after the WebKit implementation. The video, audio, and canvas elements were some of the first “modern web” features that many of us distinctly remember (and who can forget border-radius?). These features brought a new level of interaction to web experiences, and meant developers no longer needed plugins such as Adobe Flash or Java, to build interactive media and graphical experiences. Chrome experiments have captured great examples of rich experiences that are a direct result of the web’s improved performance.

The “Mobile Web” really hit the world in 2010, and we saw a slew of new platform primitives introduced for the platform (many inspired directly by Google Gears) to help make building web apps easier. We could now make responsive, offline-enabled applications with AppCache and WebSQL, request permission to access the user's geolocation, and even understand the orientation of the user’s device.
WebSocket landed on the platform the same year, heralding a change in the types of experiences developers could deliver on the web. No longer did they have to use long polling to enable a bi-directional channel between the user and a service; developers now had a two-way channel with a simple API to provide real-time communication.




Plink is an interactive music experiment synchronising player state via websockets.


Four major APIs came to Chrome in 2011. WebGL, Web Audio, and the Fullscreen API let us build rich and immersive experiences that could take advantage of the entire screen. IndexedDB — a new “web-first” storage mechanism — us store and query serializable JavaScript objects such as Strings, Objects, Arrays, Files, and Blobs more effectively.

Chrome Web Lab was an experiment that bridged the physical and digital worlds. It used Web Socket, video, real-time streaming, WebGL, and Web Audio to create an immersive world.


A bumper year for game-changing experiences on the web arrived in 2012. On the back of WebGL and Fullscreen, the Pointer Lock and Gamepad APIs let us build games and other web experiences that felt really interactive. The game-changing collection of WebRTC APIs truly set the web apart from all of the other platforms: It let us build P2P video-chat and real-time data sharing, without any plug-ins or proprietary stack, and accessible by simply clicking a link.

One of the first Chrome on Android to Chrome on Android WebRTC calls (March 2013)

In just seven years, the web changed drastically. Browsers got significantly faster and more capable, letting developers build richer experiences on the desktop. Users started to consume even more content on mobile, meaning we all had to rethink how our experiences would work across devices and form-factors, even when the user had no connectivity.

2015-2018: PWA, The Extensible Web, and deeper integration era

In 2015, we experienced a fundamental change in how we thought about integrating capabilities into the web platform. The Extensible Web manifesto asked browser engineers to consider a layered platform that offered lower-level primitives that were easier to explain, more efficient to implement, and allowed web developers to easily build higher-level abstractions, thus increasing the cadence and availability of compelling new features. Service Worker is an example of building on these APIs to follow these principles. Service Worker is a small piece of JavaScript that sits between the browser and the network, and lets the developer decide what to do with any web requests.

The combination of Service Worker and a handful of new APIs allowed marked the beginning of the Progressive Web Apps (PWA) era. PWAs are high-quality sites that combine the reach of the web with the user expectations that come with native platforms. Specifically, PWAs are...
  • Fast—they load instantly
  • Reliable—they never show the “downasaur,” even in uncertain network conditions, by taking advantage of the Service Worker and Cache APIs
  • Engaging—they respond quickly to user interactions with silky-smooth animations and no janky scrolling
  • Capable—the sites feel like natural extensions on the device, with immersive user experiences provided by features such as “fullscreen” and standalone mode through Web App Manifest; they deliver capabilities for meeting specific business goals, such as re-engagement through the Add to Homescreen feature and Web Push notifications

As PWAs became more established, so did the capabilities of the platform. The Background Sync API brought increased opportunities for developers to improve the resilience of their applications. We also got a better understanding of the network capabilities with extensions to the Network Information API.

Pointer Events, a critical component for any web site or app, came to Chrome after a long wait. Pointer Events presented a unified model for handling all forms of gesture-based input, ranging from touch to pens to mouse pointers.

In 2017, deeper integration of web apps with the host operating system and secure access to devices around the user arrived..

The Image Capture and Media Capture APIs provided full-frame access and control over a phone camera, as well as from other input sources such as a canvas. The Web Share API let sites share data directly with the operating system’s native sharing systems.

The Web Bluetooth API let a user securely select a Bluetooth LE device and have a webpage interact with the device. The Web USB API enabled the same level of connectivity, but to devices connected to the user's machine.

WebAssembly (WASM) opens up many possibilities. It brings a runtime that can execute code at near-native performance. Plus, it opens a new world of experiences on the web by letting developers use existing codebases built for other platforms on the web platform.




Web VR came to the web at roughly the same time it came to native platforms. It let us deliver immersive experiences without installing an app, significantly reducing the gap between a new native primitive arriving on platforms and being available across the web platform.




Forward to the future

We’re excited about the possibilities of the web platform. The web can (and should) be feature-rich, but new capabilities don't always have to be more complex. Web development should be predictable, manageable, and pain-free. Coming APIs such as Feature Policy are great examples of additions that will help developers create amazing sites in a more predictable way, and provide more control and customization over the UX of certain browser features. Feature Policy is the browser's built-in guide rails to help web developers avoid common pitfalls and use best practices.


Layered APIs is another initiative that we're excited about. With it, developers will be able to load and use high-level features shipped directly into the browser as JS modules. For example, instead of building a custom virtualize-scrolling component, developers can just import and use <virtual-scroller> in a site. Layered APIs can be quickly iterated on by the standards bodies and implemented by browser vendors, and will help create a pay-as-you-go standard library for the web. And looking further, the Houdini and Web XR APIs will radically change experiences we can build on and with the web.






Over the last 10 years, we’ve seen a massive increase in the rate at which new primitives and capabilities can be introduced to the web. We can thank all the browser vendors for their continued work to create and iterate on specs, using streamlined processes like those defined by the WICG and based on the principles in the Extensible Web Manifesto. We’ll continue our commitment to work with browser vendors and the developer ecosystem to prioritize features that users need, and to ensure that those capabilities arrive in a “webby” way. By doing so, we can uphold our original mission, while also prioritizing user safety, discoverability, instant access, and universal reach for everyone on the planet.


Here’s to the future of an even-more-capable open web.

 Posted by Paul Kinlan, the Wizzy Web Warrior.






Labels: , , , , ,