直接请求API与JS请求API时延差异显著（前者耗时约为后者一半）的原因及相关TTFB指标咨询

Great questions—let’s break them down clearly, since these are common pitfalls when working with browser-based API calls.

1. Why Direct API Requests Take Half the Time of JavaScript Requests? #

The significant latency difference usually boils down to a few key browser/network behaviors that differ between direct requests (like address bar, curl, or Postman) and JavaScript-initiated calls (XHR/fetch):

• Cross-Origin Preflight Overhead: If your JS request is cross-domain, browsers automatically send an OPTIONS preflight request first to check if the server allows the actual request. This adds a full round-trip to the total latency—so if the direct request is same-origin (no preflight), it’ll cut the time roughly in half right there. Direct tools like curl don’t enforce CORS, so they skip this step entirely.
• Request Priority & Browser Throttling: Browsers assign different priorities to requests. Navigation requests (address bar) get top priority, while JS-initiated XHR/fetch calls are often lower priority—especially if the page is still loading other resources (like images, CSS, or scripts). The browser might delay your JS request to prioritize critical page content, adding extra latency.
• Cache Mismatches: Direct requests might hit browser or intermediate caches that your JS calls aren’t using. For example, if you’ve previously accessed the API via the address bar, the browser might return a cached response instantly. JS calls sometimes bypass cache by default (depending on Cache-Control headers or request configuration) or use a different cache context, forcing a full network round-trip.
• Extra Headers/Cookie Overhead: JS requests automatically include all cookies and custom headers tied to the domain, which can bloat the request size. Direct requests might not send these (if you don’t explicitly add them), reducing data transfer time and server processing overhead.
• Connection Reuse: Direct tools often reuse existing HTTP/2 or HTTP/1.1 keep-alive connections more aggressively. In a browser, JS calls might have to establish a new connection if the existing pool is exhausted or the connection was closed after idle time, adding TCP handshake/TLS negotiation time.

2. Does the Estimated Time for JS Screenshot Requests Correlate with TTFB? #

This depends on how you’re initiating the request and measuring time:

For XHR/Fetch Requests #

If you’re using XMLHttpRequest or fetch to load the screenshot, the time from when you send the request to when the first byte of the response is received is exactly TTFB. You can measure this directly in code:

// Example with fetch
const startTime = performance.now();
fetch('/api/screenshot')
  .then(response => {
    const ttfbEstimate = performance.now() - startTime;
    console.log(`TTFB Estimate: ${ttfbEstimate}ms`);
    // For precise TTFB, use the Performance API
    const resourceEntry = performance.getEntriesByType('resource').find(entry => entry.url.includes('/api/screenshot'));
    if (resourceEntry) {
      const preciseTTFB = resourceEntry.responseStart - resourceEntry.requestStart;
      console.log(`Precise TTFB: ${preciseTTFB}ms`);
    }
  });

Just make sure you’re not measuring total request time (which includes downloading the entire screenshot file)—TTFB only covers up to the first byte of the response.

For Document-Type Requests #

If you’re loading the screenshot via a document context (e.g., <img> tag, location.href, or window.open()), the TTFB is still the time from request start to first byte, but measuring it in JS requires using the Browser Performance API:

// For an <img> tag loading the screenshot
const img = new Image();
img.src = '/api/screenshot';
img.onload = () => {
  const resourceEntry = performance.getEntriesByType('resource').find(entry => entry.url === img.src);
  if (resourceEntry) {
    const ttfb = resourceEntry.responseStart - resourceEntry.requestStart;
    console.log(`Screenshot TTFB: ${ttfb}ms`);
  }
};

If you’re using a navigation-based request (like location.href to download the screenshot), you won’t be able to measure TTFB in the current page’s JS context (since the page will unload), but you can view it directly in the browser’s DevTools Network tab under the TTFB column for that request.

内容的提问来源于stack exchange，提问作者wymli