Published on <a href="http://ift.tt/2mG6HaJ">| Prototyping: From UX to Front End &mdash; Medium</a> Browser 
<a href="http://ift.tt/1cv7T36">Progressive enhancement</a> focuses around providing a core ‘device-agnostic’ experience for all users. By starting with a solid foundation that works everywhere, HTML, we ensure our application is usable for as wide an audience as possible. This encourages us to pare down our applications to their essential features — be it reading the news or sending and receiving messages. Once we’re confident this core experience is functional for everyone, we can start to layer on styling and interaction to provide a better experience for devices which support it.
<img alt="" src="http://ift.tt/2mFV0AQ">Simple HTML, before and after CSS and JavaScript.
Although progressive enhancement is a popular technique for content-driven sites, it’s often ignored on modern web-apps since it de-prioritises more ‘dynamic’ features that likely wouldn’t work on older devices. However, while the main advantages of progressive enhancement are traditionally seen as reliability and compatibility, there are also many performance benefits that come from adopting a PE-friendly mindset that make it more than worth considering for your next application.
<h3>Faster time-to-interactive</h3>
Many modern apps utilise client-side frameworks (such as <a href="https://angularjs.org/">Angular</a> and <a href="http://ift.tt/1jBdybn">React</a>) to provide their ‘core’ experience. These often require downloading the full application to the device before becoming usable, resulting in a long delay for users on slower connections.
<img alt="" src="http://ift.tt/2n08mKP">A large JavaScript bundle delaying time-to-interactive.
While client-side rendering can be great for repeat visitors or dynamic features, serving simple HTML is still the fastest way to get your application in the hands of your users. There’s no waiting for large files to download and execute — you get instantly-usable HTML without any dependencies. By starting with simple HTML/CSS, you let your users interact with your app as soon as possible.
<h3>Non-blocking font loading</h3>
Web-fonts have become extremely popular in recent years, but the best way of loading them is still a contentious issue. Serving them to everyone immediately can lead to the infamous ‘<a href="http://ift.tt/1NJ9zet">flash of invisible text</a>’ while the browser downloads the font, which on some browsers (such as iOS Safari) leads to invisible content for as long as the font takes to download.
<img alt="" src="http://ift.tt/2mZRLXC">It’s there, you just can’t see it.
Instead, we can use an already available ‘system’ font (such as Arial) and then only swap it out when we’re sure our custom font is ready and supported. This means the content will always be visible, regardless of the device or network capabilities. This may be distracting on the first visit, as the font will visibly change after a few seconds, but is preferable to hiding content.
<img alt="" src="http://ift.tt/2mG45tp">
This is the basic principle of progressive enhancement — starting with a reliable and fast experience, then ‘layering’ on enhancements when we can.
<h3>Conditional loading</h3>
Some of the most impressive features on the web mimic native apps, such as real-time chat and ‘WYSIWYG’ editors. Unfortunately these can often be very large and complex files, usually JavaScript, that result in slower sites and larger downloads.
Taking a PE-friendly approach means ensuring the core functions behind these actions (e.g. typing content, sending a form) don’t rely on external files or JavaScript. Then, in the background, we can ‘progressively’ load the enhanced versions of these features and swap them out when ready. Better still, we can load these assets only when relevant and not (for instance) if there is no WYSIWYG editor on the page.
<img alt="" src="http://ift.tt/2mZTNqy">A simple text area, becoming a WYSIWYG editor when clicked
This means that users don’t need to wait for core functionality within your application. If they’re on a slow device or network connection they can still use a simple version of a feature without waiting.
<h3>Being selective</h3>
We can take our conditional loading of ‘enhanced’ features one-step further by being even more selective about who receives them.
Many older browsers have poor support for modern features, often necessitating the addition of large helper libraries (known as ‘polyfills’) to fill in the gaps. This usually means serving visitors larger files than they need, just to cater to the lowest common denominator.
Instead, we can employ a technique the BBC have referred to as ‘<a href="http://ift.tt/17bwLAn">cutting the mustard</a>’. We can run a simple test when our website loads that checks for the existence of ‘modern’ features and then loads the appropriate file based on the result. Modern browsers get the modern code, older browsers get the larger backwards-compatible code, and very old browsers don’t get any of the enhancements.
<img alt="" src="http://ift.tt/2mZSyHL">
By checking up front, we can ensure users only download and run appropriate code. Even better, since the basic functionality is usable without the enhancements, users can still interact with the page while this is going on in the background.
<h3>One more thing</h3>
Of course, there are a bunch of other benefits of a progressively-enhanced application. Your app will be far more error tolerant — if something goes wrong with a fancy new feature, there’s a good chance your users will still be able to complete their task with the ‘basic’ version.
Progressive enhancement also helps save time when it comes to cross-device testing since you can be safe in the knowledge that your app will only layer on features when they’re supported. Practically everyone is guaranteed a functional experience, regardless of browser or device.
Although everyone appreciates better performance and resiliency, progressive enhancement remains a contentious issue. Some developers feel the approach limits their ability to provide dynamic experiences, especially those that mimic native applications. Many modern tools and frameworks, such as React and Angular, are written entirely in JavaScript. While these provide a fast, ‘app-like’ experience, they also won’t (usually) work for customers who have JavaScript disabled, or if there is a problem with parsing the script. Others consider the future of progressive enhancement to be in network resiliency, ensuring that pages work ‘offline’ thanks to new technology such as <a href="http://ift.tt/2dsDrBJ">service workers</a>.
Like all techniques and methodologies, progressive enhancement doesn’t need to be followed dogmatically and is more a guideline than a rule. However, it’s a valuable mindset that can help improve your application for all users, not just those on slower or less capable devices.
<h3>About us</h3>
We make businesses more productive with digital tools and applications for the web. We’ve helped clients such as Shell, British Airways and UK Gov improve efficiency and streamline their business. Take a look for yourself at <a href="http://ift.tt/MXpmfC">Browser London</a>.
We publish content on a (almost) monthly basis, so if you like what you’ve read then keep in touch on Medium, <a href="https://twitter.com/browserlondon">Twitter</a> or via our <a href="http://ift.tt/2mZUDnr">Newsletter</a>.
<img src="http://ift.tt/2mFW6wB" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2mZThsz">The Performance Benefits of Progressive Enhancement</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Performance Benefits of Progressive Enhancement

Top Stories