CSSファイル数を減らしてページ表示時間を最適化

STINGERテンプレートの場合、ダウンロード対象のCSSファイルは2つあります。
少しでも表示時間を短くするためにはダウンロード対象のファイル数を減らすと効果的だと言われてます。
そこで、まずは複数あるCSSファイルのダウンロードを最適化するという目的で、SASSを導入してみました。

STINGERが使うCSS

STINGERテンプレートの中で使っているCSS定義は、以下の2つのファイルに分割されて保存されています。

• style.css
  WordPressで予約されたファイルであって、テーマ作成時の必須ファイルです。
  STINGERとしてのテーマ本体という位置づけになっているようです。
• css/normalize.css
  STINGERとしてのカスタマイズに先立って複数ブラウザの挙動を初期化するために読み込んでいるファイルです。
  先頭行にコメント記載があり、normalizeを同梱しているようです。

この記事では、STINGER使用時にダウンロードされる2つのCSSファイルを1つにまとめておき、表示時間を短くすることを考えてみました。

SASSの導入

この記事ではSASSについて既に導入済みであることが前提ですが、環境構築はこちらの記事にまとめましたので良かったらこちらも見てください。
また、SASSに関する書籍もあります。

CSSからSASSに変換

今回2つあるCSSファイルをどちらかに集約することを考えますが、前述のとおりでstyle.cssファイルはWordPressにおける必須ファイルという位置づけなので、normalize.cssのダウンロード箇所を削除してstyle.cssへ集約します。

準備としてSASS用のファイルを作成するために、以下のSASS提供コマンドでstyle.cssとnormalize.cssについて、scss版を作成します。

これでSASS形式への変換が完了となりますが、今後はSASSファイルのほうでメンテナンスするので、特にstyle.scssについては全体を見ておいたほうが良い気がします。
むしろ自動変換じゃなくて、手作業で変換したほうが衛生的かもしれません…。

SASSでファイル統合する定義に変更

SASSの場合、「@import」命令を使うことで複数あるCSSファイルの統合が出来ます。
今回はこの機能を導入してCSSファイルを1つにまとめたいと思いますが、そのためのソース修正を以下にまとめます。

style.scss

normalize.cssはスタイルをリセットするのが役目なので、style.scssの定義が始まる前に真っ先にnormalize.scssをインポートしてしまいます。

header.php

STINGERはもともとこのファイルでstyle.cssの読み込みの前にnormalize.cssを読んでいる作りでしたが、不要になったので1行削除します。
以下抜粋で言う5行目のget_stylesheet_uri()がstyle.cssへのパスへ変換されることになります。

SCSSからCSSへコンパイル

style.scssにてnormalize.scssをインポートする定義を追加して、SCSSの準備が出来たので、以下のようにしてstyle.scssファイルからstyle.cssファイルを作成します。

これでstyle.cssが出力されますが、先頭のコメントはWordPressの必須の定義なので、壊れていないことをチェック。
無事cssファイルへ出力できたら完成です。

余談ですがライセンスについて

STINGERはGPLライセンス。

それに対してnormalize.cssはMITライセンス。

SASSコマンドで作成したstyle.scss,normalize.scssは元々のライセンスを継承します。
そして気になるのは、scssファイルからコンパイルして得られるstyle.cssがどうなるか？
WEB検索するとこちらのページにまとめ記事あり。

GPLやMITやCCなど主要ライセンスの内容と意味のまとめ

GPLやMITやCCなど主要ライセンスの内容と意味のまとめ

GPL(GNU General Public License)
「GPLライセンスのソフトウェアやプログラムを使用した場合、その制作物もGPLライセンスで配布しなければならない」という、歪みねぇ制約。

MIT License(X11 License、X Licenseとも呼ばれる)
「修正済みBSDライセンス」と同条件のライセンスになります。

BSD(Berkeley Software Distribution License)
１つ目は「再配布時には著作権表示を残す」という事。
もうひとつはGPLライセンスでも明示されていた「無保証である」という事。
この２点を守りさえすれば、どのように利用しても構いません。
ライセンスをGPLに変えて再配布するもよし、改変して独占販売するもよし、ソフトウェアだけ頒布してソースを非公開にしてもよし。

解釈上、MIT(≒BSD)の場合はMITというライセンスの変更が禁止されていないのでGPLへの変更が可能。
対して、GPLではライセンスの変更はしてはいけないため、制作物はGPLを継承しないといけない。

ということでまとめると、SASSコンパイルによって出力されるstyle.cssは、以下2つのファイルを入力としてます。
そのためGPLライセンスが生き残り、結果SASSコンパイルによって出力されるstyle.cssはGPL扱いとなるようです。

• MITライセンスのnormalize.css
• GPLライセンスのSTINGERで提供されるstyle.css

この修正による感触

正直、高々2ファイルが1ファイルになるというだけといえるので、あまり実感が無いです…。
体感的にも違いはなさそう。

とは言え、この修正からはSTINGERのスタイルをSASSでの管理に切り替えることが出来ており、収穫はあったのかなと思ってます。