みなさんこんにちは。ゐくをです。

今月もgihyo.jpに記事を寄稿しました。今回はフロントエンドのパフォーマンスの話。

聞いたら一生の宝，プログラミングの基礎の基礎 「第7回　Webサイトのフロントパフォーマンスの基礎を見直す」by @ikuwow 公開 https://t.co/eKIaFPZ52h

— gihyo.jp (@gihyojp) November 2, 2015

ここしばらくはサイトのパフォーマンスチューングを積極的に行っていました。 なのでフロントエンド周りの話を纏めることにしました。

記事にも書いているけれど、フロントエンドのパフォーマンスチューニングのための技法は 多く知られているしブログ記事も多いけれど、 それらが何を意味しているのか、どういうふうに効果があるのかを意識できていない人も 多いような気がしている。

多分アフィリエイトブログを積極的に運用している人とか、 技術そのものを生業にしていない人でメディアを運用している人に結構多いのではないかと思う。

そんな人がちょっと技術に足を突っ込んでこの記事を読んでくれたら嬉しい限りです。

もちろん技術者が見てもきっと役に立つかと思います。

でもやっぱりHTTP/2がいい

フロントエンドのパフォーマンスチューニングっていうのはすごく地道であまり 本質的な解決になっていない感じがする。

CSSスプライトやドメインシェアリングなんて冷静になって考えると狂気の沙汰で、 強引に画像一つにまとめて位置で画像の表示を分けるなんてとても面倒なことをするし、 本当は必要ないけどドメインを２つに分けることでブラウザを騙して同時接続数6を乗り越えようとする。 確実にバッドハック。

JavaScriptをBrowserifyでせっせと一つにまとめたりなんていうのも結構ばからしいことである。 とても良く出来たスクリプト言語で、書いたものがそのまま動くという良さがあるのに、 実行するときはまるでコンパイルするときのように面倒。

HTTP/2になると一つのコネクションで複数ストリーム流せなくなって同時接続数の問題が 実質的に解消するので、パフォーマンスの改善にはむしろ上とは別のアプローチになったりする。

こういうプロトコルを変えるようなドラスティックな改善はとても好き。 実は記事に書いたようなちまちま地道なことをするよりも、 もっと根本的に解決する方法を探すほうが性に合ってたりする。

NginxもApacheもこれから少しずつ対応が進んでいくようなので、ぜひすぐにでも導入したい。