Well-deployed technologies

XMLHttpRequest (the basis for Ajax development) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol: the W3C specification (formerly known as XMLHttpRequest Level 2) was meant to document the existing deployed API (with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content). That work is now done in the WHATWG. The WHATWG Fetch API also provides a more powerful Promise-based alternative.

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing (CORS) mechanism, opening up much wider cooperation across Web applications and services. Note the W3C version of the CORS specification does not reflect current implementations and will be obsoleted. The CORS mechanism is now a core part of the on-going Fetch specification in the WHATWG.

XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The Server-Sent Events API allows triggering DOM events based on push notifications (via HTTP and other protocols).

The WebSocket API, built on top of the IETF WebSocket protocol (RFC6455), offers a bidirectional, more flexible, and less resource intensive network connectivity than XMLHttpRequest.

Of course, an important part of using network connectivity relies on being able to determine if such connectivity exists, and the type of network available. The HTML5 onLine DOM flag, and its associated change event, online, signals when network connectivity is not available to the Web environment (the flag is unreliable to assert that the Web environment is online).

The Resource Timing API offers to measure precisely the impact of the network on the time needed to load various resources, offering another approach to adapt a Web app to its network environment.

FeatureSpecification / GroupMaturityCurrent implementations
Select browsers…
HTTP Network APIXMLHttpRequest
WHATWG
Living Standard
Fetch
WHATWG
Living Standard
Cross-domain RequestsCross-Origin Resource Sharing
Web Applications Working Group (historical)
Web Application Security Working Group
Recommendation
Server-pushed RequestsServer-Sent Events
Web Applications Working Group (historical)
Recommendation
Bidirectional ConnectionsThe WebSocket API
Web Applications Working Group (historical)
Candidate Recommendation
On-line StateonLine DOM flag in HTML Standard
WHATWG
Living Standard
Network CharacteristicsResource Timing Level 1
Web Performance Working Group
Candidate Recommendation

Technologies in progress

The Streams specification provides APIs for creating, composing, and consuming streams of data efficiently. Network conditions may fluctuate in mobile networks and bandwidth may be restricted; access to low-level I/O primitives enable flow control within Web applications to adjust the network delivery to some reader's speed (e.g. a media player), and perceived rendering performance improvements, e.g. when a Service Worker assembles a stream from content previously cached and content fetched online to speed up the first set of render operations of a page. The ability to cancel a stream to stop download at any time also helps reclaim network bandwidth for other tasks as soon as needed.

The Beacon API aims at letting developers queue unsupervised HTTP requests, leaving it to the browser to execute them when appropriate, opening the door for better network optimizations.

The Push API allows Web applications to receive server-sent messages whether or not the said Web app is active in a browser window. The IETF Web-Based Push Notifications Working Group developed a companion protocol suitable to request the delivery of a push message to a user agent, create new push message delivery subscriptions, and monitor for new push messages (RFC 8030).

The work on Web Real-Time Communications also provides direct peer-to-peer data connections between browsers with real-time characteristics, opening the way to collaborative multi-devices Web applications.

FeatureSpecification / GroupMaturityCurrent implementations
Select browsers…
Low-level I/OStreams
WHATWG
Living Standard
HTTP Network APIBeacon
Web Performance Working Group
Candidate Recommendation
Server-pushed RequestsPush API
Web Applications Working Group
Working Draft
P2P Data ConnectionsWebRTC 1.0: Real-time Communication Between Browsers
WebRTC Working Group
Candidate Recommendation

Exploratory work

The Web Background Synchronization specification builds on top of Service Workers to enable Web applications to keep their user data up to date seamlessly, by running network operations in the background, adjusting to possibly unreliable connections that users often experience on mobile devices.

Background Fetch defines a similar service worker based download and upload mechanism in the background, but allows the background operation to continue, with user visibility, even if the user closes all windows and workers. The specification is specifically tailored to enable downloads/uploads of large assets (podcasts, movies, textures).

Discontinued work on the Network Information API to address discovery of the network characteristics has now been resumed in the Web Platform Incubator Community Group.

The WebTransport proposal would allow data to be sent and received between a browser and server, implementing pluggable protocols underneath with common APIs on top, notably based on QUIC. The API is similar to WebSocket in that it exposes bidirectional connections between a client and a server, but allows to further reduce the latency of network communications between a client and a server, and also supports multiple streams, unidirectional streams, out-of-order delivery, and unreliable transport. Usage scenarios include sending the state of a game with minimal latency to a server repeatedly using unreliable and out-of-order messages, low-latency streaming of media chunks from a server to a client, and cloud based scenarios where most of the application logic runs on the server.