2017年にこのブログはWordpressからMiddleman製に作り変えたのですが、この度MiddlemanからGatsbyへ移行しました。前回の移行の記事はこちらです。
\n\n\n\n
Middleman時代からmarkdownや画像系を全てソース管理していたので、移行は二日くらいで特に問題なく終わりました。\n今回はマイグレーションガイドではなく、使用感としてMiddlemanとGatsbyを比較してみたいと思います。
\nGatsby使えばオフライン対応が入ってPWAにしやすいって話もあるんですが、このブログがPWAになってもどうしようもないのでその辺りは割愛します。
\nlighthouseのスコアはこんな感じです。
\nまだ初期描画のパフォーマンスがやや低い（jsのbundleが大きい）のですが、まぁ許容範囲かなと思っています。このブログはリピートで訪問される方の方が多いので、２回目以降や回遊時のパフォーマンスでいえば、圧倒的にGatsbyの方が上です。
\nGatsbyをドキュメント通りに使えばService Workerによるキャッシュやprefetchがかかるので、一度訪れたページの表示速度はかなり早いです。\n（Middlemanでもsw-precacheを使ってごちょごちょやってたんですが、管理が面倒で投げ出した）
gatsby-plugin-sharpで複数解像度の画像をクエリしてgatsby-imageを使って画像のlazy loadingと解像度の低い画像を初期表示しておくことも簡単に実現できます。
\n参考：記事のfeatured imageのクエリ と それを表示するコード
画面遷移にはgatsby-linkとgatsby-plugin-catch-linksを使うのですが、これらがprefetchの仕組みを備えているので、リンクにmouseenterするとsame-originのリンク先はfetchされ、クリックする前にキャッシュされてるのでサイト内の画面遷移も高速になります。
\nまた、通常の<a />タグを用いたリロードを伴う画面遷移ではなく、@reach/routerを用いてフロントエンドでルーティングしているので、同一ドメイン内での遷移ではリロードが発生しません。当然その分だけ早いです。この辺も自前で頑張らずとも勝手にそうなってくれるのでありがたい限りです。
\nquicklinkを使って回線強度によっては富豪的にリソースを読み込んでも良さそう、と思ってるのでprefetchの仕組みを変えるかもしれません。
また、HTTP2対応としてgatsby-plugin-netlifyを使えばLinkヘッダも自動で生成もできますし、gatsby-plugin-zopfliとgatsby-plugin-brotliを読み込むだけでZepfliやBrotliの圧縮にも対応できます。
\nMiddlemanのビルドがとにかく遅くて、CI回すたびに3-40分待つことになるのがかなり辛かったです。
\nページのビルドも遅かったんですが、もっとも遅かったのはImageMagickによる画像の最適化でした。パッケージやRubyを最新バージョンにしても速度は改善することなく、アクティブな開発も止まってるので、改善される未来も見えないなーと思っていました。
\n一方Gatsbyは画像の圧縮を含めても3-4分ほどでビルドが終わるので、10倍以上早くなりました。Gatsbyは画像の最適化にsharpというOSSを用いており、かなり高速に動作します。sharpは自分も仕事で使っているプロダクトだったので安心して使っています。
結果的にCIもデプロイもすぐ終わるようになったのでとても快適です。\nGatsby自体がとてもアクティブに開発されているし、ビルド速度に関してもまだまだ改善の余地があると思います。
\n私にとっての”普通”とは、JSのエコシステムに乗っかってwebpackサーバ立ててバベって〜、といったよくあるフロントエンドの開発のスタックに乗り換えたいということでした。
\n\n\n\n
MiddlemanでもAsset pipelineに乗っからずに無理やりwebpackを突っ込んで利用していたんですが、あまり体験は良くありませんでした。\nGatsbyではwebpackの設定がいい感じなので設定を自前で頑張る必要もありません（現時点では独自のwebpack.config.jsを持ってない）。\nカリカリにチューニングしようと思ったらその辺頑張る必要があると思うんですが、いざという時はなんとでもできそうという安心感があります。
\nまだ移行して数日ですが、今の所メリットしかないと思っています。
\nもちろんメリットがあると思っていたから移行したんですが、思ってた以上の嬉しさ（prefetch周りとかオフライン対応とか）がついてきたので、思わぬ誤算でした。\n今回のスタックはかなり満足いってるので、使ってて何か出たらGatsbyのプラグインやcoreにcontributeしていく所存です。
その他感じたことも雑多に残しておきます。
\nMiddlemanやJekyll等から移ってくるには、これまでテンプレートエンジンで書いてた部分やスタイルを全てjsxで書き直す必要があります。\nもともとのcssやSassを保ちつつ、１つ１つの要素にclassName振ってってもいいと思いますが、CSS in JSで書いた方がtree shakeしやすかったり「JSで書くならやれること」がたくさんあるので文句なしの形に移行するにはかなり手間がかかると思います。
\n移行に際して、見た目に関してこだわっておらず「本文が読みやすくて表示が早ければいい」と思っていたので、ほぼデフォルトのままで、本文に関してはMediumを参考にスタイルを当てました。
\nmarkdownのエンジンがRuby（私の場合はRedcarpet）からNode（remark）のものに変わるので、独特の方言を使ってると記法の解釈が変わる可能性がありますが、当ブログのmarkdownの構文は変えずに移行できました（アセットのパスとかfrontmatterのフィールド名はASTにバラしてゴリっと変えたけど）。
\nもしAsset pipelineを活かしたxxx.md.erbのようなmarkdownエンジンの外側の問題があると、そこは苦労すると思います。
strike throughも使えるし、見出しの横のパーマリンクもgatsby-remark-autolink-headersで実現できたし、
const message = 'Fenced code blockによるSyntax highlightも使えるし'記事では見えませんがFrontmatterも使えてます。\n（この記事のソース）
\nMiddlemanでは類似の記事の検索＋表示をやっていました。Gatsbyではそれをやってないのですが、それでもMiddlemanの方が起動は早いです。
\n画像の圧縮を開発時にもやっていることが主な問題なんですが、本番だけバグることをなるべく避けたいし、そのデバッグに手間をかけたくないのでこのまま続ける予定です。もし速度が気になっても開発時は圧縮を切ればいいので、改善の余地はまだまだあると思います。
\n（もしMiddlemanで画像の圧縮を開発時にやっていたらサーバ起動するのにビルド時のように数十分かかるので、相対的に見れば圧倒的に早い）
起動する時間はMiddlemanはおおよそ30秒、Gatsbyの方は1~2分ってとこなのですが、どちらにせよエディタに向かって記事を書いてる間にサーバは立ち上がってるのでそれほど問題になっていません。
\nHot Module Replacement(HMR)が入ってるので、画面自体をリロードせずに描画だけ更新ができます。
\nWebアプリなどで自前で設定を組むのはやや面倒ですがGatsbyでは最初から設定済みなので、使い始めれば勝手にHMRが効くようになります。\n細かいスタイルの調整をしてる時にはとてもありがたく、一度サーバさえ立ち上がってしまえばそのあとは圧倒的にGatsbyの方が快適です。
ページネーション系のプラグインを探してみたものの、どれもあまり使われてないか、開発が止まっていました。
\nただそもそもプラグインは必要なく、公式のガイドがあったのでその通りに実装しました。gatsby-node.jsから各コンポーネントへのデータフローがわかれば、特に違和感なく書けると思います。
\nその要領でタグごとの記事一覧ページも作りましたが、特にハマることも無く素直に実装できました。
などをボチボチやっていく予定です。
","timeToRead":12,"frontmatter":{"title":"ブログをMiddlemanからGatsbyに乗り換えた雑感","tags":["JavaScript","Gatsby","Middleman"],"date":"January 05, 2019","featuredImage":null}}},"pageContext":{"slug":"/impression-comparison-of-middleman-and-gatsby/","previous":{"fields":{"slug":"/you-might-not-need-dotenv-in-source/"},"frontmatter":{"title":"プログラム内でdotenvを読み込むのをやめた話","tags":["Node.js","JavaScript"]}},"next":{"fields":{"slug":"/nodejs-is-now-supported-brotli-compression/"},"frontmatter":{"title":"Node.jsの11.7.0からzlibモジュールでBrotli圧縮が使えるようになりました","tags":["Node.js"]}}}}, "staticQueryHashes": ["2585454260","2954598359"]}