API Latency Monitor

Always-on monitor that measures latency of all API/network calls and rates them as Good, Average, or Poor.

═══════════════════════════════════════════════════════════════ PART 1 — DETAILED DESCRIPTION (paste into the store listing) ═══════════════════════════════════════════════════════════════ See exactly how fast every API call on your page really is — and where the time actually goes. API Latency Monitor watches every network request your browser makes, measures how long each one takes, and rates it Good, Average, or Poor so you can spot a slow endpoint at a glance. No DevTools to open, no recording to start, no waiting. It runs quietly from the moment Chrome opens. Built for developers, QA engineers, and anyone who has ever asked "why is this page so slow?" and wanted an answer in seconds rather than a scavenger hunt through the Network tab. WHY THIS EXISTS The DevTools Network tab is powerful, but it only helps if you remembered to open it before the slow request happened. If you didn't, you reload and hope it reproduces. And when you finally catch it, you still have to work out whether the delay was DNS, the TLS handshake, or your backend chewing on the request. API Latency Monitor flips that around. It's always recording, so the data is already there when you go looking. And it doesn't just tell you a call took 1.8 seconds — it tells you that 1.7 of those seconds were the server thinking, which means the problem is your backend, not the network. WHAT IT DOES ALWAYS ON, ZERO SETUP Starts monitoring the instant Chrome launches. There is no record button, no "start capturing" step, and nothing to remember. If a request was slow, it's already in the log. INSTANT GOOD / AVERAGE / POOR VERDICT Every call is rated against latency thresholds you control: • Good — 300 ms or less • Average — up to 1000 ms • Poor — over 1000 ms Failed requests are always counted as Poor. Adjust the thresholds in Settings to match what "fast" means for your own API. THE TOOLBAR TELLS YOU BEFORE YOU EVEN CLICK The extension badge shows a green "OK" while everything on the current page is healthy, or a red count of poor requests when something is dragging. You'll notice a regression without opening anything. FULL TIMING BREAKDOWN PER REQUEST This is the part that actually saves you time. Expand any request and you get a waterfall showing where every millisecond went: • Stalled / queued — waiting before the connection work even begins • Redirect — time lost following redirects • DNS lookup — resolving the hostname • TCP connect — establishing the connection • TLS handshake — negotiating HTTPS • Waiting (TTFB) — request sent to first byte back. This is your server's real processing time. • Content download — first byte to last byte Once you can see the split, diagnosis becomes obvious. TTFB dominating? Your backend is slow — go look at the endpoint. DNS and TLS eating the budget? It's connection setup, usually a cold connection rather than a slow API. Download dragging? You're shipping too many bytes. Each row also shows a compact color-coded phase strip inline, so you can often spot the culprit without expanding anything at all. COMPLETE REQUEST DETAILS Alongside the timing you get everything you'd normally dig through DevTools for: HTTP protocol (h2, h3, http/1.1), remote IP address, status line, transferred size versus decoded size, Content-Type, Server, Cache-Control, cache status, full request and response headers, and the request body. COPY AS cURL One click copies any request as a complete, runnable curl command — method, headers, and body included, correctly quoted. Paste it into a terminal, hand it to a teammate, or drop it in a bug report. Reproducing an API call stops being a chore. RESEND ANY REQUEST Replay any captured call with one click and see the new status and latency appear right on the button, color-coded. Because the replay runs from the extension's background worker rather than the page, it isn't blocked by CORS — and it flows back through the same measurement pipeline, so it gets timed and rated like any other request. Perfect for checking whether that slow call was a one-off or a real pattern. PER-DOMAIN ANALYSIS A second tab aggregates every domain the page talked to: request count, average latency, worst latency, failure count, and a good/average/poor ratio bar. Sorted slowest-first, so your problem services float straight to the top. When a page feels slow, this view usually names the culprit immediately. AUTOMATIC RESET ON EVERY PAGE LOAD Data is scoped per tab, and each tab's data is wiped automatically when it reloads or navigates to a new URL. The numbers you're looking at always describe the page in front of you — never a stale mix of everything you've browsed today. Other tabs keep their own separate data, so measuring one page never destroys what you're collecting in another. FLOATING OVERLAY THAT STAYS OPEN Chrome closes extension popups the moment you click away, which makes them useless for watching traffic while you actually use your app. So there's a floating overlay panel you can drop straight onto the page (button in the header, or Alt+Shift+L): • A real transparency slider from 20% to 100% — you genuinely see the page through it • Click-through mode, so clicks pass to the page underneath and the panel can hover over your app without getting in the way • Drag it anywhere; it remembers its position, opacity, and open state across page loads • Live stats, the request feed, phase strips, and copy-as-cURL, all without leaving your app DETACHED POP-OUT WINDOW Prefer a separate window? One click pops the full interface out into its own window that stays open while you click anywhere else, and follows whichever tab you're currently working in. FILTER AND SEARCH Filter the request feed by URL or domain text, or narrow it to just the poor calls, just the failures, or any other rating. Cut through a noisy page in seconds. TYPICAL USES • Find out which API endpoint is making your app feel sluggish • Prove whether a slowdown is backend processing (TTFB) or network overhead (DNS/TLS) • Catch failing and timing-out requests you'd otherwise never notice • Grab a curl command for any request to reproduce a bug or share with a teammate • Keep an eye on latency while you click through a QA pass, using the transparent overlay • Compare third-party services and spot the slow ones dragging your page down • Sanity-check that your CDN, cache headers, and HTTP/2 or HTTP/3 are actually doing their job PRIVACY — YOUR DATA NEVER LEAVES YOUR BROWSER This matters, so it's stated plainly: • No data is transmitted anywhere. Ever. There is no server, no analytics, no telemetry, no tracking. • Everything is stored locally in your own browser, using Chrome's local storage. • Nothing is sold, shared, or sent to us or to any third party. • Data for a tab is deleted automatically when the tab reloads, navigates, or closes. • There are no accounts, no sign-up, and no external network calls of any kind — except the requests you explicitly choose to replay with the Resend button, which go to the same destination the original request did. The extension needs access to page network activity because measuring network activity is literally what it does. That access is used for nothing else. A NOTE ON CROSS-ORIGIN TIMING (HONEST LIMITATION) Browsers deliberately hide DNS, TCP, and TLS timing for cross-origin resources unless the server sends a Timing-Allow-Origin header. This is a browser security rule that applies to every tool, including DevTools — it isn't a limitation of this extension. When that happens, the panel tells you so explicitly rather than showing a misleading "0 ms". You still get the total latency, the rating, and the download phase for those requests. If you want the full breakdown for your own APIs, add this response header: Timing-Allow-Origin: * Worth doing, since your own endpoints are exactly where the detail is most useful. GETTING STARTED Install the extension. Pin it to your toolbar (click the puzzle-piece icon, then the pin). Open any website. That's it — it's already measuring. Click the icon to see rated requests, or press Alt+Shift+L for the floating overlay. FEEDBACK Found a bug, or want a feature? Reviews and feedback are read and acted on. Ideas already on the list: SPA route-change resets, response body capture, export to HAR, and per-endpoint historical trends. ═══════════════════════════════════════════════════════════════ PART 2 — NOT FOR THE DESCRIPTION FIELD Notes for the Chrome Web Store submission form and review ═══════════════════════════════════════════════════════════════ SHORT DESCRIPTION (132 character limit — separate field) Option A (127 chars): Measure the latency of every API call, rate it Good/Average/Poor, and see the exact DNS, TLS, and server-time breakdown. Option B (131 chars): Always-on network latency monitor. Rates every API call Good/Average/Poor, shows DNS/TCP/TLS/TTFB breakdown, copies as cURL. SINGLE PURPOSE STATEMENT Chrome requires one clear purpose. Use: "Measuring and analyzing the latency of network requests made by web pages." Every feature (ratings, timing breakdown, cURL export, resend, overlay) serves that single purpose. PERMISSION JUSTIFICATIONS (each field must be filled in, or you get rejected) webRequest — Required to observe network requests and record their start and completion timestamps, which is how latency is measured. This is the core function of the extension. host_permissions <all_urls> — The extension must be able to measure requests on whatever site the user is currently working on. Restricting to specific domains would defeat the purpose, since a developer needs it on their own local, staging, and production sites without reconfiguring it. storage — Stores measured latency data and the user's threshold and overlay preferences locally in the browser. Nothing is transmitted. tabs — Data is scoped per tab so that one tab's measurements do not contaminate another's, and so data is cleared when a tab reloads or closes. The tab ID is used for this scoping only. clipboardWrite — Used by the "Copy as cURL" button to place the generated curl command on the user's clipboard. alarms — Used for periodic internal flushing of collected data to local storage. Content scripts — Required to read the Resource Timing API, which is the only source of DNS, TCP, TLS, and TTFB phase data. This information is not available to the webRequest API and cannot be obtained any other way. Remote code — Answer "No, I am not using remote code." All code is bundled in the package. DATA USE DISCLOSURES (the checkbox section) You will be asked what data you collect. Truthfully, this extension collects "Website content" (request URLs and headers) but processes it entirely locally. Certify all three: • Data is not being sold to third parties • Data is not being used or transferred for purposes unrelated to the item's single purpose • Data is not being used or transferred to determine creditworthiness or for lending A privacy policy URL is required. A short page stating "This extension processes all data locally within the user's browser and transmits no data to any server" is sufficient. A public GitHub repo README or a GitHub Pages page works fine as the hosted URL. REVIEW EXPECTATIONS Extensions requesting <all_urls> plus webRequest usually get a slower manual review — expect a few days rather than a few hours. Make sure your screenshots visibly demonstrate the latency measurement, since a reviewer who can't see why you need the permissions is more likely to reject. SCREENSHOT SUGGESTIONS (1280x800, you need at least one, up to five) The popup on a real site, showing the rated request list with green/amber/red badges An expanded request showing the timing waterfall — this is your strongest differentiator, lead with it The "By domain" tab, sorted slowest-first The transparent overlay floating over a live web app The Copy-as-cURL button mid-action, or the Settings threshold controls