クリティカル・パスのCSSをインライン化して、描画の開始を早めるテクニックが広まり始めている。数字上は確かに効果的だが、ソーシャル・ボタンの非同期化によるスクロールのつっかかりと似たような問題を孕んでいるのではないかという思いが強い。
世の中にはスクロールをまったくしない人とすぐにする人がいる。しない人はまったくしないので、クリティカル・パスのCSSのインライン化は意味があるような無いようなところだ。効果的になるはずのスクロールする人は、ページが表示され次第とりあえずスクロールするという行動を取ることが多いように思う。その時、非同期で読み込まれたCSSが間に合っていないとかなりひどいことになるだろう。
こういったページ閲覧中のちょっとしたパフォーマンスの低下を避けるためにも、CSSは一気に読ませた方が良いと考えている。非同期化されたJavaScriptによりコンテンツの追加や削除が頻繁に行われる昨今ではなおさらそうではないだろうか。
また、クリティカル・パスのCSSを切り出す時にどうしてもユーザーの平均解像度などといったものを意識せざるをえないことも印象が良くない。このことは定期的に徹底的な見直しを余儀なくされるということでもあるが、ようやく広まり始めたコンテンツ主導のレスポンシブ・ウェブ・デザインとは相反する作業でもある。
他にもさらなる高速化のために「クリティカル・パスのCSSを小さくしよう」となってしまいそうで怖い。例えば初期描画領域に大きな画像とハンバーガー・ボタンだけといったウェブページはどんどん増えている。この流行りはクリティカル云々とは関係のないものだが、クリティカル・パスのCSSを減らすには都合が良いビジュアル・デザインではある。
body要素の余白の削除- 大きな画像の敷き詰め
- ハンバーガー・ボタンの位置指定
このくらいでクリティカル・パスのCSSは終わりになる。このCSSの小ささは魅力的なので、それを根拠にパフォーマンス主導でビジュアル・デザインの選択が行われてしまう結果になりうる。もちろんその選択をこの流行りが強力に後押しすることになる。
JavaScriptも含め、ウェブページにおける非同期化は処理を先送りしているに過ぎないことが多い。その処理はユーザーの閲覧と並行して行われるので、閲覧の快適性を損なう可能性は十分に考えられる。初期描画開始までの高速化は、数字としてはわかりやすい指標だが、それが即ウェブページの快適性に繋がるとは限らないことは十分に意識しておく必要があるだろう。