Do you have a problem? If your answer is no, don’t do it.
I gave this specific example with the feed a try and enabling compression reduced the response from more than 300kB to less than 30kB. That is quite significant, and makes sense since in case of grids, with items that have the same structure, there is a lot of repeating stuff being sent. With other types of UI there will probably not be as much repetition, but I would assume it still helps a lot.
Without having thought about this previously, to me it seemed common sense that you would enable this at some level, either in the app or reverse proxy, for Vaadin RPC calls. Taking a quick glance at other apps such as Github or this very forum, they do compress their API calls. Then again, you might want to do tests of your own and decide for yourself if it improves performance. For Vaadin this could also be a good topic for a blog post, or part of our Vaadin way documentation.
The downside of compression is of course the need to decompress the data at the other end, which takes some amount of processing power. So there’s a risk that especially lower-end devices will perform worse with compression enabled. Is the extra CPU cost going to be worth it? If you know the network is the bottleneck in your use cases, possibly. But you’ll only know for sure if you test, with your application, with real(istic) end user devices, in real(istic) network conditions.
My understanding is that especially decompressing is so light on the CPU that the overhead is often offset by having to spend less CPU time on getting those bytes through the network stack and sending ACKs and also less battery on powering radios for wireless communication.
3 Likes