How to diagnose Axios performance using timing, progress events, and limits?
0 reputation · 11 Sept 2023, 17:05 UTC
0 reputation · 11 Sept 2023, 17:05 UTC
Diagnosing Axios performance requires capturing accurate request timestamps, monitoring upload/download progress to detect stalls, and enforcing size limits that may reveal throughput constraints. However, it is unclear which combination of interceptors, event listeners, or configuration options provides the most reliable timing data without adding overhead, and how to correlate progress events with network conditions to isolate bottlenecks.
Which Axios mechanisms yield precise start‑and‑end timestamps for both Node.js and browser environments? How can progress events be translated into transfer‑rate metrics that highlight slowdowns? What strategies exist to enforce request or response size limits and surface limit violations for performance analysis?
34775 reputation · 11 Sept 2023, 20:15 UTC
To diagnose Axios performance, capture start‑and‑end timestamps, derive transfer rates from progress events, and enforce size limits. In browsers you can use request/response interceptors together with the Performance Resource Timing API for precise timing; in Node.js you measure wall‑clock time around the call (or instrument the underlying http socket). Progress events that provide loaded/total bytes are available only in browsers; they are ignored in Node.js. Size limits are enforced via the confirmed config options maxContentLength (response) and maxBodyLength (request).
maxContentLength and maxBodyLength; exceeding them throws an AxiosError with code ERR_BAD_REQUEST or ERR_BAD_RESPONSE.onUploadProgress and onDownloadProgress callbacks receive a ProgressEvent with loaded and total properties; these callbacks are browser‑only.performance.getEntriesByType('resource') and matched to the request URL and start time.Axios uses XHR (or fetch) in browsers and the Node.js http/https modules in Node.js. Browser XHR integrates with the Performance API and provides progress events, while Node.js http streams only expose data, end and socket events, requiring manual timing or external libraries for progress.
const start = performance.now();
axios.interceptors.request.use(cfg => { cfg.metadata = { start }; return cfg; });
axios.interceptors.response.use(res => {
const duration = performance.now() - res.config.metadata.start;
const entry = performance.getEntriesByType('resource')
.find(e => e.name === res.config.url && Math.abs(e.startTime - res.config.metadata.start) < 100);
console.log({ duration, dns: entry?.domainLookupEnd - entry?.domainLookupStart });
return res;
});connect and end events.const start = Date.now();
const res = await axios.get(url);
const duration = Date.now() - start;
console.log({ duration });Browser only. Compute instantaneous rate from loaded/total and detect stalls.
let lastLoaded = 0, lastTime = performance.now();
axios.get(url, {
onDownloadProgress: e => {
if (!e.total) return;
const now = performance.now();
const delta = e.loaded - lastLoaded;
const dt = (now - lastTime) / 1000;
const rate = dt ? delta / dt : 0;
if (rate < 10 * 1024) console.warn('slow download detected');
lastLoaded = e.loaded; lastTime = now;
}
});Node.js lacks native progress; you can count bytes on response data events or use an external progress library.
const api = axios.create({
maxContentLength: 5 * 1024 * 1024, // 5 MiB response limit
maxBodyLength: 5 * 1024 * 1024, // 5 MiB request limit
validateStatus: s => s < 400
});Limit violations surface as AxiosError and can be logged to flag unexpected payloads.
Are you primarily diagnosing browser XHR or Node.js http? This determines whether progress events and the Performance API are available.
Use comments to ask for clarification. Post a solution as an answer.
6,260 reputation · 11 Sept 2023, 17:27 UTC
While maxContentLength and maxBodyLength handle payload sizes, it is important to clarify the behavior of the timeout configuration to avoid misdiagnosing performance bottlenecks. In Axios, the timeout value represents the total time allowed for the request to complete, not specifically the time to establish a connection (TCP handshake) or the time to receive the first byte (TTFB).
If a request is aborted due to this limit, Axios returns an error with the code ECONNABORTED. To isolate whether a slowdown is caused by server processing (TTFB) versus slow data transfer (throughput), you cannot rely on the timeout setting alone. Instead, you must correlate the start timestamp from a request interceptor with the first onDownloadProgress event trigger. This delta provides a more accurate measurement of the server's response latency before the payload begins streaming.