Gatsbyに入門して一週間で出来たサイトですが、なかなかサマになったなぁ、と自己満足してます。
クオリティやアプローチはまだまだレガシーなんですが、サイトのタイトルの通り「インターネット老人おじさん」としているので、あんまりモダンなレイアウトにできなかった。
名前負けしました。

タイトルが悪いのか？

私だって本当はタイトルみたいなデザインとか作りたいんですが「○○ってBootstrapじゃね？」というよくわからない反骨心で採用しようとしない傾向にあります。
おかげで流行だけではなく思想までインターネット老人と化したわけですが、とりあえずベースになるブログはここまで出来たし、後は（高速化とか軽量化も）どこまで行っても趣味の世界だし、これ以上やりようがないので諦めます。
ぶっちゃけMicroCMSを捨てたら爆速は維持できます し、こんなに苦労しなかったはずです。
Githubリポジトリ （そのうちブログに移行します）でも言及していますが、

• どこからでも
• PCでもスマホでも
• 記事を書いたら即反映

これを捻じ曲げると、昔運営していたGithubPages+Jekyllサイトのように非常にイラつかされる事になっていました。
GithubPagesを捨てたのも、ビルドが遅すぎて記事の修正確認がプレビューできなかった事にあります。

静的サイトを運営した事があるから分かる、MocroCMSの良さ

MicroCMSは画面プレビュー機能があるため、記事を更新してビルドするまで画面で確認ができない、という煩わしさを捨て去る事ができるのです。
これは、GatsbyJSのデフォルト機能ではできない事なので、とても捨てられません。
microCMSで書いてプレビューして、実際はGatsbyJSにマークダウンで置く手もなくはないですが、それだと二重管理になりますし、手間がかかります。
きっと途中で飽きて廃止するだろうな、という未来が今の時点で見えました。
おそらく他のCMSでも画面プレビュー機能はあると思いますが、私が知らないのと、探して比較しようとは思いません。
そう思うぐらいMicroCMSで満足しているのです。

外部CMSを使いつつ、速度を改善する

さて、本題です。
概要をざっくり言えば、

• Webフォントを諦める
• 画像はGatsbyJSと同じWebサーバーに置く
• 画像は.webp形式に変換する
• GatsbyJSのプラグイン拡張だけ使う

です。
一つずつ解説していきます。

Webフォントを諦める

Webフォントという表現をすると、「サーバーに置けばよくね？」みたいな話を始める人もいますが、そういうい問題ではありません。
まずはゆっくり読み進めてみてください。

このブログでは、遅延読み込みを採用しているのでレイアウト崩れは起こりますが使えないわけではありません。
とはいえ、読み込み自体が遅いという問題に目を背けただけなので本質的な解決には至りません。
デザイナーズサイトでもない限り、フォントにこだわりすぎるのはよくありません。
色々試行錯誤して納得のデザインを見つけた頃には、速度チェッカーに掛けて鈍足だった、なんて事になると目も当てられません。
そもそも、フォントはすべての文字に対応しているわけではありませんので、内容によっては漢字がダメ、英数字がダメ、日本語がダメなど使用上の注意点もあります。
凝った表現を取り入れて差別化したい気持ちは（このブログでWebフォントを採用しているので）非常によく分かりますが、知識がない状態で実践するのは危険すぎる領域です。
サイトが遅いと思ったらスクリプトよりフォントを疑いましょう。

画像を次世代の規格（私はwebpを選択）形式にする

これはチェッカーに掛けて初めて知りました。
webp以外にも似たようなアプローチをしているものとして、JPG2000とかJPEG-XRとか色々な規格がありますので、どれが良いかは比較しないとなんとも言えませんが、手元の画像を変換した感じではどれも対して違いが分かりませんでした。
MicroCMSにサイズを最適化した状態のwebpを保存しておき、GatsbyJSで再度変換して全ブラウザで表示できるようにしていますが、ぶっちゃけこれをやる意味ある？ぐらいに思っています。
理屈的にはビルド時にやった方が表示が最適化されているらしいです（タグが変わったのは分かりましたが、具体的にどう良くなったか説明できないので「らしい」としました）が、場合によっては容量が増えたりしているのでこの辺りはまだ考えた方が良さそうです。
Gatsbyが公式で次世代規格に対応できるようなら検討の余地はあります。
なお、MicroCMSは対応しています。この記事の画像もwebpですがGatsbyで変換してjpgやらpngになっていますのでブラウザから確認できませんね…。

GatsbyJSのプラグインを使う

GatsbyはReactがベースなのでReactで使えるものはGatsbyでも使えるんですが、使えるのと使いやすいのはまた別の話です。
使いやすいからいいケースもあれば、使いやすくても最適ではない事もあります。
ひどいときには「動くけど…う〜ん」みたいなものもありました。
GatsbyやReactプラグインのバージョンが上がったら互換性がなくなる、なんてケースもなくはないだろうなので、しっかりと公式サポート（動作検証的な意味で）されているものを使ったほうが安心です。
Reactプレーンで完全に独立しているならまた話は変わりますが、どちらにせよ判断がややこしくなるケースが想定されるなら注意するしかないです。

なお、プラグインを入れすぎて重くならないか検証したのですが、私の触った感じだとプラグインのせいで重くなるということはなかったです。
公式でも遅かったものだと、Google Adsenseのようにクライアントサイドのスクリプトを実行している、という事がない限りは気にしなくて良いと思います。

GatsbyJSで作ったサイトブログをいつまでも爆速で保つために

フォントや画像を最適化しつづける限りは大丈夫だと考えてよさそうです。
プラグインやスクリプトのダイエットも必要ないでしょう。
最初のうちは良かったけど使い続けていくうちに重くなる、というケースにはページネーションなどで負荷を分割する方法が考えられます。
サイト内検索もアルゴリズム次第では高速化できるはずです。
レコメンド機能も品質に拘らなければ実装はシンプルにできます。
要は使い方の問題と思って良いでしょう。
サイトの保守契約が必要なケースは少ないんじゃないでしょうか。
年に一回、長くて一週間程度でメンテナンスの相談時間を都合する事も可能ですので、静的サイトを検討中もしくは運用中の方の相談に対応できます。
個人でも歓迎しますので、お気軽にLINEで友達登録＋メッセージを送ってください。