Well-deployed technologies
HTTP Network API
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.
Cross-domain Requests
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.
Server-pushed Requests
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).
Bidirectional Connections
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.
On-line State
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).
Network Characteristics
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.
Technologies in progress
Low-level I/O
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.
HTTP Network API
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.
Server-pushed Requests
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).
P2P Data Connections
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.
Bidirectional Connections
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.
Exploratory work
Background execution
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).
Network Characteristics
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.