HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論，無論是 HTTP/1.1 時代，或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push)，各種讓下載速度最佳化的技巧以及造成的複雜度：「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧，也就是 JavaScript 的 bundle，或是 CSS 的 Image sprites，甚至是 API 的合併，像是很多人會考慮的 GraphQL。

雖然在 HTTP/2 年代我們常說可以省下來，但這並不代表「打包」在 HTTP/2 情境下沒有效果，只是改善的幅度比較少，所以這個最佳化的技巧比起 HTTP/1.1 年代，可以放到後面一點再做，先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了)，其實繼續使用沒有太大問題...

另外是 Server Push 的情境，意外的反而可以提昇不少速度，看起來主要是少了請求的時間，所以快不少。

再來是跨網域時 CORS 的問題，在 Flash 的年代是一個 crossdomain.xml 解決，但現在的解法是多一個 OPTIONS request，反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制：「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的：

• If speed is the overriding requirement, keep using compound documents.
• If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
• Caching only makes a bit of difference.
• Optimizations benefit the server more than the client.