( persicsb | 2017. 09. 18., h – 10:28 )

Miben kis erőforráső a kontroller? CPU teljesítményben? RAM-ban. Ez a két dolog egymásra ortogonális.

"Minimalizálom az elküldött tartalmat, azaz a statikus tartalmakat gzip-el tömörítve küldöm el."
gzip tömörítés az a memória/sávszélesség problémát oldja meg, CPU teljesítmény kárára. Azaz ha a CPU teljesítmény a szűk keresztmetszet, ezzel rontasz a teljesítményen.

"2 - Megkérem a klienst, hogy csak a dinamikus tartalmakat kérje le újra, így a képeket, statikus fájlokat csak egyszer töltené le."
Ez sima HTTP cache headerekkel megoldható.

"Vagy van valamilyen más header, amivel jelezni tudom a kliens felé, hogy tömörítve küldöm az adatot?"
A Content-Encoding: gzip az önmagában nem elég. Csak akkor használhatod, hogy a kliens a kérésben jelezte, hogy be tudja azt fogadni. A kérésben lévő Accept-Encoding header tartalmazza, hogy milyen forráskódolást támogat a kliens, lehet, hogy gzip-et nem, de deflate-t igen. " de a kérelem header értelmezése, és a különböző esetek kezelése is erőforrást igényel." Már pedig ha nem támogatja a gzip-et a kliens, akkor hiába küldesz neki gzipet. Fel KELL dolgoznod az Accept-Encoding headert.

"A statikus tartalmak mellé elküldöm a "Cache-Control: max-age=300, public""
5 perc nem igazán érdekes cache-control max-age érték. Adj meg jóval nagyobbat.

A statikus tartalmakat kiszervezheted teljesen külön kiszolgálóra is.

Másrészt: a HTTP az egy nagy erőforrás-igényű protokoll, szöveget kell parzolni állandóan hozzá. Ez drága dolog.
Mit akarsz pontosan megcsinálni? Mindenképpen HTTP és web kell neked?