ブログは速さこそ正義である。
astro-notion-blogはそんなストイックで玄人志向な人のために作った新しいNotionブログです。
今すぐ試してみたいという方は下記のリポジトリに行ってクイックスタートをお読みください。日本語のREADMEもあります。
デモはこちらです。
この記事ではastro-notion-blogの開発背景とeasy-notion-blogとの違いを紹介します。
ご存知の方もいらっしゃるかもしれませんが、筆者はeasy-notion-blogという簡単に始められることをコンセプトにしたNotionブログの開発者でもあります。
easy-notion-blogはありがたいことにファンが多く、GitHubのスター数は130を超え、熱心にカスタマイズしたりその内容をeasy-notion-blogやTwitterで発信してくださる方が数多くいらっしゃいます。
easy-notion-blogがなぜこれだけ受け入れられたのか。私は次のように考えています。
- Notionという文章を書くのに適したツールでブログが書けること
- 初期費用やランニングコストなど一切かからないこと
- レゴブロックのように自分の思うように組み立てることができ、その過程が楽しいこと
- ブログをカスタマイズするという目的のもとにプログラミングスキルが身に付くこと
- エラーなどで詰まったときにすぐにコミュニティのサポートが得られること
- 従来のページを動的生成するタイプのブログに比べてページ表示が格段に速いこと
特に6については技術的におもしろい点です。
easy-notion-blogはNext.jsというフレームワークをベースにしています。
Next.jsが優れている点はその速さももちろんですが、強調したいのはページ（URL）ごとにレンダリングの方法を変えられるところで、静的生成と動的生成のハイブリッドアプリケーションが簡単に作れる点です。
つまり、開発者はページごとの要求や特性に合わせて最適なレンダリング方法を選ぶことができます。
一方で、開発から1年経ち少し気になる点も出てきました。
Next.jsの強みであるページごとにレンダリング方法を変えられる点については、ブログにおいてはオーバースペックであることが多いと感じるようになってきました。
ブログはアプリケーションの特性として一方向的なコミュニケーション（コンテンツの配信）が主で、オンラインゲームやSNS、ECサイトのように双方向のコミュニケーションを必要としないケースが多いです。
言い換えると、コンテンツの内容はユーザーがページを訪れる前から決まっているため、事前にページを作っておくことができます。
このことから、Next.jsの大きな特長である様々なレンダリング方法を選べるという点は、ブログにおいては少しオーバースペックです。
また、SNSでシェアした際のOG画像などメタタグ周りの不安定さも個人的に気になっていました。
ブログ記事はSNSなどで頻繁にシェアされます。シェアした際に表示される情報は今やブログの生命線と言っても過言ではありません。
しかし、TwitterやFacebookでメタ情報が取得できない現象を頻繁に観測しています。
ページをサーバーサイドレンダリング（SSR）にすると問題がないことはわかっていますが、そのためにSSRにしなければならないのはNext.jsのメリットを殺してしまうことになります。
SNSでメタ情報が取得できないことは、たとえNext.js側の問題でなかったとしても（TwitterやFacebook側の問題の可能性も十分にあると思っていますが）ブログにとっては致命的です。
これらのことから、Next.jsに変わるブログを開発したいと思っていたところで出会ったのがAstroです。
様々な要求に応えることができるNext.jsに対して、Astroはコンテンツ配信に主眼を置いたミニマムで高速なフレームワークです。
学習コストが低く始められるのも良い点です。後発のフレームワークですがこれから人気が出てくるのは間違いないでしょう。
astro-notion-blogとeasy-notion-blogは具体的に何が違うのでしょうか？
これまで説明したように、フレームワークがAstroとNext.jsという点は大きく異なる点ですが、それによってどのような違いが出てくるのか見てみましょう。
| astro-notion-blog | easy-notion-blog | |
|---|---|---|
| ページ表示の速さ | ◎ | ○ |
| ビルド時間の長さ | △→○ | ○ |
| 記事ごとに異なるOG画像 | △→○ | ○ |
| SSR拡張しやすさ | △→○ | ◎ |
| 学習コストの低さ | ○ | △ |
並べて見るとeasy-notion-blogの方がバランスが良い（良かった）ことがわかります。
これがastro-notion-blogを玄人志向と表現した理由です。
astro-notion-blogは全てのページをビルド時に静的生成します。
ユーザーがアクセスしたときにはURLごとに対応するページを返すだけなのでページ表示は非常に高速です。
ときどき阿部寛さんのホームページが非常に表示が速いことで話題になりますが、その理由はすでにあるHTMLを返しているだけだからで、astro-notion-blogも同じ原理です。
あらかじめ全てのページを生成するということは、ビルドに時間がかかるということです。
ブログの記事数や記事中のブロック数によりますが、多ければ多いほどビルド時間は長くなります。
一方、easy-notion-blogではビルド時には記事ページを生成していないためビルドは高速です。
ブログでは記事ごとに異なるOG画像を使いたいというニーズは高いですが、astro-notion-blogは対応していません。
理由は、Notion APIが返す画像URLに時間制限があることに加え、astro-notion-blogは動的な処理を行う手段を持たないためです。
easy-notion-blogのようにAPIエンドポイントを作って何かを行うということはできません。
もし対応するならばAWS S3などのファイルストレージを別途用意して画像を配置するといった工夫が必要です。
先にも述べたようにNext.jsはページごとにレンダリング方法を変えられますが、Astroは今のところ部分的にSSRにすることはできず、SSRを有効にするとサイト全体がSSRになってしまいます。
astro-notion-blogで推奨しているCloudflareはAstroのSSRにも対応しており、専用のアダプタを使うことでastro-notion-blogをSSRで動かすことは可能です。
しかし、これまで述べたようにastro-notion-blogの強みは全ページを事前に静的生成することによる圧倒的な速さです。
astro-notion-blogでSSRを有効にするということは、唯一無二と言っていいメリットが無くなってしまうことに注意してください。
SSRを使いたいケースではeasy-notion-blogを採用した方が良いでしょう。
学習コストの低さという点においては、astro-notion-blogに軍配が上がります。
Next.jsはReactをベースにしていること、いくつかのページレンダリングの種類やコンポーネントのことなど学ぶべきことが比較的多いですが、AstroではほぼプレーンなHTMLやCSSを書くAstroコンポーネントを使うため学習コストは低いです。
JSXさえ抑えておけば問題なくAstroコンポーネントを書くことができるでしょう。
さて、ここまでastro-notion-blogの開発背景やeasy-notion-blogとの違いについて説明してきましたが、結局のところ個人的には、easy-notion-blogの経験者はみんな味わったであろう最初のドキドキ、ワクワク感をastro-notion-blogでもまた味わってもらえたら良いなと思っています。
このアルパカログもastro-notion-blogへ移行予定です。
いいねボタンが無くなってしまうのは少し残念ですが、ものすごく速くなるはずなので楽しみにお待ちください。
以上です。
この記事ではastro-notion-blogの開発背景とeasy-notion-blogとの違いを紹介しました。
P.S.
コメントを送る
コメントはブログオーナーのみ閲覧できます