In the old days, delivering a fast user experience depended primarily on download speed. One reason why the network was the main bottleneck back then is that JavaScript and CSS weren’t used as much as they are now, so CPU wasn’t a critical factor.
而現代網站使用 js 的情況已經是來到了新的境界 (甚至很多網站是沒有 js 就不會動)，於是對於 CPU 的能力就愈來愈要求：
According to the HTTP Archive, the top 1000 websites download five times more JavaScript today compared to seven years ago.
而 us-east-1 的 T2 Unlimited 是 $0.05 vCPU-hour，這樣看起來其實不賴？風險應該是在於不保證可以拿到多的 CPU resource...
可能要重新算一下 c4 與 c5 的使用方式了...
另外雖然文章後面寫了一大串，但對照 region 表後，看起來是所有的區域都支援了：(美國政府的 region 除外)
You can launch T2 Unlimited instances today in the US East (Northern Virginia), US East (Ohio), US West (Northern California), US West (Oregon), Canada (Central), South America (São Paulo), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Mumbai), Asia Pacific (Seoul), EU (Frankfurt), EU (Ireland), and EU (London) Regions today.
In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.
於是他們找出原因後，發現 Google Chrome 只要 POST 後的頁面都會 revalidate：
A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.
然後在討論後認為這個行為不必要，就修掉了，可以看到降了非常多：
We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.
The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.
不過這次推出修正後發現沒有大改變：(拿 production 測試 XDDD)
Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.
There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.
還是可以 opt-out 改回來，不過官方還是建議儘量用長的 ID 測試，因為今年年底將全面強迫使用：
We recommend testing longer IDs before transitioning; however, if you have not yet tested your systems for compatibility with the longer format, you still have the option to opt out and receive shorter IDs until early December 2016.
The new IDs will be the same format as existing IDs, but longer. The current ID format is a resource identifier followed by an 8-character string, and the new format will be the same resource identifier followed by a 17-character string.
本來是 8 chars，之後會變成 17 chars。而用 SDK 的人只要更新到新版就可以了：
The SDKs are already compatible with longer IDs and don’t require any updates.
預定在 2016 年發生：
My colleague Angela Chapman wrote the guest post below to make you aware of longer instance, reservation, volume, and snapshot IDs that we will be rolling out in 2016.
