tests(smokehouse): gzip test to assert transfer and resource sizes #7286
Conversation
connorjclark
requested review from
brendankenny and
patrickhulce
as code owners
| }, | ||
| { | ||
| url: 'http://localhost:10200/byte-efficiency/script.js?gzip=1', | ||
| transferSize: 1136, |
There was a problem hiding this comment.
are these stable across platforms, like the native zlib mac/linux is the same byte-for-byte as js and transfer size is always the same and all that?
seems like we could loosen the assertion a bit
There was a problem hiding this comment.
Good question, no idea. For the purposes of the regression a ballpark is good enough (less than 1500 i guess).
Looks like travis / appveyor got the same thing I did.
This SO answer perhaps suggests that we can rely on zlib being the same? Interestingly there's a byte that represents the OS used, but that wouldn't change the length. You've got me curious now so I'm gonna dig in way deeper than necessary :P
There was a problem hiding this comment.
Any findings from the 🐰 🕳 ?
There was a problem hiding this comment.
Just that it may change when Node upgrades zlib, but they haven't update it in years. Seems fine to punt.
| resourceSize: 52997, | ||
| }, | ||
| { | ||
| url: 'http://localhost:10200/byte-efficiency/script.js', |
There was a problem hiding this comment.
is this is just for exact comparison with the gzip?
There was a problem hiding this comment.
Just the ?gzip=1 one is important for the regression test. This is just for comparing. And maybe it'd catch some other future issue? I'm open to removing.
| }, | ||
| { | ||
| url: 'http://localhost:10200/byte-efficiency/script.js?gzip=1', | ||
| transferSize: 1136, |
There was a problem hiding this comment.
Any findings from the 🐰 🕳 ?
| @@ -71,6 +72,7 @@ function requestHandler(request, response) { | |||
| } | |||
|
|
|||
| let delay = 0; | |||
| let gzip = false; | |||
| response.writeHead(statusCode, headers); | ||
|
|
||
| // Delay the response | ||
| if (delay > 0) { | ||
| return setTimeout(finishResponse, delay, data); | ||
| } | ||
|
|
||
| finishResponse(data); | ||
| finishResponse(data, gzip); |
There was a problem hiding this comment.
if passing it this way, would need to pass into the delay path above as well (to getdelay and gzip to work together).
Could also doing the gzip encoding when doing the header? e.g.
if (gzip) {
headers['Content-Encoding'] = 'gzip';
data = zlib.gzipSync(data);
}
response.writeHead(statusCode, headers);
// ...
Assert that gzip savings are correctly being provided by the browser for LH to use.
Regression test for when a version of headless Chrome was giving weird
dataReceivedEventvalues in the face of gzipped resources (see this doc (private to Googlers) for more).Related: #7284