FontAwesomeを使うのを止めた理由

今までずっとアイコンフォントとして、FontAwesomeを使ってきましたが、使うのを止めました!
FontAwesomeを使うのを止めた理由
理由としては単純で、余分なロード時間が掛かっていると判断したからです。
FontAwesomeは非常に多くのアイコンが入っており、使っているアイコンが10個未満だとしても、全てのアイコンデータを読み込まないといけません。
つまり、サイトで使っていないデータも読み込んでしまっているのです。
アイコンの種類、見た目のグラフィック等、ロード時間を除けばFontAwesomeは素晴らしいものでした。
実装も1行JSを読み込むだけで済み、CSSで:before
や:after
に疑似要素としてアイコンを表示するのも楽でした。
しかし、昨今のSEO評価制度を見る限り、意味のあるコンテンツを作るというのは当たり前にありますが、内部施策の観点で言えばモバイルファースト(簡単に言うと、スマホでサイトを見たときのサイト表示速度)が最重要だと私が判断した為、この度FontAwesomeを使うのをやめました。
勿論、アイコンはサイトにとって非常に重要なデザインパーツなので、どうにか実装はしないといけません。
FontAwesomeを使わずにアイコンをどう実装したか
デザインがきっちり決まっていて、頻繁にアイコンを増やす等をしない方であれば、icomoonを使ってSVGスプライトを作りアイコンを使うのが、一番データ通信量が少なくすむのでオススメです。

icomoon
ただ、私のサイトはデザインを変更する事が頻繁にあると判断した為、SVGスプライトを作ってしまうと、新しくアイコンを追加したい時に再び作り直さなければいけなくなってしまうので、HTMLに直でSVGを入れています。
HTMLに直接SVGを埋め込むメリット
HTMLにSVGを埋め込むメリットとしては、2つあります。
- アイコンを変えたい時に、SVGを入れ替えるだけなので、めっちゃ楽
- 1ページ内にアイコンの数が20個未満であれば、icomoonを使ったSVGスプライトを使うよりデータ量が少ない
私のサイトですと、1ページ当たり最大で21個のアイコンを使う予定なので、SVGスプライトを使って構築したほうが結果データ量は減ると思います。
ただ、アイコンの入れ替えが頻繁にあると予想しているので、入れ替えの楽なHTML直入れにする事にしました。
HTMLに直接SVGを埋め込むデメリット
デメリットとして考えられるのは
- 1ページ内にアイコンの数が20個以上あると、icomoonを使ったSVGスプライトを使う方がデータ量が少なくすむ
- アイコンフォント化していないので、:afterの様な疑似要素をアイコン化するのが面倒
の2つだと思います。
モバイルファーストを意識したサイト制作を心がけるのであれば、1KBでもデータ通信量を減らしたいと思うので、1ページ内にアイコンの数が20個以上あるのであれば、SVGスプライトを使った方が良いと思います。
icomoonを使っていれば、アイコンフォント化も簡単にできるので、疑似要素をアイコン化するのも簡単です。
FontAwesomeを使うのを止めた結果
見た目のデザインも変わらず、PageSpeed Insightで計測したサイト表示速度も上がり、大満足です。
ある程度サイトのデザインが固まってきたら、SVGスプライトに切り替えていこうと思っています。
遅延読み込みを行わなかった理由
FontAwesomeをDOM形成後に遅延読み込みすれば、こんな対応しなくてよくない?
と思った方はいらっしゃるでしょう。
私としては、それも正解ではあると思っています。ただ、遅延読み込みは結局読み込むタイミングをずらしているだけで、読み込んでいるデータ量自体は変わりません。
最終的に読み込むデータ量は軽量であれば、軽量であるほど良いと私は考えているので、サイトで使っていないものを読み込むのには抵抗があるのです。
なので、今後アイコンフォントを使うとすれば、icomoonを使いサイト上で使うアイコンのみをSVGスプライトにし利用したいと考えます。
スポンサーリンク
コメント欄
コメントを書く