With the Chromium 42 release, H.264 hardware video decoding support has been expanded to OS X. Now Chromium on Macs, Windows 7+ and essentially all Chromebooks support power efficient decoding of video by default. Chromium?s HTML5 video implementation will automatically make the best decision on when to use this feature based on driver and hardware support.
The same hardware support is available to browser plugins as well. Pepper Flash for instance provides full access to video acceleration via the ActionScript StageVideo object. Switching from the old style Video to the StageVideo object should in most cases be simple to do. We would like to refer to Adobe?s excellent Best Practices for High Performing and Efficient Flash Video.
For best platform support and video performance, we strongly recommend moving from plugins to HTML5 video. Using plugins such as Flash may also adversely affect search ranking on mobile: see Google?s Webmaster FAQ. The video element is implemented by over 90% of browsers on mobile and desktop; Adobe ended support for Flash in Android Jelly Bean. The Web Fundamentals video section shows how to make the most of plugin-free, cross-platform media. For adaptive streaming on the web we recommend Shaka Player, an easy-to-use media player that implements DASH using MSE, with optional native support for content protection via EME. Likewise ExoPlayer for Android native apps.
More information about plugin deprecation timelines, and how to move to native APIs, is available from the NPAPI deprecation developer guide.
The DevTools Timeline panel has always been the best first stop on the path to performance optimization. This centralized overview of your app?s activity helps you analyze where time is spent on loading, scripting, rendering, and painting. Recently, we?ve upgraded the Timeline with more instrumentation so that you can see a more in-depth view of your app?s performance.
We?ve added the following features:
Note that using the Paint capture options described in this article do incur some performance overhead, so flip them on only when you want ?em.
Using the JS Profiler capture option and Flame Chart view to investigate call stacks in the Timeline.
Tip: Use WASD to zoom and pan through the Flame Chart. Shift-drag to draw a selection box.
The art of layer compositing is another aspect of the browser that has been mostly hidden from developers. When used sparingly and with care, layers can help avoid costly re-paints and yield huge performance boosts. But it?s often not obvious to predict how the browser will composite your content. Using the Timeline?s new Paint capture option, you can visualize composited layers at each frame of a recording.
When you select a gray frame bar above the Main Thread, its Layers panel provides a visual model of the layers that compose your app.
Tip: Play back animations by clicking through frame bars on a Timeline recording.
You can zoom, rotate, and drag the layers model to explore its contents. Hovering over a layer reveals its current position on the page. Right-clicking on a layer lets you jump to the corresponding node in the Elements panel. These features show you what was promoted to a layer. If you select a layer, you can also see why it was promoted in the row labeled Compositing Reasons.
Inspecting a layer from Codrops' Scattered Polaroids Gallery to reveal the browser?s reasons for compositing.
Last but not least, we?ve added the paint profiler to help you identify jank caused by expensive paints. This feature enriches the Timeline with more details about the work Chrome does during paint events.
For starters, it?s now easier to identify the visual content corresponding to each paint event. When you select a green paint event in the Timeline, the Details pane shows you a preview of the actual pixels that were painted.
Previewing pixels that the browser painted using the Paint capture option.
If you really want to dive in, switch over to the Paint Profiler pane. This profiler shows you the exact draw commands that the browser executed for the selected paint. To help you connect these native commands with actual content in your app, you can right-click on a draw* call and jump straight to the corresponding node in the Elements panel.
Relating native browser draw* calls to DOM elements using the Paint Profiler.
The mini-timeline across the top of the pane lets you play back the painting process and get a sense of which operations are expensive for the browser to perform. Drawing operations are color-coded as follows: pink (shapes), blue (bitmap), green (text), purple (misc.). Bar height indicates call duration, so investigating tall bars can help you understand what about a particular paint was costly.
Profile and profit!
When it comes to performance optimization, knowledge of the browser can be incredibly powerful. By giving you a peek under the hood, these Timeline updates help clarify the relationship between your code and Chrome?s rendering processes. Try out these new options in the Timeline and see what Chrome DevTools can do to enhance your jank-hunting workflow!
If you?ve worked with the Geolocation API before, chances are you?ve wanted to check if you had permission to use Geolocation without causing a prompt. This simply wasn?t possible. You had to request the current position and this would indicate the permission state or cause a prompt to be shown to the user.
Not all APIs work this way. The Notifications API has its own way of allowing you to check the current permission state via Notification.permission.
As the web platform grows in API?s, there needs to be a single, standard way for developers to check the status of a permission rather than having to remember how each and every API works. The Permission API, available in Chrome version 43, is intended to be this single, standard way to check the permission status of an API.
Check the status of a permission using the permissions.query() method. This will return a status of granted (you have permission), denied (you are blocked from accessing the API) or prompt (user needs to be prompted). For example:
The query method takes a
object, where you define the permission?s name. The response is a Promise
resolving to a
object. From this object, you can check the status with
In the above example, we highlight how to query the permission state for
geolocation with the following permission descriptor:
The Notification permission descriptor is similar in that it only requires a
For the push permission, you can supply a
Midi allows a
Requesting permission from the user depends on the specific API. For example,
geolocation would show a permission prompt when you call
Whereas notifications would prompt the user when you call
The point here is that the Permission API allows a consistent way to monitor the status of permissions while being able to support the range of APIs currently on the web.
The big advantage of this is that it allows you to build better experiences for your users, only prompting when it?s obvious to the user why you need extra privileges and taking full advantage of these APIs when you know you have been granted permission.
Chrome is the first browser to implement this, Mozilla are planning on shipping this, and Microsoft have shown interest in the API.
IE10 and above added support for the ?cut? and ?copy? commands through the Document.execCommand() method. As of Chrome version 43, these commands are also supported in Chrome.
Any text selected in the browser when one of these commands is executed will be cut or copied to the user?s clipboard. This lets you offer the user a simple way to select a portion of text and copy it to the clipboard.
This becomes extremely useful when you combine it with the Selection API to programmatically select text to determine what is copied to the clipboard, which we?ll be looking at in more detail later on in this article.
For example?s sake, let?s add a button which copies an email address to the user?s clipboard.
We add the email address in our HTML with a button to initiate the copying when it?s clicked:
which we select the email address text from the
What we are doing here is using a method of the Selection
to programmatically set the ?selection? of text to the anchor, which is the text we
want to copy to the user?s clipboard. After calling document.execCommand() we
can remove the selection by calling
The ?cut? command can be used for text fields where you want to remove the text content and make it accessible via the clipboard.
Using a textarea and a button in our HTML:
We can do the following to cut the content:
queryCommandSupported and queryCommandEnabled
Ahead of calling document.execCommand(), you should ensure that this API is supported using the document.queryCommandSupported() method. In our example above we could set the button disabled state based on support like so:
The difference between document.queryCommandSupported() and document.queryCommandEnabled() is that cut and copy could be supported by a browser, but if no text is currently selected, they won?t be enabled. This is useful in scenarios where you aren?t setting the selection of text programmatically and want to ensure the command will do as expected, otherwise present a message to the user.
IE 10+, Chrome 43+, and Opera 29+ support these commands.
Firefox supports this but requires a preference change (See cut and copy commands here). Without this Firefox throws an error.
Safari does not support these commands.
The Chrome team recently announced that we are moving DOM properties to the prototype chain. This change, implemented in Chrome 43 - (Beta as of mid April 2015) - brings Chrome more in line with the Web IDL Spec and other browsers? implementations, such as IE and Firefox. Edit: clarified Older WebKit based browsers, are currently not compatible with the spec, however Safari now is.
Clarification: The use of the word Attribute and Property are used interchangeably in this post, the ECMA Script spec defines ?Properties? that have ?Attributes?. A JS property is a ?WebIDL Attribute?. An Attribute in this article is not an HTML Attribute such as
The new behavior is positive in many ways. It:
For example, a hypothetical W3C specification includes some new functionality called
Prior to this change ? for consistency with other DOM properties in Chrome ? you would have had to create the new property on every instance, which for every
These changes are important for consistency, performance and standardization of the web platform, yet they can cause some issues for developers. If you were relying on this behavior because of legacy compatibility between Chrome and WebKit we encourage you to check your site and see the summary of changes below.
Summary of changes