t_wの輪郭

Amazonが提供するCDN
システムがAWS上で動いていなくても利用できる
システム（オンプレ）→ CloudFront → クライアント　のようにできる

オンプレミスの略称

変な小細工をして手間をかけるよりも、CDNを噛ませる方が楽に早くできるので好み
サーバ側の負荷も下げられる
ただ、デライトのような動的なコンテンツを扱う場合は工夫が必要になりそう
お金もかかる

昨日，アイコンのスプライト化を3歩ほど試行してみて，やはり保守性の問題を感じた。

ドメイン シャーディングにも言えることだが，最適化のために実装の意図を曖昧・遠回しにする，というのは全体最適化の観点から避けるべきことだ。開発者としてはどうしてもここにひっかかる。

そんな時，HTTP/2 のことを思い出した。RFC 7540 が出来た頃に情報収集した記憶があるが，流石にその時は時期尚早で導入は考えにくかった。現状，月庭も含めてデルンは HTTP/1.1 で動いている。

改めて調べてみると，採用実績は十分にある。請い手側の普及率は調査によって中途半端なところもあるが，時間が解決する問題であること，そもそもデライトが比較的新しいブラウザを事実上の推奨動作環境としていることから問題ない。

kitetu.com の HTTPS 統一 はすでに実現しているため，手定め環境で nginx の ngx_http_v2_module を導入するだけで環境は整いそうだ。

スプライト化に費したのは，デライト・アイコン集制作の時に配置を工夫したこと，昨日の3歩くらいで正味数時間だろう。埋没時間はほぼない。

早速 HTTP/2 の導入試験を始めることにした。

ちょうど11月から Googlebot も HTTP/2 に対応するらしいので，今が好機なのだろう。