Speed in the Opera mobile browsers

Speed in the Opera mobile browsers

Luz Caballero@gerbille

Hi, my name is Luz Caballero. I work at Opera Software as a Web Opener.

Today I’m going to talk about speed in the Opera mobile browsers.

Wednesday, June 27, 12

• our browsers for mobile

• how they work to offer users maximum speed and data savings

• what’s new and what’s coming next.


Mini

Mobile

Opera for phones and

tabletsTurbo

“normal”

browsers

compression�� modes

Opera has two different “mobile” browsers and both work in phones *and* tablets: Opera Mini, and Opera Mobile.

In turn, Mobile (like Opera desktop) has two different compression modes: Turbo, and “normal” (no compression).


confusing?


luckily 250M+ users seem to understand this ;)


*

And the reason I think they do, is because although speed and performance matter to all of us, most of our users come from places where network infrastructure is not so awesome (network speed is not great and definitely there are no unlimited data plans, with data being super expensive) so these things matter even more to them.

And this is why, through time, we’ve devoted a huge effort to delivering the best experience in terms of speed and data savings to them. Let me explain a bit more...

* this map is very old already, from before we launched our Chinese browser, so now we’re a lot stronger in the Chinese market as well, making the map “red” in all markets except most of North America, Europe and Australia.


Opera Mini


This is Opera Mini. Opera Mini runs in feature phones and smartphones (incl. Android and iPhone).


proxy browser

Opera Mini is a proxy browser. There’s only a thin client on the device and all the rendering happens server-side in Opera’s servers.

When the client makes a request and gets a page in return, the whole communication between Mini client and server is based on a binary, performance and responsesize oriented protocol. The format that Mini client on a phone gets, is no more HTML with accompanying resources (JS, CSS, media) that requires uncompressing, processing, parsing, etc. but OBML (“Opera Binary Markup Language”, a joke by our engineers that finally stuck around ;). The client just draws pre-rendered content on the device screen and catches the user input events, which are then forwarded to the server.


data savings: up to 90%


speed: super fast

Cannot really say that Opera Mini is the fastest browser out there, because how can you actually measure that? But the way it compresses data in the communication between the client and the Opera servers, the high performance of the servers in rendering a page, and the fact that our data centers are well connected to the Internet through really big pipes make Opera Mini definitely *very* fast when browsing in the wild.


progressive loading

On top of that, Opera Mini has some tricks to make the experience seem even faster. We have a time window on the server that the request has to fit into. However, even if the time of fetching resources exceeds usual window, but the server is able to draw something for the client, we do so and that send back.

We mimic the behavior of a regular browser loading a page. As in the desktop browsers, Mini server browser gets browseable content ready in the window even though not all page resources are there, so as soon as server is able to draw the page partially, it sends the partial result to the client. The client will display this content, but will keep listening for updates from the server. This is marked on client by rotating spinner. As more resources are loaded on the server, the page view is updated as the server sends updates that the client applies to previously received views.

In this way user is able to browse the page even though some minor resources, for example images, have not loaded yet.


tradeoffs

Obviously there are a few tradeoffs, so let’s see what you need to know if you’re going to develop for Mini.


Presto

Opera Mini -its servers- uses the Presto rendering engine, the same rendering engine in all the Opera browsers. So, by looking at the Presto version in the Opera Mini UA string you can go to our Web Standards support specs and figure out what’s supported in a particular Mini version.

