Inlining critical CSS for first-time visitsという、クリティカルCSSを初回訪問時のみインラインに展開して、その後はインライン化せず予めキャッシュさせておいたフルセットのCSSを使うというアイディアについての記事を読んだ。実装はともかく、アイディアとして成立していないんじゃないかと思う。
クリティカルCSSをインライン化することのメリットは既に多くのウェブサイトでも取り上げられており、もちろんネタ元のGoogle PageSpeedでも項が割かれている。ここでは特に触れないが、描画領域の大きさにかかわらず初期描画の高速化には大きなメリットがあるとは言えるだろう。上記リンク先の記事ではそれを動的に行うことで、2度目以降の訪問の時にはキャッシュ済みであるフルセットのCSSを使わせるようにし、効率的なキャッシュ運用と保守性を実現する実装について解説されている。
常にクリティカルCSSをインライン化している場合、1度目の訪問では以下のリソースがリクエストされる。
- インライン化されたクリティカルCSSを含むHTML(非キャッシュ)
- クリティカルCSSを含まないCSS(非キャッシュ)
そして2度目の訪問では以下のリソースがリクエストされる。
- インライン化されたクリティカルCSSを含むHTML(キャッシュ)
- クリティカルCSSを含まないCSS(キャッシュ)
対して記事の実装においては1度目の訪問の時は以下のリソースがリクエストされる。
- インライン化されたクリティカルCSSを含むHTML(非キャッシュ)
- 完全なCSS(非キャッシュ)
そして2度目の訪問では以下のリソースがリクエストされる。
- HTML(非キャッシュ)
- 完全なCSS(キャッシュ)
つまり記事の実装だと、2度目の訪問時にHTMLのキャッシュが効かない。その上、フルセットのCSSを読み込むのでそのパース時間も改善しない。インライン化しない場合と比べると、HTMLのキャッシュが効かないのでページ読み込み時間は遅くなる(3度目以降には追いつく)だろう。静的にインライン化する場合と比べても、CSSのパースに時間がかかるため初期描画までの時間が遅くなる(3度目以降も悪化したまま)。
保守性という点では多少見るべき点はあるが、同じようなアプローチを使ってタスク・ランナー経由で静的にHTMLをビルドした方が効率的だろう。CDNのようなシステムとの相性も考えると静的なHTML生成の方に軍配が上がる。
クリティカルCSSのインライン化についてはまだ歴史が浅く、その目的と効果がはっきりと伝わっていないような印象を受ける。この技術の目的はページの読み込み時間の改善ではなく、むしろそれを悪化させてでもとにかく初期描画までの時間を短くすること、これくらいにとらえておくと良いのではないだろうか。そしてその最適化はその目的を崩さずに行われるべきなので、自然とクリティカルCSSを小さくするようなデザインへと帰結することになる。
僕があまりクリティカルCSSのインライン化に興味を持てないのは、ウェブサイトのデザインに大きな影響を与えすぎる点だ。インライン化を効果的に行うためには初期描画領域のビジュアル・デザインをとにかく必要最低限までに絞る必要がある。そのことは他のビジュアル・デザインとの兼ね合いという点でも情報設計という点でもウェブサイトのデザインに大きな影響を与えることだろう。ひとつの指標ではあって良いとは思うが、その性質上プライオリティーが高くなりやすく、他の指標を否定してしまいやすいと感じている。