プレーンなCSSとSassを使ったCSSで、PageSpeed Insightsを比較してみた件
2022.05.10
CSSを最初に勉強していると、次のステップとしてSassやSCSSという言葉を耳にすると思います。
実践の現場でも使われていることが多いので、CSSをしっかりと理解できるようになったら、次のステップとして、是非とも覚えてもらいたい技術になります。
ここでは、その使い方は置いておいて、実際に使った時のメリットやデメリットを紹介しながら、その効果などについて、お話していきたいと思います。
目次
Sass(SCSS)のメリット
詳しい使い方は、また機会を改めてご紹介するとして、Sass(SCSS)のメリットについて、お話していきます。
まずはざっくりとメリットをリストアップすると、
- 入れ子構造で記述できる
- 入れ子にすることで、記述がバラバラにならない
- 記述を最小限に抑えることができる
- 重複した記述を防ぐことができる
- 変数を使うことができる
- コーディングのスピードアップが図れる
一番大きなメリットとしては、入れ子構造で記述できるので、体系的にソースを整頓できるというところかと思います。
そのため、プレーンなCSSで記述していると、後から追記する場合に、それまでの記述と重複してしまったり、同じ記述が散乱していたりと、無駄な記述が増える可能性がありましたが、それを防ぐことができます。
Sass(SCSS)のデメリット
CSSを記述する上で、とても便利なので実務の現場でも広く導入されているので、是非とも覚えてもらいたいですが、いくつかのデメリットも存在します。
個人的には、そのデメリットが大きくてしばらく導入していませんでした。
- 入れ子の階層が深くなってしまう
- SCSSファイルからCSSファイルへのコンパイルが必要になる
- そのため修正する度にコンパイルが必要
- エンコード後のソースが読みづらい
- デベロッパーツールで追跡するには、mapファイルが必要になる
制作環境を整えて、コーディングに慣れてくると、これらのデメリットは小さくなると思いますが、最初の慣れないうちは、普通にCSS書いた方が楽と感じるかもしれません。
プレーンなCSSとSassを使ったCSSでスピードを比較した結果
以上のように、Sass(SCSS)を使ったCSSのメリットとデメリットを簡単に紹介してきました。
CSSのメンテナンス性などを考えた場合、Sassを導入するメリットは大きいと思うので、ぜひ勉強してみて欲しいですが、実際に導入した場合、サイトの表示速度にどのくらい影響があるのか、気になったので、当サイトを使って検証してみました。
まずはプレーンなCSSで検証して、それを基準にして比較してみます。
対象としたのは、
- プレーンCSS
- Compact(mapあり)
- Compressed(mapあり)
- Compact(mapなし)
- Compressed(mapなし)
の5つで、CompactとCompressedで違いがあるのか?
mapファイルありとなしで違いがあるのか?
プレーンなCSSと比較してどのくらい速度が変わるのか?
というところに注目してみます。
PageSpeed Insightsのサービスは、チェックしたタイミングでかなり誤差が生じるので、それぞれ5回ずつ取得しています。
プレーンなCSSで、PageSpeed Insightsのチェック
まずは、Sass(SCSS)を使わないプレーンなCSSの状態でチェックしてみます。
5回計測した結果は以下の通りでした。
1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
---|---|---|---|---|---|
SP | 61 | 46 | 44 | 61 | 46 |
PC | 99 | 82 | 81 | 99 | 84 |
SP(スマホ)では、61〜44と測定ごとの差が20近くあり、PCでも99〜81と同様になっています。
PCでは、全体でも最高の99を叩き出しているところは特筆すべきところかなと思います。
Sass(SCSS)で、Compact(mapあり)でチェック
Sass(SCSS)を使ってコーディングし、Compact(mapあり)でコンパイルした場合の測定結果が以下の通りです。
1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
---|---|---|---|---|---|
SP | 59 | 40 | 60 | 59 | 60 |
PC | 93 | 81 | 92 | 89 | 90 |
プレーンCSSの測定値と比較すると、全体的に低い結果となりました。
コンパイルしたソースコードやファイルサイズを見ると、文字通りコンパクトになっているのですが、mapファイルにアクセスすることで、レンダリングブロックが発生しているのかもしれません。
Sass(SCSS)で、Compressed(mapあり)でチェック
Sass(SCSS)を使ってコーディングし、Compressed(mapあり)でコンパイルした場合の測定結果になります。
1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
---|---|---|---|---|---|
SP | 32 | 44 | 58 | 52 | 35 |
PC | 83 | 81 | 91 | 93 | 83 |
ちょっと予想していた結果と異なりました。
Compressedは、改行を排除してファイルサイズを圧縮したソースコードになるので、読み込み速度は改善されるかと予想していたのですが、それほど効果はありませんでした。
もっとソースコードが大きくなればその効果は出るかもしれませんが、今回はむしろCompactの時より悪化してしまいました。
全体を通して一番悪い測定結果でした。
Sass(SCSS)で、Compact(mapなし)でチェック
続いて、Sass(SCSS)を使ってコーディングし、Compact(mapなし)でコンパイルした場合の測定結果です。
mapファイルへのアクセスが無い分、レンダリングブロックが発生しないかなと予想しています。
1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
---|---|---|---|---|---|
SP | 44 | 51 | 55 | 64 | 60 |
PC | 81 | 95 | 80 | 79 | 83 |
結果的には、mapありと比較してそれほど変わりませんでした。
もう少し影響あるかと思いましたが、それほど変わらないのであれば、mapファイルがあった方がメンテナンス性は高いので、mapありの方が良いですね。
Sass(SCSS)で、Compressed(mapなし)でチェック
Sass(SCSS)を使ってコーディングし、Compressed(mapなし)でコンパイルした場合の測定結果がこちらになります。
1回目 | 2回目 | 3回目 | 4回目 | 5回目 | |
---|---|---|---|---|---|
SP | 46 | 51 | 42 | 54 | 40 |
PC | 91 | 90 | 92 | 95 | 93 |
こちらの測定結果は、数値自体はあまり高くないですが、比較的安定した数値となっていますね。
Compressedでコンパイルして、mapファイルを使用しないと、メンテナンス時に大変苦労するので、この方法で運用するのは現実的ではないかな?
まとめ
今回は、「プレーンCSS」「Compact(mapあり)」「Compressed(mapあり)」「Compact(mapなし)」「Compressed(mapなし)」と5つのパターンで、Google PageSpeed Insightsで速度を比較してみました。
今回、当サイトのCSSで比較してみたので、プレーンな状態でも1000行ちょっとのソースコードだったので、それほど差が出なかったかもしれません。
もし、ページの表示速度に変化が無いのであれば、Sass(SCSS)のコンパイルに慣れてしまえば、メンテナンス性などメリットは大きいので、是非とも勉強して導入できるようになっていただければと思います。