Claude Fable 5.1 & GPT-6 Astra packages are live

Network

Free · MIT

Network performance — latency versus bandwidth, connection setup cost, compression, request waterfalls, and delivering bytes from close to the user.

186 lines8.1 KB Sarvam Ai Performance
Target models
Sarvam-105BSarvam-30BSarvam FamilyFuture Sarvam Models
Name
network
Category
Performance
Description
Network performance — latency versus bandwidth, connection setup cost, compression, request waterfalls, and delivering bytes from close to the user.
License
MIT
Author
Agent.md maintainers
Last verified
2026-08-23
Reviewed by
unreviewed

#Locale

Examples use Indian conventions: ₹ amounts, IST, dd/mm/yyyy, Aadhaar and DPDP Act where a standard mentions identity or privacy law. Keep them when you copy an example.


#Purpose

Rules for making the network faster. The central fact: latency, not bandwidth, dominates web performance. Doubling bandwidth barely changes page load time; halving round trips changes it a lot.

Every rule here reduces round trips, moves bytes closer, or sends fewer of them — in that order of impact.


#Count the round trips

A cold HTTPS connection costs, before a single byte of your content:

scss
DNS lookup        1 RTT (0 if cached)
TCP handshake     1 RTT
TLS 1.3 handshake 1 RTT (0 on resumption)
HTTP request      1 RTT

On a 100 ms round trip that is 300–400 ms before anything arrives. Consequences:

  • Every additional origin costs a full connection setup. Three third-party domains on a page is roughly a second of setup on mobile.
  • preconnect for origins you will definitely use, early; dns-prefetch for likely ones. Do not preconnect to everything — each open connection competes.
  • HTTP/2 or HTTP/3 multiplexes many requests over one connection, removing head-of-line blocking at the HTTP layer. HTTP/3 (QUIC) also removes TCP-level head-of-line blocking, which matters most on lossy mobile networks.
  • Keep connections alive. Set the server's keepAliveTimeout above the load balancer's idle timeout, or you get intermittent 502s from close races. → Backend/express

#Eliminate waterfalls

A waterfall is a request that cannot start until a previous one finishes. It is the single largest avoidable cost in most applications.

sql
❌ HTML → JS → fetch config → fetch userfetch orders      4 sequential RTTs
✅ HTML → (JS ∥ config) → (user ∥ orders)                    2
  • Server-render or return data with the document, so the client does not make a round trip to discover what to request. → Frontend/server-components
  • Start independent requests together (Promise.all), on the client and the server. A sequential await chain in a server component is a server-side waterfall.
  • Discovery waterfalls: an import that discovers another import, a JSON manifest that names the real asset. Use modulepreload and preload for known critical resources.
  • Do not preload everything — a preloaded resource competes with the one that actually blocks rendering. → Frontend/performance

#Send fewer bytes

TechniqueTypical saving
Brotli over gzip (static assets)15–25%
AVIF/WebP over JPEG/PNG30–60%
Font subsetting50–90%
Removing an unused dependencyWhatever it weighed
Projecting API responses to needed fieldsFrequently 50%+
  • Compress text: Brotli level 11 for static assets at build time, a lower level for dynamic responses where CPU matters.
  • Do not compress already-compressed formats — images, video, .woff2. It costs CPU and saves nothing.
  • Compression on responses that reflect user input can leak secrets by size (BREACH). Do not compress a response containing a secret alongside attacker-controlled content. → Security/headers
  • API payload size is a real cost on mobile: return the fields the client needs, paginate, and avoid deeply nested expansions nobody reads. → API/pagination

#Cache to avoid the request entirely

The fastest request is the one not made.

arduino
Cache-Control: public, max-age=31536000, immutable      # content-hashed assets
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400
Cache-Control: private, no-store                        # authenticated
  • Content-hash asset filenames so they can be cached for a year and a deploy changes the URL.
  • ETag/If-None-Match turns a repeat request into a 304 with no body — still a round trip, so it is second-best to a cache hit.
  • stale-while-revalidate serves instantly from cache and refreshes in the background.
  • Never cache an authenticated response in a shared cache.Performance/caching

#Move bytes closer

  • A CDN turns a 150 ms origin round trip into a 15 ms edge round trip. It is the highest-leverage change available for a geographically distributed audience.
  • Ensure a high cache hit ratio at the edge — a CDN that proxies every request to the origin adds a hop and helps nothing.
  • Co-locate compute with data. An edge function querying a database in another region pays that latency on every query, which usually cancels the benefit of being at the edge. → DevOps/vercel
  • For chatty internal services, latency multiplies: a request that makes twenty sequential internal calls at 2 ms each is 40 ms of pure network. Batch, or co-locate.

#Anti-patterns

Anti-patternWhy it failsFix
Optimising bandwidth, ignoring latencyRound trips dominateReduce round trips
Many third-party originsFull connection setup eachConsolidate; preconnect
preconnect to everythingOpen connections competeOnly definite origins
Sequential dependent requestsWaterfallParallelise; send data with the document
Client fetching config before dataAn extra round trip before anythingInline it in the response
Preloading everythingCompetes with render-blocking resourcesPreload deliberately
HTTP/1.1 with many small assetsSix-connection limit, head-of-line blockingHTTP/2 or HTTP/3
keepAliveTimeout below the LB'sIntermittent 502sSet it higher
No compression on textMultiples of the necessary bytesBrotli/gzip
Compressing images and fontsCPU cost, no savingSkip already-compressed types
Compressing secrets with reflected inputBREACH-style size oracleDo not compress those responses
Returning full entities from APIsPayload dominated by unused fieldsProject fields
No content hashing on assetsCannot cache long; deploys serve staleHash filenames
Caching authenticated responsesCross-user data exposureprivate, no-store
CDN with a low hit ratioAdds a hop, saves nothingFix the cache rules
Edge compute far from the dataPer-query latency cancels the gainCo-locate
Chatty internal callsLatency multipliesBatch or co-locate

#Checklist

  • Verify: Performance work targets round trips before bandwidth
  • Verify: Third-party origins are minimised and critical ones are preconnected
  • Verify: No request waterfall exists on the critical path
  • Verify: Independent requests are issued in parallel on client and server
  • Verify: Data needed for first render arrives with the document
  • Verify: Preloading is deliberate and limited to render-critical resources
  • Verify: HTTP/2 or HTTP/3 is enabled
  • Verify: Server keep-alive exceeds the load balancer idle timeout
  • Verify: Text responses are compressed with Brotli or gzip
  • Verify: Already-compressed formats are not re-compressed
  • Verify: Responses mixing secrets and reflected input are not compressed
  • Verify: API responses return only required fields and paginate
  • Verify: Static assets are content-hashed and cached immutably
  • Verify: stale-while-revalidate is used for cacheable dynamic content
  • Verify: Authenticated responses are never in a shared cache
  • Verify: A CDN serves static assets with a monitored hit ratio
  • Verify: Compute is co-located with the data it queries
  • Verify: Internal service calls are batched rather than sequential