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.


browsers
compression

modes
Opera for Mini
phones and Turbo
tablets Mobile
“normal”

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 deﬁnitely 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 response
size 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 ﬁnally 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 deﬁnitely *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 ﬁt 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 ﬁgure 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/).


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).


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 ﬁt 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 ﬁnd 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 ﬁrst 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/


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 Dragonﬂy. 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/).


Opera Mobile

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


modes

Turbo
Mobile
“normal”

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-ﬁ, 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 ﬁle transfers (downloads).


pipelining, out-of-order and reordering

Turbo implements pipelining, out-of-order response, and reordering to get the critical ﬁles ﬁrst: 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 ﬁelds between the client and the Turbo proxy and restores them on arrival. Other
unnecessary header ﬁelds are permanently removed.


images

Turbo does destructive recompression of images: images with transparency are ﬁltered 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 signiﬁcantly 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 ﬁle 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 conﬁgs.


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


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.


dragonﬂy

Dragonﬂy 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


that’s all... for now ;)


Speed in the Opera mobile browsers

More Related Content

Similar to Speed in the Opera mobile browsers

Recently uploaded

Speed in the Opera mobile browsers