| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Please set a semver versioning label of either major, minor, or patch on this pull request. |
Sorry, something went wrong.
|
@tiagoad sorry for the direct ping. I wanted to follow up on this PR since it's been open for a while. Is there anything I should update or any requirements I might have missed to get it reviewed/merged? |
Sorry, something went wrong.
There was a problem hiding this comment.
@dmeremyanin Hey, thanks for this. Could you rebase onto current main?
Sorry, something went wrong.
There was a problem hiding this comment.
Hey, couple of things:
something like this should work:
.then(r =>
r.blob().then(blob => {
if (this.#responseHook) {
return blob.text().then(body => {
this.#responseHook({ url, headers: r.headers, body });
return blob;
});
}
return blob;
})
)The key difference is return blob.text().then(...) — returning the promise so the chain waits for the hook to finish before continuing to the timing calculation.
That detached promise also has no .catch() — errors get swallowed silently.
Minor: #responseHook defaults to r => r, not null, so the if guard is always true. blob.text() runs every time regardless.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
I noticed that download speeds were significantly slower than expected (and much slower than upload speeds) when testing against a local Go-based backend.
It turns out response.text() creates significant backpressure. Because JS handles the text chunks slower than the network can deliver them, it throttles the actual TCP connection. Using response.blob().text() avoids JS backpressure and results in a more accurate network speed measurement.
In local tests, the difference is substantial – around a 9-10x improvement. Below is a simple benchmark run in Chrome on a MacBook M4 Pro downloading a 100MB payload:
