Introduction
In this article I’m going to cover the best ways that you can make your website or blog work well with Opera Mini. I'll also outline some items and quirks you might want to keep in mind while developing your website. The topics covered here will be applicable to mini browsers such as Opera Mini and UC Browser Mini. But why? Simply put, browsers like Opera Mini consume less data and they have attracted a lot of users. The following is an excerpt from a report published by Facebook about the state of global connectivity in 2015:
But in locations like Sub-Saharan Africa where 69% of people live on less than $2 per day, only 53% of the population can afford the internet with a cap of 20MB, an amount that provides just 1-2 hours of web browsing a month.
The African Exponent is an African based news organization and so most of the traffic originates from Africa. This report has huge implications for us. Let us break it down a bit.
If a normal user visits 10 websites a day, theoretically, that leaves us with 2MB of data to play with. The average page on The African Exponent is about 400KB and a user has about 5 page views before their data saving instincts kick in. Most sites have page sizes that are higher than that. According to Gmetrix, the average size of a loaded web page today is about 2MB.
We want users to spend more time on our sites by viewing more pages and interacting with all the features that we offer. For instance, a lot of newsworthy events happen every day and we need to keep the user updated while taking into account that this particular user might be limited in terms of data.
Browsers like Opera Mini can to compress web pages up to 10% of the original page size. This means that if your website sends pages whose average size is 400KB including images, JavaScript, CSS and other assets that you need to render your page, Opera Mini promises to send an effective 40KB to the user. What magic is this? This theoretically raises the potential room for more page views for your site from ~ 5 to ~50 page views. Depending on what your business focuses on, this might mean 10x more conversions from Opera Mini and if it contributes to a significant amount of traffic to your site then that will be a big win for you.
Why Bother?
Occasionally you might have heard that Opera Mini has a some 250 million users and you might have let that slide. What's that have to do with me? You might actually be correct. That number might not matter to you at all. But it also takes a minute to be sure. If you have an analytics solution installed on your website, the facts to back you up will be easy to get. For Google Analytics, check Audience->Technology->Browser & OS:
Is it clear yet? Opera Mini makes up to a large share of our traffic at The African Exponent. As always, before diving into this venture, you should check your data on your analytics solution and see what technologies users are using to reach your website. Sometimes this might not be something that is urgent for your particular site. If it is then you need to make sure that your website works very well in Opera Mini.
---
Okay, enough of all this, let's get a bit more technical. The items and experiences below are tested on Opera Mini 19 in extreme mode and Chrome 56, both on an Android device.
Many major websites are already optimized to work well in Opera Mini. Let us see how this looks like.
Opera Mini handles web pages differently compared to other web browsers. In most web browsers, when a user requests a web page, the browser will resolve the address of the specific website and fetch that particular page directly from the website's servers. When the server responds with an HTML page, the browser parses the HTML and downloads any images, JavaScript, style sheets and other assets required to render that page. Note that setting up TCP requests is already an expensive process and downloading the extra assets such as images and JavaScript files eats up resources on the page that could be used for something else.
Parsing JavaScript is also a CPU intensive operation. JavaScript is the Lingua Franca of the web today, and it has gotten very powerful over time enabling us to do things like crazy animations that we never thought were possible before. That came with a cost of file size and parse time. Reports from the 2016 Chrome Dev summit show that websites now on average ship nearly 4 times more JavaScript in terms of file size compared to 2010. (113KB Nov 2010/408KB Oct 2016). This is meaningless until you consider the fact that on average it takes about 500 milliseconds to parse 300kb of JavaScript on an Apple Iphone 4. The Iphone 4 is an okay device, the performance is great and users will somewhat be satisfied to wait that long. Adding network latencies, image download times, and actually painting something to the screen makes such a big blow to device's performance such that in low-end and older devices your website appears slow, sluggish and completely unusable.
Users in many African countries cannot afford expensive high-end phones that can crunch all the awesomeness in your JavaScript and so they opt into buying cheap low-end phones that they can afford. These devices are limited in both memory and CPU and the stakes rendered above would make most websites unusable.
Enter Opera Mini
In simple terms, Opera Mini transfers page rendering workload from the phone to Opera's own servers. A user requests your web page, the request goes through Opera Mini servers, Opera Mini Servers make a request to that particular website and then the servers process the response and transcode it into something called an Opera Binary Markup Language (OBML) - more on this in a bit, which is then sent to the user's device. The Opera Mini Browser is left with one function only, translate the OBML into something that the user can see.
You can think of OBML as some sort of super image that the Opera Mini browser can render to the screen. We can immediately see the advantages here. Most of the operations that are CPU intensive are done by the Opera Mini Servers e.g. The servers will parse your markup, download all the JavaScript, CSS, images, parse your JavaScript and then only send the final markup to the device. Your site then loads faster this way.
The Opera Mini Servers can cache frequent resources that your website needs. For instance, if your website uses jQuery 3.0.0 and we know that Opera Mini processes millions of requests every day that might have the same version, there is no need to get and ultimately parse this particular version of jQuery every time. Your website can enjoy the full benefits of a cached version and even load faster through Opera Mini. Much of the performance control is now left to how Opera implements their architecture, rather than hoping for a website to be optimized in its raw form.
Apart from all these goodies that we get, there are downsides that we have to consider while we develop our websites. Consider the following situation.
We have a simple script that appends a new H1 tag every 500 milliseconds (forever) to tell the user that we love them. This is sleek right? Everybody needs some love. So we said before that the Opera Mini Servers will transcode this into OBML which might be gibberish to us but not for the Opera Mini browser. So how will this be displayed if our actual JavaScript is not transferred to the user? Think about it. If we were developers behind Opera Mini, the simplest solution would be to just detect all these endless functions and strip them out. But what if the developer is trying to collect important information after the page has loaded? We would have to strike a fair balance. It turns out Opera Mini tackles this problem intelligently.
JavaScript in Opera Mini
Let's test the web page above and see what happens. Most browsers lack emulators for Opera Mini but fortunately, Opera has been so kind as to giv us with all the tooling we would need to emulate an actual page rendered through Opera Mini Servers.
If you want to get your hands dirty, head over to Installing Opera Mini on Your Computer and follow the instructions. Once set up, you can start your website as you normally would on a specific port. Note that we need to test our site as rendered through Opera Mini Servers. That means we cannot test using URLs such as http://localhost and so on since those cannot be requested externally from those servers. The easiest way to do this is through Ngrok. Quickly download the executable and run it. e.g. ./ngrok http 3000 to expose port 3000 to your own tunnel. Ngrok will give you a unique URL which you can then put into Opera Mini Emulator and access your local site.
In Summary:
- Your website is listening locally at port 3000 but Opera Mini cannot access the site locally through http://localhost:3000
- Ngrok helps you create a secure tunnel to the internet and gives you a unique URL.
- You type this URL into the emulator on your computer, or the Opera Mini browser on your mobile phone.
- Opera Mini requests the web page at that unique URL and Ngrok service forwards that to your computer.
- Your computer responds with the web page, which then goes back to Opera Mini Servers
- Opera Mini Servers transcode the page into OBML and sends it back to the browser to be rendered which then allows us to view and test the results.
Results:
Note that our setInterval function does not execute in Opera Mini! Let us try another common use case. Assume that we want to ask our user to subscribe to our mailing list or like our Facebook page when the page loads. We want to wait 2 seconds when the page loads and ask the user to subscribe. In this context, our conversion is a user subscribing to our newsletter. Let us see what happens.
Results:
That too did not execute. These are among the quirks you will have to keep in mind. Here is a summary of various JavaScript behaviours and patterns that specifically apply to Opera Mini.
setTimeout and setIntervalsetTimeout and setInterval are subject to timeout of ~5 seconds in newer versions of Opera Mini. In simple terms, you cannot have a timeout that exceeds 5 seconds or a setInterval where the interval sum exceeds 5 seconds. e.g. If you have a setInterval function that has a 1 second interval, it will be executed at best 5 times. In my experience, if you can avoid these functions, then avoid them completely as their behaviour is unpredictable. For instance, to avoid losing conversions from Opera Mini users, you would want to create a simple form for browsers like Opera Mini where users can type in their email and subscribe rather than using JavaScript.
XMLHttpRequest
Ajax requests are subject to the same restrictions as setInterval functions. You have to make sure that your request does not take too long to complete or else it will be paused.
User Actions
In Opera Mini, every action requires a user interaction and every action requires a request to the Opera Mini Servers. For instance, you cannot have a self executing anonymous request that has not been initiated by the user. The most common areas affected by this limitation are the navigation blocks. See below for a demonstration.
If you remember, we covered the fact that JavaScript in Opera Mini is executed on Opera Mini Servers and not the device. Therefore, actions such as opening the navigation drawer must be sent to the servers so that they can render the new OBML that is returned to the user showing that the navigation is actually open. If you have fancy animations such as when the user opens the navigation, the user will not get to see that part. It is either in an opened state, or a closed state.
These server round trips can get really annoying so we are better off optimizing for that section of our website too. At The African Exponent, we noticed that users tend to visit our Home page a lot, together with our Politics category and Blogs. We can save the user from these extra requests and show a simple quick navigation when we detect that they are using Opera Mini - more on this in a bit.
Opening new windows
Opera mini does not support window API such as window.open(). If a user signs up for your newsletter and you want to show them a thank you page, Opera Mini will open the passed link as a new screen. If keeping this user at that particular page is important to you then you might want to consider other options such as appending a new success node on the same page notifying the user that they have successfully subscribed to your newsletter. Every action requires a server roundtrip so when the new OBML is rendered, the user will see the success message.
Browser Storage
With Progressive Web Apps on the rise, most websites today make intelligent use of browser storage API like Localstorage and indexedDB. Opera Mini does not support either of these technologies. It's a good practice to test for browser features before using them which will make sure that you are at a safe place if your website lands on any other browser that does not support the features that you want to use.
Form Validation
One of the best things about HTML5 is that it adds very helpful client side form validation techniques to our toolbox. By using attributes such as type="email", we can let the browser help us make sure that the user typed in text to conforms to recognized email formats before the form is submitted. This should always be coupled with server-side validation. These attributes also help notify the user of missing fields and incorrect email formats quickly before they submit their forms. In Opera Mini, most if not all these attributes are not supported. They default to text. Opera suggests that you can add the attributes and use them to validate while your script runs in their servers during submission. You can get the attributes and validate the input yourself.
You can read more about unsupported API and behaviours at Opera Dev Website on Opera Mini and JavaScript.
---
Layout and Styling
Opera mini seeks to be fast and optimizing the layout of the content and strictly preventing some items from displaying in the final output shouldn’t come as a surprise. As developers, we need to be up to date of what is and what is not supported so that we can better optimize our site to display well in absence of certain stylistic features. Here is a brief summary of things I've encountered along the way.
Fixed Positioning
Many of us love fixed positions. We can make sure that we advertise our brands on our static top navigation when the user is on our site. Some sites often place fixed ads at the bottom of their pages to increase their ad impressions and hence more potential revenue. When it comes to Opera Mini, well, the code and images below summarize it all.
Searching through Opera docs, I have not yet found the details about fixed positioning not being supported but as you can see they are not supported as of Opera 19. If you have a fixed bottom navigation, you might want to replace it with one that flows with the document or else that bottom navigation might cover content while the user is scrolling through the page.
Line heights
Opera Mini does not respect line heights and any hacks that use line heights will not work. Avoid vertical aligning your items using line heights. Most of the time, your text will display well with the default line height.
No Support For Web Fonts
Forget Google Fonts, period. Opera puts the user first. This saves bandwidth and uses built-in fonts in the user's device that are more often already optimized to display well in those devices
No Support For Icon Fonts
Icon Fonts such as those provided by fontawesome.com are not supported. It is good to know this beforehand since you can fall back to other mechanisms if you detect a browser like Opera Mini. Most websites use icons to provide meaningful information such as drop downs on menus and so on. If you don't carefully optimize your site with fallback behaviour, your users from browsers like Opera Mini will fail to use most of the features you offer and this might lead to a significant loss in conversions.
Opera suggests that you use SVG images which can be compressed into smaller sizes than Icon Fonts.
CSS Gradients Not Supported
When used well, CSS Gradients can make your website appear more attractive and futuristic. Unfortunately, Opera Mini does not support CSS Gradients yet and therefore you should try as much as possible to have a fallback. e.g. If you have a brown gradient with white text on top of it, make sure that you set the background property to brown before setting the gradient property. This ensures that Opera Mini will set the default brown color as the background color ensuring that your white text remains visible. Otherwise, the default white background will kick in and the text will not be visible to the user.
For more information on these and other items, consult Making Websites That Work Well With Opera Mini.
More tips
Images
Images contribute to a lot of bandwidths spent by users on the web today. It shouldn't come as a surprise that optimizing images on your site is probably the best starting point to make your site run faster. And of course this is one of the tasks that Opera Mini does best. Opera Mini users have the option to reduce the quality of the final images rendered on their screens so there is no use rendering an HTML markup that references high quality retina-like images.
At The African Exponent, all images that are uploaded are processed to create 4 new optimized versions of that image. Whenever we detect Opera Mini, we try our best to serve optimized and highly compressed images. We use ImageMagick behind the scenes and have open sourced this particular functions. Configuring ImageMagick can be a hustle so take a look at our ImageFunctions repo in Github to start you off.
Debugging
You can easily debug your loaded web page in Opera Mini by typing server:console on the URL bar. This will show you most of the JavaScript errors that were encountered when rendering your page. This is probably a good starting point to detect API used in your code that is not supported in Opera Mini.
Third Party Libraries
It is a common practice to lazy load libraries like Facebook SDK and Google Plus Scripts to improve the loading performance of our web pages. Most of these libraries have very short time span before they need to be downloaded again by the browser. For instance, at The African Exponent, we use Facebook Comments Plugin to help users share their thoughts on our articles. This plugin is loaded on demand when the user clicks the "show comments" button. For users not interested to see the comments, we can save the additional data that would be consumed by loading it every time they read an article.
We covered before that in Opera Mini, every action requires a server roundtrip. Opera Mini needs to request the scripts and parse the documents with those downloaded scripts and thus showing comments. This is transcoded into OBML and returned to the user's device. This is irritating if the user will have to incur additional page loads to show most components on our site. In our experience, we found that it is way better to load these scripts during the initial page load and Opera Mini has proved to be very efficient in rendering our Facebook comments. The load speed is still as fast as loading a page without the Facebook comments.
Detection
If you ask designers today to choose between a separate mobile site or a responsive design, I'm certain that you will get different opinions. Some think that having a separate site for mobile users is better since developers can better address and create pages that are optimized to work on mobile devices. On the other side, having a responsive design means that you as a developer get to work on one code base that becomes more manageable over time as you add new features. The same content is served to all users and search engines.
This debate extends to the Mini browsers too. Should we create a separate site for browsers such as Opera Mini or is it better to just optimize our existing site so that it works in Opera Mini too?
The answer really depends on your current setup. For example, at The African Exponent, we often use newer browser API such as LocaStorage and indexedDB. We use ServiceWorkers and the newly offered PasswordCredentials API. We are probably going to use the next set of awesome API that are going to be announced. We use frameworks like ReactJS that have implemented their own virtual DOM to improve performance. For us to move faster in implementing these features, we do not want to worry about supporting and fallback in Mini browsers. This is the core reason why we focused a lot of our time to create a separate version of our site that is optimized to work well with Opera Mini. Most new pages on The African Exponent (main) always come with their mini versions that is rendered when we detect that the user is either using Mini browsers like Opera Mini, or older browsers like Internet Explorer 7 & 8.
You can easily detect browsers on your servers by parsing the incoming user agents. We use NodeJs and detecting the browser can be as simple as...
Conclusion
You might be thinking that it's best if the folks at Opera loosen up some of these limitations. Remember, the core reasons that people actually use Opera Mini and keep coming back is that it saves a lot of their data. Every year the web increases in complexity and Opera Devs have to figure out how to best optimize these sites to display well on users devices. Perhaps the first step would be to make our own websites more efficient without any assumptions about the end user's device.
Opera does a good job of reminding users to upgrade your browsers so most of the time you'll have to test on one or two versions of Opera Mini.
Opera Mini has shown us some good results in terms of the load time and overall performance. Most of our users are on 2G connections and if you've ever tried to optimize your site's time to interactive, then I'll just leave you with this.