Another best practice to follow to improve the performance of our website for those old devices, which have limited functionalities and are not as fast as today's mobile devices.
We know that since we have the Internet, we have web browsers to display the content. We should not forget that there are users who still use older mobile devices and which lack the features of modern equivalents; we can handle this using graceful degradation.
Graceful degradation is a strategy, which is used to handle the design of web pages for different browsers. If we built a website using the graceful degradation strategy, then it is intended to be viewed first by the modern browsers and then in the old browsers, which have less features. It should degrade in such a way that our website still looks good with respect to look and feel and is still functional but with less features.
But today's modern designers and developers do not like this approach. The main reason is that it often turns into a demand where our users should download the most recent and updated browser in order to view the best view of our website. We should remember that this is not graceful degradation.
If we are asking our users to download a modern browser, then that means we are using a browser-centric approach. Some points we should remember to follow for graceful degradation, which can equally apply to progressive enhancement:
- We should write HTML, which is valid and standard compliant
- We should use external style sheets
- We should always link our scripts externally
- We should always make sure that our content is accessible for old browsers without CSS or JavaScript
When developing responsive sites, we should check to see if our target browser or device can support a specific feature, rather than simply assuming it can be used.
For example, if we were to install the latest Chrome browser on an old Android phone, we might be tempted to assume that it will support the latest features, such as CSS animations, background parallax effects, and WebGL.
But, is this really the case? What would happen if we were to try to operate a site that relied on a feature that is not supported on an older Android device? The end result might be that our browser becomes unresponsive or crash; we would be forced to have to reboot it to restore service.
This issue was faced by Android users recently in a big way and in this the most noticeable application to suffer was Google Talk/Hangout. With their upgrade, the most lightweight chat service of Google was turned to an almost unusable application due to performance issues on the older devices.
This way it is really important to filter out those features, which are less usable and have less relevance on small screens. A great example is the applications that make use of proximity sensors. This helped push manufacturers to make this a standard feature across all newer smartphones.
We developed an eye-catching, responsive, animated, and touch-oriented website but for a user who has poor Internet connection or an old device?
What should we do if the site appears to be hanging during the initial load or on subsequent page refreshes?
The reader will of course be confused as to what they should do.
Here is a simple thing we should do. Ever run Gmail on an old device or slow Internet connection? If yes, then you must have noticed Load basic HTML (for slow connections), or even this gem, where slower connections mean we may be forced to use Gmail's simple view, because a slow Internet connection makes using the standard view impossible:
For the elite few who are used to high-speed cable or broadband connections, they may find it hard to believe that other users do not have that luxury, and are forced to use the basic view, as would be the case in our example. Using this option loads the basic GUI version of Gmail, which is optimized for slower connections, and allows the user to interact with the site.
This illustrates a great point—if a site must use the latest features, then we should consider implementing a basic or standard mode in our application. We progressed from the days of a select few sites that have all of the latest features and which get all of the traffic, providing a user with what they are looking for on the website is what they care about.
We should always follow the standard of either use it or keep it. It is difficult to keep track of all the libraries and modules which are in use; we have to strike a fine balance between the libraries we use and maintaining site speed.
Many frameworks and libraries now have the option to customize the functionality provided within; for example, we may only require key elements of jQuery (if we were using it); we can select to exclude redundant functionality when downloading the library. However, if we are still at a development phase, then we will require the whole library; we can choose the parts needed to run our application, before minifying it for production use.