As we’ve tried to optimize the experience for people using feature phones, we’ve decided to drop support for some features (like scrolling on elements other than <body> for example. If you’re interested to know more about this, you can have a look at the Opera Mini web content authoring guidelines (http://dev.opera.com/articles/view/opera-mini-web-content-authoring-guidelines/).


http://dev.opera.com/articles/view/opera-mini-web-content-authoring-guidelines/




JavaScript

JavaScript running on the Mini server will only run for a couple of seconds before pausing, for resource constraint reasons. This applies to JavaScript run due to an event firing e.g. onload, as well as code run because of a user action.

There’s no fixed time limit to how long javascript runs, but you should try to make you scripts as short and as fast as possible. There are limits for XHR requests (12 seconds in Mini 5+) and setTimeout / setInterval (5 seconds in Mini 5+).

Although we try to be flexible here -if there are ongoing XHRs we extend the time window somewhat to allow them finish the job- after yet another threshold is crossed, we will eventually stop the JS because otherwise we might need to wait forever, as there are sites that observe constant JS updates and processing.

Code registered with setTimeout() and setInterval() may be run before the page is sent, but it is unlikely that it will be called more than once because of script pausing. XMLHttpRequest is supported just as it is on desktop browsers, but triggering such requests from timeouts and intervals will not cause dynamic page updates, since that code will not be run in the background.

Things affected by this include JavaScript animations that use setInterval to move or resize elements (with the effect that pages may be sent to the client mid-move or mid-resize).


fewer server roundtrips

Performance in Mini is very much about reducing the number of server roundtrips. Every change in the page requires a trip to the server.

When events are triggered client-side a round trip to server occurs as they are handled in server window. For example, hover is directly not supported in its original way by design, as in most use cases it would require many server-client roundtrips. If there is a hover event on an element, it will create a link in Mini and a click on the link in client will trigger the event on server. So menus, that in desktop browser are hover controlled, in Mini are rather click controlled.

Reducing the number of events to the minimum necessary for your page to be usable is a good approach :)

Also, if it requires a repaint or a reflow, the server will be involved. This one’s pretty obvious but if you want to figure out what’s going on with your CSS you may want to use our DFL style profiler (http://my.opera.com/dragonfly/blog/experimental-build-with-integrated-style-profiler-preview).


http://my.opera.com/dragonfly/blog/experimental-build-with-integrated-style-profiler-preview

http://my.opera.com/dragonfly/blog/experimental-build-with-integrated-style-profiler-preview

images

Opera Mini handles image size optimization by itself, so there’s no need to do that yourself (either by using services that look at the UA or by any other means). The Opera Mini client allows the user to choose between four “image modes”: no images, low, medium and high quality. “No images” is self-descriptive. In low and medium quality the server will rescale image to fit in the device viewport and apply additional compression (low quality means, of course, higher compression). High quality mode downloads originally sized images that are still somewhat trimmed in data size comparing to the original resources of webpage. The user has an option to fetch full version of a picture.

Also, a performance trick that will not work in Mini is the lazy loading of images. If you do this to speed up display of the “above the fold” part of page, it’ll work in a full-featured browser, but for Mini this is an issue. Many of the scripts that provide this functionality are built upon user input/events (for example, scrolling) and we are not propagating them to the server, so the images will not load at all keeping all the placeholder images in their place. This is not totally true, because we’ve done some tweaking to support the most popular among these scripts, but you’d need to test yours to be sure.


hwa: panning, scrolling and zooming*

Something that we’ve recently added to Mini is hardware accelerated panning, scrolling and zooming. The page is rendered on a texture that later is painted via GPU. This makes navigating around pages a lot faster and smoother.

*only in Android devices


customizing content

From what we’ve seen so far, Mini is super fast and performant but you may want to be sure you’re serving it the right content/format so it can properly work its magic. Progressive enhancement is the way to go, but also Mini offers several resources for you to optimize your content for it.

I’m not going to go too much into it, but I’ll mention a few interesting things.

(You can find out more about all of these things here: http://dev.opera.com/articles/view/opera-mini-web-content-authoring-guidelines/)




operamini

The operamini object allows you to control certain features of Mini and the device, like for example for how many minutes the page will be cached *in client*.


“Opera Mini”

Like usual, we discourage browser sniffing, but if you feel you absolutely must do it, please look for the whole “Opera Mini” phrase. Remember that there are other Opera browsers out there whose users may not appreciate your small screen-optimized content ;) Also, some people look for “Opera Mini” as a last resort so if they’re testing for other things like Android or iPhone first they fail to recognize the user’s on Opera Mini.


headers

We provide a lot of information in the Opera Mini request headers, allowing you (among other things) to detect the device’s native user agent, the device’s manufacturer and model, and the user’s language.

To detect the real source of a request (its IP), remember to look for the X-Forwarded-For header (soon to drop the X!).

You can learn more about the Opera Mini request headers here: http://dev.opera.com/articles/view/opera-mini-request-headers/


http://dev.opera.com/articles/view/opera-mini-request-headers/

http://dev.opera.com/articles/view/opera-mini-request-headers/

media queries

Opera Mini supports media queries.


testing in Mini

Finally, to test in Mini you can use the Opera Mini simulator, which is an online simulator of Opera Mini that works just like it would when installed on a handset: http://www.opera.com/developer/tools/mini/

Also, you can download Opera Mini here http://m.opera.com/ and run it using the MicroEmulator (http://microemu.org/). Here are the instructions on how to do it: http://my.opera.com/ariesptn/blog/2008/11/17/using-microemulator-to-run-opera-mini

Also, since the Opera Mini servers use the same rendering engine as Opera Desktop, a lot of what is going on can be inspected simply by opening a website in Opera Desktop and starting the Opera Dragonfly. Also, there are some tricks that allow you to see the source (check “View page source” here: http://dev.opera.com/articles/view/opera-mini-web-content-authoring-guidelines/).


http://www.opera.com/developer/tools/mini/




http://m.opera.com

http://m.opera.com

http://microemu.org

http://microemu.org

http://my.opera.com/ariesptn/blog/2008/11/17/using-microemulator-to-run-opera-mini

http://my.opera.com/ariesptn/blog/2008/11/17/using-microemulator-to-run-opera-mini





Opera Mobile

As opposed to Mini, Opera Mobile is a full browser. Lately, some of our features even land first in Mobile than in desktop, like, for example, WebGL. As a result of this, Mobile lends itself to complex performance optimization practices like GPGPU.


MobileTurbo

“normal”

compression�� modes

Like I mentioned earlier, Mobile has two different compression modes: Turbo and normal, which means no compression at all.

I’ll go ahead and explain what Turbo means -since the other mode is just regular Opera- and later talk a little bit about what’s new in it, what we’re working on, and how you can improve and test your websites in Opera Mobile.


Turbo

User have three different options when it comes to Turbo: always on, off when on wi-fi, and always off.

When Turbo is enabled in the browser all HTTP requests will be sent to through the Turbo servers, through compressed headers. Exceptions are made for HTTPS requests, to preserve end to end encryption, and for plugin content. The browser will also make a best effort to avoid using the Turbo servers for file transfers (downloads).


pipelining, out-of-order and reordering

Turbo implements pipelining, out-of-order response, and reordering to get the critical files first: html and scripts before images, etc... This makes a big difference on mobile networks with high latency.


custom HTTP compression

Headers are compressed. Turbo removes unchanged request/response header fields between the client and the Turbo proxy and restores them on arrival. Other unnecessary header fields are permanently removed.


images

Turbo does destructive recompression of images: images with transparency are filtered and saved as PNG, and non-transparent images are saved as WEBP. The size of the new image is compared with the original to decide if it’ll be switched -because size is not always improved by these methods. If the image is significantly larger than the user’s screen it is also resized (this only applied to images inlined in web pages).

Right-clicking on an image will open it in full quality in case, for example, that you want to download it or the contents are hard to read.


gzip

If the file isn’t already compressed, then we add gzip compression to most datatypes (some like Flash or movies are excluded).


on-demand Flash

Load on demand for Flash plugins, to display the actual web page as fast as possible and to avoid loading unneeded plugins.


some cool new stuff

Like I mentioned, I’d like to talk a little bit about some stuff that we’ve recently release and some stuff we’re working on.


hwa

What we currently do in Opera Mobile is to accelerate the panning, scrolling and zooming using hwa. Essentially we render the page (or part of the page) in software as usual, and when we have this buffer we upload it to a texture and then as you pan, zoom and scroll we present the texture -together with some effects- using hwa.

This differs from the hwa we’ve integrated into desktop, which focuses on actual content rendering. We believe that accelerating content is more of an improvement than accelerating compositing on the Web today. Accelerating content will enable authors to make more complex and high performance games and other graphics-intensive applications that generally do not have much static content on top or under it. This is not there for mobile, but you can try it out by enabling hwa in the desktop configs.


SPDY

We’ve been working on implementing SPDY, and sharing some of our experience implementing similar optimized protocols for Mini and Mobile. If you’re interested in learning more, you can have a look at Martin Nilsson’s review of SPDY here: http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0498


http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0498

http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0498

HTTPS

As I mentioned before, Turbo can make Opera super fast but is not used for HTTPS. And until now we had been slower than we wanted to for HTTPS. With Opera 12 we’ve implemented several SSL improvements that have helped Opera reach top performance.

We now do CRL and OCSP requests in parallel instead of serial like we used to. We also optimized connection setup and introduced extra idle connections.

Strict Transport Security (STS) reminds the browser that the given domain should only be contacted through HTTPS.

We also did various other network optimizations.


dragonfly

Dragonfly is Opera’s integrated debugger, and we’ve been making some improvements to it.


enhanced network logging

This is an all new network logger integrated into Dragonfly -Opera’s debugger- that provides extensive information to allow you to monitor and optimize the network performance of your website. You can read more at the Dragonfly blog: http://my.opera.com/dragonfly/blog/enhanced-network-logger


style profiler

We’ve been working on a new style profiler for Dragonfly. The profiler lets you record all events that happen on a web page, for example script compilation and reflow. When recording is stopped these events will be presented in a timeline where you can see how long each event took. Events in the timeline can be hovered to get more information and some can be clicked. For now only style recalculation events can be clicked and will show a table of selector matching events with detailed information. Future releases will add the possibility to profile JavaScript. We also have a feature in this release which improves timing accuracy in the Network by turning off unneeded debugging services. This will be especially noticeable when remote debugging.


better remote debugging

You can debug your Mobile content using the Mobile emulator (http://www.opera.com/developer/tools/mobile/) or using remote wireless in-network remote debugging with Dragonfly.

Among the various improvements we’ve been working on for Dragonfly, we’ve recently added UPnP Dragonfly instance detection to pair up mobile devices with desktop Dragonfly instances more easily, by choosing the Dragonfly instance from a menu (before you had to write the IP of the machine from which you were using Dragonfly).

You can learn more about it in this video:http://my.opera.com/dragonfly/blog/2012/04/13/early-look-at-upcoming-features-pretty-print-function-return-values-upnp


http://www.opera.com/developer/tools/mobile/

http://www.opera.com/developer/tools/mobile/

http://my.opera.com/dragonfly/blog/2012/04/13/early-look-at-upcoming-features-pretty-print-function-return-values-upnp

http://my.opera.com/dragonfly/blog/2012/04/13/early-look-at-upcoming-features-pretty-print-function-return-values-upnp

that’s all... for now ;)


Thanks!


@gerbille@ODevRel

find out more:

Opera devrel blog:

developer resources:

Dragonfly blog:

Opera standards support specs:

Opera Mini simulator:

Opera Mobile emulator:

my.opera.com/ODIN/blog

dev.opera.com

my.opera.com/dragonfly/blog

opera.com/docs/specs

opera.com/developer/tools/mini

opera.com/developer/tools/mobile

memy�� team


Speed in the Opera mobile browsers

Technology

Transcript of Speed in the Opera mobile browsers