Gzip support in serverless functions

I was curious why the edge functions support gzip automatically but the lamda serverless functions do not. Is my only option is to gzip the response?

Hiya @struckm and thanks for asking over here - I was the one who suggested we couldn’t usefully address it in depth over twitter yesterday.

What I can see from the two URL’s you linked yesterday is that both returned compressed content to my chrome:

  1. https://golf-functions.markstruck.com/.netlify/functions/users seemed to return an content-encoding: br for me when sent accept-encoding: gzip, deflate, br by Chrome.
  2. https://www.markstruck.com/edge/users seemed to return an content-encoding: gzip for me when sent accept-encoding: gzip, deflate, br by Chrome.

Our individual CDN nodes do each have their own cache for static files, and can respond differently in this situation: Since Chrome professed ability to handle “any” compression type, if there is already some compressed response in cache using one of those types, we would return it (so two nodes who had previously received Accept-Encoding: gz and Accept-Encoding: br would have different things in cache and would serve those different things in this made-up scenario); if nothing compressed is cached, we’ll have to request and cache an asset in some format and return it. For proxy’d results including lambdas, everything is different as I explain below.

Still, that shouldn’t prevent us from returning a compressed response should the site config allow it. I wonder if you added compression to your lambda function, since I can see it now? I wouldn’t think we’d change compression types there, if for no other reason than we “proxy to” your function and we try not to transform that output at all (faithfully relaying the browser request to your remote service - in this case a lambda function - and then faithfully relaying its response without substantial change to the browser). However, for an edge function, we’ll serve the underlying asset using our CDN’s usual automatic compression, which I think is what is happening for the EF at least; if we’d serve the underlying request with some response - such as automatic compression - we’d serve the EF response with such. But of course you can manipulate HTTP response headers in an EF so without knowing what your code does, it’s hard to reason about it directly.

I was using Postman to test, I wasn’t using the browser as the edge function was returning a favicon.ico as part of the response. I wanted to test the functions as if they were going to be called in JS. The browser payload is smaller than what I’m seeing in Postman, i.e. 1.2kb vs 6.37kb. I’ll have to look into that. Thanks for the response.

1 Like