Given that ambitious goal, Chrome has just milliseconds to produce every frame. But painting graphics to the screen isn't all that Chrome does, and there can be several different tasks contending for a single processor core. Historically Chrome handled execution of tasks, such as animating an image, responding to a click, or doing some memory operations, the same way that a bank handles a queue of customers: the first one line in is the first one handled. While this is simple and straightforward, it's not always the best for optimal performance. An urgent task, such as painting the next frame to the screen, might be added to the end of a long queue of pending tasks. The 60 frames per second goal would be lost.
Starting in Chrome 41, we've created a task scheduler integrated into the Blink rendering engine. The scheduler is capable of evaluating pending tasks and reordering them so that the most urgent tasks, such as animating and responding to a user's action, are prioritized ahead of others. Lower priority tasks, such as clearing out unused memory, are delayed until the processor has available time. In practice, this results in up to a 40% higher responsiveness to user input when Chrome is working hard to draw frames.
However, even the most advanced scheduler can't properly queue up tasks without knowing what's coming in the future. To address this, the Blink scheduler is also integrated with Chrome's graphics engine, which has precise knowledge of when Chrome will need to deprioritize other tasks in order to paint graphics to the screen. This allows the scheduler to consider lower priority tasks and schedule only those tasks that fit nicely into the otherwise "idle" time before Chrome needs to draw another frame. These tasks are handled essentially for free, with no impact on the smooth, 60 frames-per-second animations.
The latest version of Chrome scrolling a particularly challenging website, with the scheduler enabled (left) and disabled (right).
These changes demonstrate that performance isn't just about doing things faster - it's also about doing things smarter, in the right order, and at the right time. Stay tuned for more updates about how we're using Chrome's scheduler to push the bounds of performance.
Posted by Sami Kyostila and Ross McIlroy, Senior Task Masters
Unfortunately, once users discover an experience they love, it is hard for them to build a meaningful relationship since websites lack the engaging capabilities developers have come to expect from mobile such as push notifications and home screen icons. As a result, developers have needed to decide between the engagement potential of a native app and the reach potential of a mobile website.
Chrome 42 addresses this dilemma by allowing users to engage more deeply with the mobile web experiences that are important to them, by both opting in to receive push notifications directly from websites and easily adding regularly-visited high-quality sites to their home screen.
Push Notifications
Timely, personalized notifications save users the effort of manually checking for updates throughout the day and have enabled a host of new experiences from real time communication to live updates on breaking news.
This release of Chrome supports the new emerging web standard for push notifications on Android and desktop, enabling users to opt in to allow a specific website to send them push notifications just like an installed native app. Over the coming weeks, mobile web users will be able to opt in to receiving push notifications from early adopters including Beyond the Rack, eBay, Facebook, FanSided, Pinterest, Product Hunt, and VICE News. Roost and Mobify also provide services that make it easy for developers to integrate web-based push notifications into their site with minimal custom implementation work.
Promoting Add to Home Screen
Mobile users often open their phones to pass time while on the bus or waiting in line. Home screen icons help them easily jump back into their favorite experiences with just a single tap.In this release of Chrome for Android, users who frequently visit a modern, mobile-optimized website such as Flipboard or Medium will be offered the option to easily add the site directly to their home screen in one tap, allowing them to keep in touch and engaged throughout the day.
Developers can now take advantage of these and other recent changes including improved performance, full offline support, and access to device capabilities such as the camera and geolocation to deliver more meaningful experiences on the web than ever before. These new features will continue to improve and evolve over time, diminishing the difficult choice for developers between the reach of the mobile web and the engagement of native apps.
Posted by Miguel Garcia, Push Maestro and Owen Campbell-Moore, Engagement Optimizer
For latency-sensitive services like web search, the largest gains come from zero-round-trip connection establishment. The standard way to do secure web browsing involves communicating over TCP + TLS, which requires 2 to 3 round trips with a server to establish a secure connection before the browser can request the actual web page. QUIC is designed so that if a client has talked to a given server before, it can can start sending data without any round trips, which makes web pages load faster. The data shows that 75% percent of connections can take advantage of QUIC’s zero-round-trip feature. Even on a well-optimized site like Google Search, where connections are often pre-established, we still see a 3% improvement in mean page load time with QUIC.
Another substantial gain for QUIC is improved congestion control and loss recovery. Packet sequence numbers are never reused when retransmitting a packet. This avoids ambiguity about which packets have been received and avoids dreaded retransmission timeouts. As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections. These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
Where do we go from here? Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers. We plan to formally propose QUIC to the IETF as an Internet standard but we have some housekeeping to do first, like changing the wire format and updating our reference implementation from SPDY-over-QUIC to HTTP2-over-QUIC. In the coming months, we also plan to work on lowering handshake overhead to allow better server-side scalability, improving forward error correction and congestion control, and adding support for multipath connections.
If you want to follow along or play around, feel free to check out the code and experiment with it, or join [email protected] as we continue to improve the Internet, one packet at a time.
Posted by SYN, SYN-ACK and ACK (also known as Alyssa Wilk, Ryan Hamilton and Ian Swett)
MIDI is a well-established communication protocol used by music devices such as synthesizers, DJ decks, and drum machines. In Chrome 43, users are able to use MIDI hardware to create music without installing any specialized software, as the Web MIDI API allows websites to communicate with connected MIDI devices such as a USB-MIDI drum machine plugged into an Android tablet.
Permissions API
Until now, websites have been unable to determine the permission state of APIs such as Geolocation. Due to this, sites often attempt to use APIs immediately after page load without pre-existing permission, causing users to see confusing permission prompts with no context or explanation.
The new Permissions API allows developers to query and observe changes to their permission status for Geolocation, Push, Notifications and Web MIDI so they can ask for permission in context, improving the user experience.
Moving DOM attributes to the prototype chain
In Chrome 43, attributes defined on DOM objects have been moved to the prototype chain, as specified by Web IDL. This change allows developers to efficiently override or create methods on DOM Objects and improves compatibility with Firefox and Internet Explorer. As this subtle change may cause breakages in existing content, developers should use Chrome 43 to test their website to ensure their users don’t experience issues when this release rolls out to all users.
Upgrading legacy sites to HTTPS
Transitioning large collections of unmodifiable legacy web content to encrypted, authenticated HTTPS connections can be challenging as the content frequently includes links to insecure resources, triggering mixed content warnings. This release includes a new CSP directive, upgrade-insecure-resources, that causes Chrome to upgrade insecure resource requests to HTTPS before fetching them. This change allows developers to serve their hard-to-update legacy content via HTTPS more easily, improving security for their users.
The autocapitalize property is now supported on input and textarea elements, allowing sites to suggest default capitalization for text typed with on-screen keyboards.
Developers can now programmatically trigger copy and cut actions using document.execCommand('copy') and document.execCommand('cut') in response to a user gesture, eliminating the need to use Flash-based workarounds.
The Fetch API now allows developers to directly operate on and incrementally release the bytes of streamed network responses, in contrast to the equivalent XMLHttpRequest functionality that requires developers keep the entire in-progress stream response in memory.
showModalDialog was disabled by default in Chrome 37 and in accordance with the public deprecation timeline, this release removes the Enterprise Policy setting created to temporarily re-enable it.
Chrome OS now fires devicemotion events on pages at a regular interval, allowing developers to track the device’s acceleration in the same way they do on Chrome for Android, Windows, Mac, and Linux.
The Web Audio API now allows developers to selectively disconnect specific connections to an AudioNode or AudioParam, avoiding the audio artifacts caused by disconnecting all inputs and then manually re-connecting those that should have been retained.
Developers using the Web Audio API can now also explicitly close an AudioContext, releasing all allocated system audio resources instead of depending on unpredictable garbage collection.
The nonstandard WebSocket.URL and EventSource.URL were removed in favor of their standard counterparts WebSocket.url and EventSource.url.
CSS animations can now be used without the -webkit prefix.
