Well-deployed technologies
The Fetch API provides a powerful Promise-based API to load content from Web servers using the HTTP and HTTPS protocols. It replaces the former XMLHttpRequest API, which was at the heart of Ajax development (XMLHttpRequest may still be used).
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 users 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.
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 fetch and 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 (note the flag is unreliable to assert that the Web environment is online).
The Resource Timing API allows to measure the impact of the network on the time needed to load various resources, offering another approach to adapt a Web app to its networking environment.
Technologies in progress
The work on Web Real-Time Communications provides direct peer-to-peer connections between browsers with real-time characteristics, ideal to manage in-game communication in multiplayer games. Streams exchanged may include data, audio, and video tracks. WebRTC may also be used to communicate with the game's server, effectively replacing the WebSocket API.
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).
Exploratory work
Early work on a Web Background Synchronization API would provide a robust Service Worker-based mechanism to enable Web applications to download and upload content in the background, even in the absence of a running browser.
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.