Responsive design alone is not enough: we need adaptive performance

Responsive website design is one of the fundamental solutions to the problem of the diversity of aspect ratios and screen resolutions of mobile devices. But at the same time, many sites have big performance issues. Sometimes it comes to the fact that they cannot be normally viewed on anything except the most powerful smartphones. A paradoxical situation arises when responsive design, designed to expand the audience of sites, itself turns into a kind of obstacle to this.

One of the main reasons for this situation is the focus primarily on desktop and laptop users. It would seem that it is enough to change the priority and focus on mobile users when creating a design. But this is still not a guarantee of good performance. It seems that we are too carried away by the idea of ​​gradual degradation, using all kinds of shim libraries and polyfills to compensate for the missing functionality. For the sake of speeding up development and ensuring browser compatibility, we rely too much on all kinds of libraries.

Many will probably ask: “And what is the problem? Most visitors to my site use normal smartphones with the latest versions of the OS. My site works without question for them, analytics tells me about it. ” But it’s quite obvious that analytics will tell exactly about those who can use your site. And if users of Android 2.3 are not mentioned in it, this does not mean that they are not there or that you can ignore them. Or your site simply can not offer them anything? It is not surprising, but even today you can find on sale devices running older versions of the OS. And it is hardly advisable to discard all users of not too fresh devices and OSes.

Therefore, I would like to discuss with you the ideal cases and current goals of web development. And also talk about techniques and concepts that can help us achieve these very goals.

Focus on obsolete models

Until now, a significant share of annual sales falls on traditional push-button mobile phones. Most buyers purchase a new phone once every few years, without being carried away by the pursuit of fresh models. Be that as it may, a certain fraction of the devices available to the population is quite suitable for web surfing. Do not forget all kinds of readers and other devices on which people can view sites: WAP devices, televisions, etc.



What are the most likely use cases for this diverse motley audience? These people on their devices are unlikely to read long articles and actively seek information on the web. But they can experience real torment simply by trying to type a web address on the keypad, or using the cursor keys to scroll through the page in search of the phone number and address of the company, or trying to double-click.

How difficult for us, web developers, to implement as an entry level, designed for such "semi-mobile" devices? The level at which information is presented taking into account certain performance limitations?

Gradual Improvement

Using the concept of gradual deterioration as a kind of basic approach has led us to stop thinking about something else. Having realized a gradual deterioration, we calm down and consider the work done. We’re less and less thinking about it, as more and more frameworks and libraries work in accordance with this approach. And finally, polyfill and shim libraries in a number of cases completely saved us from the need to use gradual performance degradation.

In other words, the more accessible this functionality becomes, the less we think about the features of its use. It can take, let's say, three forms:

• A sharp deterioration in performance: if some functional cannot be used without tricks, then it is implemented so poorly that it becomes either impossible to use at all, or it can be limited.
• Gradual deterioration: if some functionality cannot be used without tricks, then it is implemented at a satisfactory level.
• A sharp improvement in performance: if some functionality cannot be used without tricks, then it is emulated using polyfill and shim libraries.

Everything, the problem is solved?

Well, yes, if you do not pay attention to the performance of the device of the lower price segment.

They have weaker processors and less memory, but the load on them only increases. The use of polyfill creates the illusion of the availability of all modern functional diversity on any device. And there is a temptation to use this tool without any restrictions. As a result, the least efficient devices are forced to handle very heavy computing tasks. And we are confident that we give users the “best” user experience.



What if we use the concept of “gradual performance improvement” as opposed to “gradual degradation”? That is, start with the site version with the least performance requirements, loading additional functionality until a balance of usability and performance is reached. Thus, the volume of traffic and processing power requirements will be adapted to use weaker devices.

Of course, at the moment it’s impossible to take and switch to a similar concept of website development, because it is simply not supported by the vast majority of frameworks and libraries. And few developers at all discuss this issue, as well as trying to implement this approach. Basically, experiments in this direction are reduced to the adaptation of microfunctionality. But once all other concepts went through this.

He can, but should he?

Another good approach is to pre-test the possibility of using some functionality on the device before activating it.

However, this is a double-edged sword. For example, you can install the latest version of Google Chrome on an old Android smartphone. However, it can still run CSS animations , WebGL , background parallax effects, and more. The old smartphone just does not pull it all. The browser will fall, and the device will generally stop responding to user actions until you reboot it or until it copes with the tasks that have fallen on it.

A similar problem began to arise more and more often in various Android applications. One vivid example of a noticeable performance degradation was the upgrade of the Google Talk / Hangouts application. At one point, it turned from a very light messenger that works on almost all devices, into a clumsy monster, almost unsuitable for old smartphones.

Once again, these "old" devices can still be bought in stores.

A similar story happened with the YouTube application , and with mobile Twitter, and with many others.

So when you plan to develop your sites and applications, then try to evaluate the importance of high performance when using key functions compared to all sorts of fashionable twists. Or at least make a separate version for your cool application / service / site for legacy users.

Leave users the option to opt out of cutting-edge functionality

Have you ever used Gmail on fairly old devices or with a poor connection? In such cases, “ loading the basic HTML interface ” will be very useful .

Why do not all other developers provide such an opportunity in their adaptive, animated, window-dressing tools that are adapted for the touch interface? After all, we want to achieve as many users as possible, and for the sake of this we are sophisticated with all these technologies. As a result, less and less potential consumers are able to get at least basic information about our products. If “gradual improvement” is too expensive a concept for you, then why not give users the option to download a simple text version if the “superversion” is shamelessly slowing down their devices?

Do you really need the whole library?

Another practice to improve the performance situation. Sometimes it’s too time-consuming to keep track of which libraries and modules are really used by your product and include only them. But you should not shove the entire set of tools on each page.



You can make the site structure and its code cleaner using some tool that automatically analyzes and adapts the number of libraries used.

Many libraries and applications before using them provide the ability to configure the "payload". Perhaps the time has come to somehow standardize and automate the principle of building the architecture of "use it or lose it." For example, use special versions of libraries for developers who can track all the functions used and reduce the number of dependencies, or at least the degree of use. This would help reduce the bulkiness of our products, reduce performance requirements.

"What can I do?"

First of all, you need to generally address the topic of performance on older devices. Reflect on different approaches, discuss with colleagues, on forums, try to find specific practical solutions.

Give it a try . Dig up your old phone and upload your sites to it, check if it can display anything at all. Visit your relatives who are far from high technology and try on the role of techno-evangelist. Observe whether their lag in the use of modern technologies is a consequence of the problem of accessibility of sites and, as a result, information.

If you order website development, then ask to implement at least a minimum support for older devices. Remember that you do not need to run all sorts of features on weak gadgets at all costs. The main thing is that their users can quickly find your contact information without hanging devices. The solution to this problem should not take more than one or two days, with preliminary thought over. Do not forget about the main reasons for creating a website as such.

If you are developing a library, framework, bundle, or any other embedded software, then you can influence the improvement of the performance situation on weak devices more than any other. If you can integrate support for the above concepts into your products, you can influence the development of web development.

And finallyif you are a regular developer or designer , do not limit yourself to “best practices” in your work. Always try to look beyond the horizon. The spread of concepts that so far are not claimed by anyone, are not supported by anything and are not documented depends on your diligence. But which will only benefit your customers and users.