実のところ、私が真面目なサイトを作る時は、似たようなビルドツールを作って動かしていました。 いい加減なサイトにも同じ仕組みを適用したいと思い初めて、作り直しました。 作り直した理由は、esbuild のように、ツールチェインがだいぶ高速になってきたからです。 まず parcel/css が出てメンテの大変そうだった CSS Minify に決定版感が出てきました。 HTML Parser は中身を操作しようとすると選択肢が一気に減るのですが、 node-html-parser が早そうな上に、使い勝手が良かったので採用しました。 普通は jsdom あたりを使うのかな。 そこにみんな大好き DropCSS を組み合わせます。 現時点で最速/最高性能と思われるライブラリを組み合わせると、割といい感じです。
ボタン一つでサイト全体の Critical Path を最適化
さて drop-inline-css の使いどころですが、シンプルなページの Critical Path の最適化 (above the fold) に使えます。 ちなみにツールでは画面内に収まっているかのチェックなどはしておらず、HTML 全体の外部 CSS をインライン化しているだけです。 そのため簡易的なページにしか使えませんが、個人的にはそれで十分と思っています。 複雑なページなら他のライブラリを使えばよく、シンプルな大量のページをストレスなく最適化するほうが大半のニーズだからです。 また Critical Path を手作業で抽出した後に適用しても良いですよね。 わざわざ Critical Path の自動抽出のような、実行時間が極端に遅くなるような処理を実装する必要はないと思ってます。drop-inline-css は、たとえば Bootstrap のインライン化には使いやすいです。 Bootstrap の CSS をそのまま読み込むサイト場合、160KB くらいロードしてからレンダリングが始まります。 drop-inline-css で不要な CSS を削除してインライン化すると、ほとんどのサイトは 5〜20KB でレンダリングを始めることができるようになります。 あとから元の Bootstrap を読み込むので 10KB くらい通信量は増えてますが、体感的にも Pagespeed Insights のスコア的にもかなり向上します。
最近は CSS in JS が流行っているので、Critical Path の最適化はやっている人のほうが少ないかな？ 個人的には CSS in JS よりこちらのアプローチのほうがずっと楽だと思うんですよねえ。 Node.js や JavaScript Framework、そして Webpack に頼り過ぎると、設定とマニュアルに振り回されがちになり、逆に苦労が増えることのほうが多い気がします。
ローカルビルドでの利用例
drop-inline-css を使えば、何一つ悩むことなく、ボタン一つでサイト全体を高速に最適化できます。 tdewolff/minify と組み合わせると最強に思ってます。ただ、Vercel / Netlify で使うにはどうするのが良いんだろう。minify コマンドとの組み合わせが難しいです。 ローカルビルドじゃないと苦労するかも。 まあ私はだいぶ前から基本的にはローカルビルドでやっているので、特に問題はないです。 デプロイサービス特有の設定を覚える必要がないので楽ですよ。 それが他の人に合うかはわからないですが、Hugo なら例えば以下のようにコマンドを打つだけでOKです。
hugo
drop-inline-css -r public -o public
minify -r public -o public
0 件のコメント:
コメントを投稿