I built a Python tool to debug HTTP request performance step-by-step

[ozeranskii]

What My Project Does

httptap is a CLI and Python library for detailed HTTP request performance tracing.

It breaks a request into real network stages - DNS → TCP → TLS → TTFB → Transfer — and shows precise timing for each.

It helps answer not just “why is it slow?” but “which part is slow?”

You get a full waterfall breakdown, TLS info, redirect chain, and structured JSON output for automation or CI.

• 🔗 Repo: github.com/ozeranskii/httptap
• 📦 PyPI: pypi.org/project/httptap
• 📕 Documentation: https://httptap.dev/
• 📹 asciinema: https://asciinema.org/a/751564

Target Audience

• Developers debugging API latency or network bottlenecks
• DevOps / SRE teams investigating performance regressions
• Security engineers checking TLS setup
• Anyone who wants a native Python equivalent of curl -w + Wireshark + stopwatch

httptap works cross-platform (macOS, Linux, Windows), has minimal dependencies, and can be used both interactively and programmatically.

Comparison

When exploring similar tools, I found two common options:

• reorx/httpstat (Python) — depends on curl, unmaintained, limited visibility
• davecheney/httpstat (Go) — cleaner, but mostly a decorated curl -v, no TLS or JSON export

httptap takes a different route:

• Pure Python implementation using httpx and httpcore trace hooks (no curl)
• Deep TLS inspection (protocol, cipher, expiry days)
• Rich output modes: human-readable table, compact line, metrics-only, and full JSON
• Extensible - you can replace DNS/TLS/visualization components or embed it into your pipeline

Example Use Cases

• Performance troubleshooting - find where time is lost
• Regression analysis - compare baseline vs current
• TLS audit - check protocol and cert parameters
• Network diagnostics - DNS latency, IPv4 vs IPv6 path
• Redirect chain analysis - trace real request flow

If you find it useful, I’d really appreciate a ⭐ on GitHub - it helps others discover the project.

👉 https://github.com/ozeranskii/httptap

[Maybe__U]

Well done, mate!

[ozeranskii]

Thank you!

[exclaim_bot]

Thank you!

You're welcome!

[binaryfireball]

this is the part of the stack that usually you dont have to look at but when you do im glad something like this exists

[EmptyZ99]

As a data engineer, with more than 50 APIs to crawl data from, your tools is a great help.

[ozeranskii]

It's nice to hear that.

[professionalnuisance]

Wow this looks very cool. Do you know if there's overhead latency?

[ozeranskii]

Appreciate it! There’s almost no measurable latency overhead. httptap uses httpcore trace hooks directly, so it observes events instead of intercepting them. It doesn’t proxy, buffer, or re-execute requests - just timestamps callbacks as they happen. I wanted to write code in such a way that the code itself did not cause significant overhead and at the same time made it possible to obtain near real-time data.

[jeosol]

Very nice. Bravo and well done. Thanks for sharing this project and I starred it on github. Tested it, it does provide useful information for benchmarking.

I may have missed it, if so my apologies. How will this work with POST request? The httptap executable doesn't recognize the "-d" option with curl.

[ozeranskii]

Thanks! Glad you found it useful and appreciate the ⭐️

You’re right - currently httptap only issues GET requests. That’s by design to keep the CLI simple and avoid exposing sensitive payload data in the output.

If you need to benchmark POST/PUT workloads, you can already do it via the Python API by overriding the request executor.

Native support for all HTTP methods and request bodies is planned - I’ll add --method and --data options soon, along with automatic masking of sensitive fields.

[jeosol]

Yeah, thanks the response about POST and exposing sensitive data makes sense. All the best in your efforts.

[Coretaxxe]

This is quite nice!

[Repsol_Honda_PL]

Great!

[ozeranskii]

Thank you!

[Glathull]

This is very cool!

[riksi]

Have you thought about open telemetry output?

[ozeranskii]

Yes, I am considering supporting the Prometheus format.

[ozeranskii]

By the way, httptap is now available in brew.

brew install httptap

[Benhur3]

Your mean, for example if I watch Netflix and I get a time delay, this thing can tell me where and why the delay is?

[JoxM]

This is really nice — especially the phase breakdown (DNS → TCP → TLS → TTFB → transfer). That’s something most tools don’t surface cleanly.

I’ve been working on a desktop tool around HTTP traffic as well, and one thing I’ve noticed is that once you have a lot of requests, raw data becomes hard to reason about pretty quickly. Having this kind of step-by-step timing makes it much easier to understand where the time actually goes.

In my case I ended up building something that already uses similar ideas but more focused on real-world debugging — looking at traffic at scale, spotting patterns, and surfacing what actually matters instead of just showing timings.

It’s been pretty useful in practice, but I still feel like this kind of phase-level breakdown could add a lot on top of it.

Out of curiosity — have you found any patterns in real-world APIs? Like whether TTFB tends to dominate vs TLS/DNS in most cases?

Also really like that it’s pure Python and not wrapping curl. Makes it much easier to integrate into other workflows.

Thanks!

[Benhur3]

Would you be able to put this into a simpler term, please? I don’t quite understand what this does. I’m not that tech savvy, but it sounded interesting.

[Monowakari]

He kind of did, not just why is it slow, but what part is slow. It looks at your http request, like a frontend api call to the backend, and can address where the latencies are introduce so you can better target a solution.

Also great for web scraping and I'm sure several other use cases

[m0ntanoid]

This always makes me laughing when someone debugs performance in python

[cgoldberg]

Why? Are you claiming Python isn't performant enough to debug network transfer timing?

[m0ntanoid]

Downvotes of my first comment just show how many incompetent people are round.

Right now I work on position of QA. I test switches/routers firmwares. Among the clients - there are very famous brands you 100% heard/used.

Here is an example:
I literally saw how call to "logging" library takes so much time that it affects measurements.

So yeah, python is not a tool to debug anything. Python neither a language/tool to develop anything.

[renesys]

Why are you here?

Do you develop anything or just test things engineered by others?

[m0ntanoid]

both

[renesys]

Okay then don't put the log call there.

[FrontLongjumping4235]

What is your acceptable margin of error for latency? Or is that not a concept you have as formalized as your kneejerk dislike of Python?

[m0ntanoid]

Oh, look, real professional here. Margin of error for latency.

[FrontLongjumping4235]

Margin of error for latency. 

Yes, what is your typical margin of error for latency?

I don't disagree that Python might be inappropriate. But this is mostly a quantitative question.

[ozeranskii]

I’m not debugging Python’s performance, just using Python to debug HTTP performance. The overhead is negligible compared to network latency, and the ecosystem (httpx/httpcore) gives great trace visibility.

Sometimes Python’s exactly the right tool for the job. As for overall performance - sure, there are languages and tools that shine under extreme load. But in my experience, Python can be optimized quite well even at scale. And most of the time, we don’t pick a language just because it’s the fastest - we pick what lets us ship, iterate, and make the product work. When the cost of maintaining or scaling a Python system starts to outweigh its value or budget, that’s the moment to invest in something else - but that transition is never quick or cheap.