Adaptive 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 problems. Sometimes it comes to the fact that they can not normally view on anything, except for the most powerful smartphones. There is a paradoxical situation when an adaptive 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 to focus primarily on users of desktops and laptops. It would seem, it is enough to change the priority and when creating a design to focus on mobile users. But this is still not a guarantee of good performance. It seems that we are too carried away by the idea of ​​gradual degradation (graceful degradation), using all sorts of shim libraries and polyfills to compensate for the missing functionality. To speed development and ensure browser compatibility, we rely too heavily on all sorts of libraries.

Probably, many will ask: “And what's the problem? Most visitors to my site use normal smartphones with current OS versions. My website works for them without questions, the analyst tells me about it. ” But it is quite obvious that the analyst will tell exactly about those who can use your site. And if it does not mention users of Android 2.3, then this does not mean that they are not there or that you can ignore them. Or your website just can not offer them anything? As it is not surprising, but even today you can find selling devices running old 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 to talk about techniques and concepts that can help us achieve these very goals.

Outdated model orientation

Until now, a significant proportion of annual sales accounted for traditional push-button mobile phones. Most buyers buy a new phone every few years, without being carried away by the pursuit of fresh models. Anyway, a certain share of the devices available to the population is quite suitable for web surfing. Do not forget all sorts of readers and other devices on which people can browse websites: WAP-devices, TVs, etc.



What are the most likely usage scenarios for this entire diverse audience? These people are unlikely to read long articles on their devices and actively search for information on the web. But they can experience real torment just by trying to type in a web address on a button keyboard, or by using the cursor keys on a page to search for a phone and company address, or trying to double-click.

How much is it difficult for us, web developers, to implement as an initial level, designed for such "semi-mobile" devices? Is the level at which information is presented subject to certain performance limitations?

Gradual performance improvement

Using the concept of gradual degradation as a kind of basic approach has led us to stop thinking about something else. Having implemented a gradual deterioration, we calm down and consider the work done. We are less and less thinking about this, as more and more frameworks and libraries provide work in accordance with this approach. Finally, polycomplete and shim libraries in some cases completely freed us from the need to use gradual degradation of characteristics.

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 functionality fails to be used without tweaks, then it is implemented so badly that it becomes either impossible to use it, or it is possible to a limited extent.
• Gradual degradation of performance: if some functionality fails to be used without tweaks, then it is implemented at a satisfactory level.
• A dramatic improvement in performance: if some functionality fails to be used without tweaks, 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 devices. And there is a temptation to use this tool without any restrictions. As a result, the least productive devices are forced to handle very heavy computational problems. And we are confident that we give users the "best" user experience.



What if you use the concept of "gradual improvement of performance" versus "gradual deterioration"? That is, start with the version of the site with the lowest performance requirements, loading additional functionality until a balance of usability and performance is achieved. Thus, the traffic volume and computing power requirements will be adapted to use weaker devices.

Of course, at the moment it will not be possible to take and go to a similar concept of website development, since it is simply not supported by the vast majority of frameworks and libraries. Yes, and few developers at all discuss this issue, as well as trying to implement this approach. In general, experiments in this direction are reduced to the adaptation of microfunctions. 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, it 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 , parallax background effects and more. The old smartphone just will not pull it all. The browser will crash, and the device will stop responding to user actions altogether until you reboot it or until it copes with the tasks that lean against it.

A similar problem has begun to emerge more and more often in various Android applications. One of the clearest examples of noticeable deterioration in performance was the upgrade of the Google Talk / Hangouts application. At one point, it turned from a very lightweight messenger that works on almost all devices into a hulking monster, almost unsuitable for old smartphones.

Once again we recall: these "old" devices can still be bought in stores.

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

So when you plan the development of your sites and applications, then try to assess the value of high performance when using key functions compared to all sorts of fancy bells and whistles. Or at least make for legacy users a separate version of your cool application / service / site.

Allow users to opt out of the state-of-the-art functionality.

Have you ever used Gmail on fairly old devices or with a bad level of communication? In such cases, “ loading the basic HTML interface ” would be very useful.

Why don't all the other developers consider such an opportunity in their adaptive, animated, online storefronts, sharpened under the touch interface? After all, we want to reach as many users as possible, and for this we are sophisticated with all these technologies. As a result, less and less potential consumers have the opportunity to get at least basic information about our products. If the "gradual improvement" is too expensive for you, why not give users the opportunity to download a simple text version, if the "super version" shamelessly slows down on their devices?

Do you really need the whole library?

Another practice to improve performance. Sometimes it is too difficult to keep track of which libraries and modules are actually used by your product and include only them. But it is not worth while at the same time to shove the whole set of tools on each page.



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

Many libraries and applications before their use make it possible to configure the "payload". Perhaps it is time to somehow standardize and automate the principle of building the architecture “use it or lose it (use or lose)”. 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 do the topic of performance on older devices. Reflect on different approaches, discuss with colleagues, on forums, try to find concrete practical solutions.

Try it . Dig out an old phone and upload your websites on it, see if it can display anything at all. Pay a visit to relatives who are far from high technologies 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 the development of the site , then ask to realize at least a minimal support for old devices. Remember that you do not need at any cost to run all sorts of features on weak gadgets. 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 thinking. 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 more than all others influence the improvement of the performance situation on weak devices. If you can integrate support for the above concepts into your products, you can influence the development of web development.

And finally, if you are an ordinary developer or designer , do not limit your work to “best practices.” Always try to look beyond the horizon. From your diligence depends on the distribution of concepts that have not yet been claimed by anyone, are not supported by anything and are not documented in any way. But which will only benefit your customers and users.