こんにちは

システムチームのKです。

 

以前にもお話したことがあると思いますが、

僕はこれまでマーケティングチームやデザインチームを渡り歩いてきました。

そうした経緯もあって、今はエンジニアですが、実はSEO検定1級も持っています。

 

そこで今回は、「SEOを意識したサイトの高速化」について書いてみようと思います。

 

 

早ければ早いほどいい、ではなく

遅ければ遅いほど悪いというのがポイントです。

 

検索エンジンの評価は減点方式で、

遅いサイトほど評価されにくくなります。

逆にべらぼうに早くなっても恩恵はありません。

 

いくら編集画面が爆速で、使い勝手が良くても

SEOが絶望的に悪くては意味がありません。

 

デキテルの性質上、コンテンツがどんどん増えていくものですから、

基本的には、読み込むソースが多くなってサイトは重たく、遅くなっていきます。

 

デキテルでたくさんのページを公開していただいているユーザ様が

デメリットを受けないように、

公開されるサイトが重たくなることをいかに防ぐか

ということが大事になります。

 

– 昨年改修を行ったもの

HTML,CSS,JSなどのリソースを圧縮

 

CSSとJSについては、

昨年に一度改修を行いminifyを行うことで軽量化を行いました。

 

ただ、不要なコードが含まれたままminifyしていたり、

HTMLはminifyの対象となっていないので、まだ改善の余地は残されています。

 

キャッシュの有効活用

こちらも昨年対応を行い、キャッシュすべきソースについてはキャッシュされ、

編集画面で変更したり更新した内容は、

新たに読み込みなおすような処理を導入しました。

 

– 未対応のもの

適切な画像サイズ

表示エリアが小さいのに、高解像度の画像を読み込んでも意味がなく、

サイトのデータ量を無駄に増加させてしまうだけです。

 

また、モバイル端末での閲覧でフルHDの画像が必要になることはほとんどありません。

 

最小～MAXまでの画像サイズの設定に応じて、

読み込む画像ファイルを適切に分岐する処理が必要かなと考えています。

 

次世代フォーマットへの対応

WEBPやAVIFなどのフォーマットはJPEGやPNGと比べて圧縮率が高いので、

読み込みの高速化に効果があると言われています。

 

IE11など非対応ブラウザが存在するため、

利用する場合は、sourceタグなどを使って、ブラウザによって読み込むソースを分岐させるなどの処理が必要になります。

 

ただ、改修コストの割には、得られる効果が小さい（ある程度たくさん画像を載せていないと）ので

改修の優先度としては低いと思います。

 

リソースの遅延読み込み

自分が一番効果があるんじゃないかと考えているのはこれです。

前述したように、デキテルはコンテンツがどんどん増えていくものなので、

1ページが長くなります。

 

ですが、最初からその1ページをまるまる読み込んでおく必要はなく、

画面に映った段階で読み込みが完了していればOKなわけです。

 

主に画像の遅延読み込みに使用される、lazyloadという仕組みは、

画像が表示されるところへスクロールする直前に読み込みを完了させ、

初回に読み込むデータ量を減らす仕組みです。

 

こちらもブラウザ対応など、実装には障壁がいくつかありますが、

それを差し置いても高い恩恵があるので、

なるべく早い段階で導入したいと考えています。

 

これまでは編集画面のパフォーマンスに目が行きがちでしたが、

公開されるサイトのパフォーマンスも意識して改善に取り組みます。