I’ve been encountering numerous responsive websites lately plagued with performance problems. These issues are often so severe that the websites are practically unusable on anything other than the latest smartphones. This seems counterintuitive, given that responsiveness aims to reach a broader audience.

The main culprit is the persistent desktop-first design approach. A mobile-first perspective seems to offer a solution, but it doesn’t guarantee satisfactory performance on its own. We tend to over-rely on graceful degradation, utilizing shims and polyfills for missing functionalities and leaning on libraries for rapid development and browser compatibility.

You might argue that most website visitors use high-performing smartphones with the latest operating systems and can handle these sites. While analytics might support this, it’s crucial to consider the users who can’t access your site. Does the absence of Android 2.3 in your analytics mean there are no users with those devices, or does it mean your site offers them nothing? Many older devices are still in circulation and shouldn’t be disregarded.

Let’s delve into the ideal scenarios and objectives of web development, examining practices and paradigms that can help us achieve them.

Prioritizing Accessibility: A “Brick-First” Approach

Feature phones still constitute a significant portion of annual phone sales, and a large segment of the population doesn’t upgrade their devices yearly. Factor in older smartphones, Kindles, and other web-enabled devices (like those with WAP, TVs, and even unconventional ones), and the potential reach is vast.

Consider the use cases for this audience. They likely won’t read lengthy articles, browse extensively, or conduct research on these devices. Instead, their primary goal might be to access essential information like phone numbers or addresses, even if it means navigating with a numeric keypad and directional keys.

Given this, implementing a simplified layout below a certain capability and performance threshold to cater to these users seems like a manageable task.

Moving Beyond Graceful Degradation: Embracing Graceful Improvement

Graceful degradation has become a ubiquitous best practice, potentially hindering our ability to think beyond it. While it ensures acceptable usability even with missing features, the increasing availability of polyfills and shims further reduces the need to consider functionality degradation.

Let’s break it down:

Ungraceful degradation: Feature unavailability leads to unusable or highly impractical implementations.

Graceful degradation: Feature unavailability maintains acceptable usability despite limitations.

Ungraceful improvement: Missing features are emulated through polyfills or shims, potentially overlooking performance implications.

While this might seem like a comprehensive solution, it neglects the performance constraints of low-end devices. These devices often lack the processing power and data capabilities of their modern counterparts. Employing polyfills to bridge the gap creates an illusion of universal functionality, leading to scenarios where:

modernizr gets implemented, and everything is polyfilled “just in case.” Consequently, the least capable devices end up shouldering the heaviest data and processing load, hindering the user experience.

Graceful improvement, on the other hand, starts with minimal feature requirements and progressively enhances them based on device capabilities. This approach ensures optimal performance and usability by tailoring the experience to the device’s limitations.

Admittedly, this concept presents challenges: limited framework and library support, scarce discussion, and a focus on micro-functionalities. However, most concepts and functionalities were once at a similar stage.

Rethinking Feature Availability and User Choice

Another common practice is checking for feature availability before activation. However, even if an older device runs the latest Google Chrome version and claims support for features like CSS animations, WebGL, or background parallax effects, it might not genuinely handle them, leading to crashes and unresponsiveness.

This issue is increasingly affecting Android applications, with Google Talk/Hangouts being a prime example. The app’s transition from a lightweight chat application to a resource-intensive one has rendered it practically unusable on older devices (which are still readily available). Similarly, affected the YouTube app and the Twitter app (among others) have been plagued by similar performance issues.

Therefore, it’s crucial to weigh the value of a high-performance core feature against cutting-edge embellishments. Providing a legacy version of your application, service, or content can also benefit users with older devices.

Consider Gmail’s approach for accessing it from older devices or over poor connections: the availability of a “load basic HTML” link. Implementing a similar functionality for your website can ensure accessibility even with limited device capabilities.

Optimizing Library Usage: A “Use It or Lose It” Approach

The “use it or lose it” principle emphasizes including only the necessary libraries and modules. While tracking library usage can be tedious, carrying the entire toolset on every page is inefficient.

Personally, I’ve started analyzing my actual library usage. In the case of jQuery, I often find myself using only a fraction of its features or even just basic functionalities. This has prompted me to remove or decouple dependencies whenever possible.

Imagine the potential of automatically analyzing and minimizing library usage based on actual implementation. While some libraries offer customization options, standardizing an automated “use it or lose it” build architecture seems within reach.

Instead of the “include everything” approach, imagine a development-only library version that, through dependency analysis, traces used features and outputs the minimal required dependencies. This could then be used to cherry-pick, aggregate, and minimize the production output.

Taking Action: From Awareness to Advocacy

The first step is to acknowledge the issue. Discuss it, observe real-world scenarios, and test your websites on older devices. Consider the user experience of those with limited access and advocate for accessibility during project discussions.

When commissioning websites, request at least basic support for older devices. Remember, the goal is not to provide full feature parity but to ensure that even users with limited devices can access essential information. Allocate resources accordingly, as even the simplest solutions can be implemented with minimal effort.

Package developers can make a significant impact by incorporating these concepts into their libraries, frameworks, and bundles. Facilitating accessibility at the platform level can transform the web development landscape.

Finally, developers and designers should strive to go beyond best practices. Pushing for these concepts, even if they’re currently unsupported and undocumented, benefits clients and users alike.

If you’d like to delve deeper into this topic, I’m always happy to discuss it further over a cup of coffee near Zagreb.