Web Design/Progressive enhancement

It is beneficial for the performance and compatibility of a web site if its pages enhance progressively throughout loading. This means that the essential content is loaded through HTML, the page's appearance is implemented through CSS to the extent possible, and further enhancements are covered by JavaScript, following the inherent rendering path of web browsers.

The order of progressive enhancement: HTML → CSS → JavaScript.
CSS and JavaScript build upon a foundation of HTML code.

Performance

JavaScript finishes last.

When a web page is loaded, the static HTML source code is the first resource downloaded by the client's browser. This means that including the essential content into the HTML source code makes it the first thing to load. Style sheets (CSS), scripts, and multimedia are only downloaded subsequently through additional HTTP requests, and JavaScript code itself is only executed after it finished downloading. Should those resources take too long after the HTML to load, a flash of unstyled content may appear. This is, however, favourable over a blank page.

However, as of 2022, some popular web sites, including Twitter, Instagram, Everipedia, and Quora, do the opposite. They load the page's essential content using JavaScript-based XMLHttpRequests (AJAX / XHR), which is an added abstraction layer. While AJAX and XHR are useful web technologies, they are the last step in the web page's loading process, meaning downloading the essential page content through JavaScript postpones its arrival from the first to the last step in the page loading process.

After downloading, JavaScript needs to place the content into the DOM (document object model) on a JavaScript-dependent page, where it is placed from the beginning on a progressively enhancing page. In other words, the script loads and puts content subsequently to where a progressively enhanced page has it out of the box.

As such, to maximize performance, it is recommended to build the HTML source code on the back end (server side) to the extent possible, and immediately serve the client content that is ready for "consumption", rather than requiring it to be slowly built on the front end (client side) through additional incremental HTTP requests.

Progressive enhancement uses the rule of least power, meaning the capabilities of the less powerful but simpler languages, HTML and CSS, are exhausted before the more powerful and complex language, JavaScript, is made use of.

“ "We don't have any non-JavaScript users" No, all your users are non-JS while they're downloading your JS ” — Jake Archibald, web developer, 15:09 · 28 May 2012

Compatibility

JavaScript is the weakest link in the page loading process.

JavaScript is more versatile than HTML and CSS, and able to implement dynamic client-side enhancements such as interaction without having to reload the page. A notable example is posting a comment or similar and having it appear on screen without the whole page being reloaded.

However, support of HTML and CSS is more consistent across web browsers than JavaScript, since JavaScript is more complicated. Additionally, as described in JavaScript/Compatibility, the JavaScript specification is occasionally changed, such as catch binding being optional since 2019. Implementing such changes could break all JavaScript-based functionality of a site to web browser versions that predate such. Should loading the essential content depend on JavaScript, the entire site would end up useless.

Fragility

Due to its complexity, JavaScript is more fragile than HTML and CSS, meaning errors in the code have a greater impact on the functionality on the site. Even a seemingly minor syntax error like a misplaced semicolon or bracket can break the entire script. JavaScript might be unavailable for several other reasons.

As such, it is recommended to implement elements such as buttons and text submission forms in static HTML and then build upon it using JavaScript, to allow the web browser to fall back to the former in case of a JavaScript error. The fallback version would be less comfortable to the user, for example requiring to refresh the page upon submission, and relocation of some submenus such as a comment reply form on a separate page, but is very much preferable over a defective site.

In simplified words, progressive enhancement means having a less comfortable but working site instead of a defunct site in case of an error in JavaScript code.

Also keep in mind that some users may choose to temporarily deactivate JavaScript to increase performance, power efficiency, and security, or access a site from a public computer with JavaScript deactivated for security reasons. A progressively enhancing site would, albeit with restricted functionality, remain operational in such environment, whereas a site without progressive enhancement could become useless.

Case studies

MediaWiki

The MediaWiki content management system that powers Wikipedia and Wikiversity has implemented progressive enhancement very well. Examples for such are:

• The page content is delivered as static HTML. Pages are navigable and even editable without JavaScript, though JavaScript provides enhancements such as the visual editor, the 2017 wikitext editor, and the overlay interface of the mobile front end.
• The retractable sections on the mobile "Minerva" skin are expanded by default, and only retracted through JavaScript, making the sections readable if JavaScript is unavailable. The same applies to the "Search for contributions" menu on Special:Contributions, which was introduced in 2019.
• The live preview feature also acts as an extension rather than a replacement to the traditional edit previewing that requires a page reload, since the latter remains usable if JavaScript is unavailable.
• With JavaScript unavailable, the individual pages of the tabbed Special:Preferences menu appear together as sections on a single page. As of 2022, a minor flaw is that the tabs at the top are completely missing rather than linking to the sections through HTML anchors.
• Without JavaScript, menus on the responsive mobile view of the Monobook skin are located at the page bottom and linked to from the buttons at the top through HTML anchors. Due to new specifications in CSS (:target), implementing menus does not require JavaScript anymore, but back when this was designed, it was a clever solution.
• If JavaScript is unavailable, the media player falls back to the stock HTML5 player that is shipped with the browser.
• On Special:Search, the multiple-tag-selection widget falls back to a subpage selector, where "advanced" has the search filters as check boxes. The language selector on Special:WelcomeSurvey also falls back to check boxes.

WikiData

On WikiData, entities can be edited without refrehsing the entire page through a JavaScript user interface. The "Edit" button links to the page at "wikidata: Special:SetLabelDescriptionAliases", which is fallen back upon should JavaScript be unavailable.

timeago.js

"timeago.js" is a two-kilobyte JavaScript library which automatically updates relative time stamps (e.g. "3 minutes ago") displayed on a page, on the client side from the absolute time information.

Should JavaScript be unavailable, the absolute time is simply displayed, since it never becomes inaccurate as time passes. If only relative time stamps were served, they could not change until the page is refreshed.

Other examples

• "Keycode.info" jumps to individual pages by detecting keyboard presses using JavaScript. When unavilable, it is accessible through URLs.
• The browser compatibility reference site "caniuse.com" is able to deliver search results without JavaScript, but displays details for each result if JavaScript is enabled.
• Vimeo: Without JavaScript, the watch page still appears with the notice "Please enable JavaScript to experience Vimeo in all of its glory.". However, the video's thumbnail (preview picture) is displayed in place of the video player.
• While SoundCloud is JavaScript-based, track information (title, author, thumbnail, description, date) is included in the static HTML. Comments on tracks without responses but with dates, and track lists on search results and user profiles are too, but limited due to lack of pagination. This means while tracks can not be played with JavaScript unavailable, the site can still be browsed. It should however be noted that SoundCloud performed well in the JavaScript compatibility test.
• The FilePond JavaScript library for file uploading does build upon a traditional HTML-based upload form (<input type=file […] >), meaning on a properly configured server, the uploader can be used without JavaScript. If JavaScript is available, FilePond starts uploading asynchronously (while the page is open) to save time, and adds a modernized user interface.

Resources

• Progressive Enhancement - a Plea for Code Quality by Accessabilly (slideshow by Martin Mengele; March 7, 2021)
• Critical rendering path – Mozilla Developer Network