Assuming that you're really talking a data pipeline, if you gzip sooner rather than later, the rest of the path just gets to move the more compact data around.
If you gzip at both places, the later point should see that the traffic is already compressed and not do it again.
But if you have compression turned on at both places, but they're not using the same compression, the latter point might not recognize the other algorithm, and so try to compress with the new algorithm. This usually costs more time, because compressed data is usually not as compressible as uncompressed data and the extra compression yields little if any benefit (and can make things worse.) Also, many clients aren't expecting doubly-compressed results, and may just undo the second layer of compression rather than both.
Also, if your frontend server is looking at the content provided by the content server and tweaking it, then it's going to need to decompress anything that the content server sends it compressed. There are compression algorithms for this sort of use case, like LZO compression. I have not really looked into these algorithms, as I mostly compress data at rest and data moving from across two or more timezones.
Just to be clear on that additional case: if the content provided by the content server is passed on to the client as distinct files from anything the frontend is providing, it probably doesn't matter to the frontend server if that data is already compressed. If, on the other hand, you're prepending a beginning of a webpage, and then adding after it the end of a web page, then having the stuff that goes between that beginning and that end separately compressed just doesn't work. I hadn't considered this case, because I assumed that you were asking about two cases that you had working code to handle, but couldn't figure out how to benchmark since you're at your site and the client isn't.