モチベーション
暇つぶしにアナリティクスを見ていたところやたらとブレンダーの記事がヒットしている。検索にヒットさせることを目的とした記事だった気がするため製作者冥利に尽きる(お役に立っているかはわからない)。一方でこの記事は画像がやたらと多い。その結果重いページであり、表示まで結構時間がかかることも知っている。ということで速度でも上げようと思い立った。
アプローチ検討
どのようにして速度を向上させるか。その手段として次の2つを検討した。結論としては2の転送容量の削減を実施した。
- サーバーの速度向上
- 転送容量の削減
サーバーの速度向上
本記事作成時点でサーバーはnetlifyを使わせてもらっている。ドメインの転送先を調べれば今のサーバーを調べられる、またnetlifyは日本にサーバーやcdnを用意していないため遅いという記事を見た。
ということで実際に調べてみる。nslookupで調べたところわがドメインの転送先はap-southeast-1(ipv4)でありシドニーにいるらしい。
$ nslookup stwms.net
サーバー: UnKnown
Address: ****
権限のない回答:
名前: stwms.netlify.app
Addresses: 2406:da18:880:3801::c8
2406:da18:880:3802::c8
13.228.199.255
13.251.96.10
Aliases: stwms.net
traceはうまくいかなかったが、まあcdnがなく実態のサーバーも遠いなら遅いだろう。最近海外のゲームの記事を挙げたので若干日本以外からのアクセスもいただいているようだが、記事は日本語しかない。そのため日本ユーザーをターゲットにすることを考えると近場にエッジサーバを置いてくれるサービスがよさそうという結論に至る。
とはいえサーバーを乗り換えるのは面倒なため、もっと暇なときにする。
転送容量の削減
当然のことながら転送容量自体が減ればいかにサーバーが遠かろうとも読み込み時間は速くなる。そして現在は適当に用意した静的サイトをてきとうにデプロイしているだけであり、容量削減はしていない。そのためcss, js, 画像は転送容量を削減する余地がある。ここに手を入れる。
転送容量の削減(実践)
css, js
本サイトはhugoを利用している。先生はminifyコマンドを用意してくださっている。
hugo-command
これを追加すればよい、お手軽。素晴らしい。修正前後の速度は測っていない。多分、速い。
なお調べを進めるとdisqusのjsなども意外と読み込みに時間がかかっていることがわかった。これは手出しができないのだが、読み込みを邪魔するわけでもなくたまに❤が付いてちょっとうれしいので一応置いておく。
画像の削減
こちらは真面目に速度を測った。なんということか画像群を読み込むのに7.09[s]もかかっている。流石に遅すぎだろう。これは改善の余地があるに違いない。
削減方法の検討
思いついたのは次の2つ。
- 解像度を小さくし容量を削減する
- 圧縮形式を変更し容量を削減する
1は手軽に思えたが、いざ検討するとアスペクト比とか気にするのが面倒なことが分かった。そういうことも考慮してくれるフリーソフトもあるようだがこのサイトを更新するのにGUIでポチポチするタイプの依存を作りたくなかった。そのため簡単にCUIでポチれそうな2番を検討する。
近年ではwebp, avif辺りが有名なのでひとまずこれらでどれぐらい削減できるのかを調べたところどちらでも充分に圧縮されるとのことだ。どうもavifの方が容量が小さくなり、またブラウザも対応済みとのことなのでこちらにする。詳細はほかの人が検討しているのでここWebサイトの画像フォーマットは積極的に「AVIF」を使おう | zennとか参照。
しかし適当にスクリーンショットを取るとpngやjpegになる。これは変換が必要、ということでffmpegが変換できるため利用する。この子もexeで配布してくださっているため環境保持や環境変化には対応できるだろう。
バッチ(windows)
ということでドラッグドロップで変換し元ファイルを消すバッチを作った。そんなに画像は多くないため複数ファイルの対応はやめた。多くなる時に頑張る。
|
|
結果
この後minifyしたため最終的には1.0[s]程度で第一読み込みが完了するようになった。まだ遅い気もするが、頑張れる範囲で高速になったので良いだろう。
なお何度かスーパーリロードすると1.8[s]ぐらいまで上振れすることもあった。経路のキャッシュ度合いとかも効いてそう。しかしそこまではコントロールできないため、気になりだしたら日本サーバーを用意してくれているホスティングサービスを検討しよう。