Biz & IT —

Chrome rendering engine will get faster, lighter, and better offline in 2014

Goals for the Blink engine align closely with those of Android and Chrome OS.

A Google software engineer has outlined the Blink team's plans for 2014.
A Google software engineer has outlined the Blink team's plans for 2014.

In April of 2013, Google announced that its Chrome browser would move away from the then-current WebKit rendering engine to a new, Google-backed (but still open-source) engine called Blink. Reasons given for the switch included a desire to improve performance and reduce complexity, and a recent Google Groups post by Google software engineer Eric Seidel shows just what the Blink team will be working toward in 2014.

Unsurprisingly, many of the team's goals focus on mobile device performance, "in part because Web engines (e.g. Blink) are not nearly as good on performance-constrained devices as they need to be." Google considers smooth scrolling and animation, input responsiveness, and load time to be key factors on mobile devices, and the company wants to improve on these while reducing memory usage and power consumption.

Other goals are focused on "improv[ing] the mobile Web platform itself," blurring the line between locally installed applications and apps run in the browser window. Google wants to enable "better-than-AppCache" offline modes for apps, Web apps that support push notifications, and apps that support hardware-specific features like screen orientation.

Google also moved away from WebKit so that it could deprecate code it wasn't using, and that kind of cleanup will continue in 2014. Google wants to remove unspecified "large platform features," but with "minimal breakage." For the rest of the codebase, the team wants to "modularize and homogenize" it, making it easier to make changes to specific features without breaking other things. Finally, developers are getting some love: they'll be getting tools that help them analyze "mobile design [and] performance" and some new mobile app guidelines from Google. The team wants to reduce the amount of time it takes for developers to begin using a feature once that feature ships.

Most of these goals are unsurprising—there's a lot here that falls under the "slow and steady improvement" umbrella, and Chrome has been about slow and steady improvement since the first beta was released in September of 2008. More notable is how the team's plans for Blink align with Google's goals for its other platforms. Reduced memory footprint and improved performance were features of Android 4.4, which Google engineered to run on devices with 512MB of RAM. Doing the same to the Blink engine furthers Google's goal to get older versions of Android off low-end phones and cheap handsets sold in emerging markets, many of which continue to run Android 2.3.

Just as the performance improvements line up with Google's Android strategy, any changes to Blink that makes Web apps richer will pay off for Chrome OS. Google is working to improve Chrome OS' utility by way of its installable Packaged Apps, but Web apps aren't so Google-specific and are much more widespread as of this writing. Investing in more robust Web apps and better offline capabilities are essential features if Google wants to make Chrome OS fit better in slots currently occupied by other devices.

The mobile-heavy focus of this Blink roadmap may be a side-effect of Sundar Pichai's management—he took over for then-Android boss Andy Rubin back in March of 2013, and since then both the Android and Chrome teams have operated under his aegis. Google has never been as compartmentalized as a company like Microsoft, but having both projects managed by the same person makes it easier to align strategies. This document about adding new Blink features, linked as a footnote in Seidel's roadmap, mentions the balance between features and performance as being particularly important for mobile devices, something that could fall through the cracks if the Chrome team was primarily focused on Chrome OS or the desktop browser.

"Considering that feature deprecation remains elusive, the cost of new features and APIs is untenably high," it reads. "The situation is even more grim for mobile devices, where every byte and milliamp/hour counts. Given that the mobile Web is already working off the negative balance, we simply can't afford adding new girth and jank there."

The full list of goals, as well as a growing discussion thread about them, can be found here.

Channel Ars Technica