2024年2月12日(月)

ReactとAstroでブログを作ってみて

このブログサイト、「GadgetBlossom」はReactとAstroで制作しました。
Astroは静的なWebコンテンツを生成するための静的サイトジェネレーターで、2021年に登場してからまだたったの3年しか経っていません。

なぜAstroを採用したのか？

Astroは基本的にはSSGで動きます。（設定すればSSRで動かすことも可能です）
静的コンテンツが多いブログである以上は、パフォーマンスを可能な限り引き上げてUXやSEOにおいて優位に立ちたいという理由から迷わずAstroを採用しました。

AstroはIslandsというフロントエンドアーキテクチャによって、静的コンテンツの海の中に動的コンテンツの島が存在するという独特な考え方で成り立っています。
島に当たる部分はSSRやCSRを用いてReactやVue、Svelteなどから完全に独立した部品を読み込ませることができ、それらの部品を遅延して読み込ませることも可能。
まさにパフォーマンス全振りのフレームワークです。

私は半年ほど前からプライベートでReactを学んでいました。
職場ではAngular、Flutter、Smatyなどがメインですが、ここ最近のフロントエンド界隈ではReactが一強の状態。

ブログを作るのであれば、ReactかNext.jsを使って作ろうかと思っていました。

ただし、いろんなブログや記事を漁ってみるとNext.jsよりもAstroの方がパフォーマンスが高いことが判明。
想像はできていましたが、やはりJavaScriptを取り除くことで得られる恩恵が大きかったようです。
※「Astro Next.js 比較」などと検索するとたくさん記事が出てきます

Astroを使ってみた感想

先述した通り、最近のWebフロントエンド界隈ではReactやNext.jsがデファクトスタンダードになり、数多くの有名サイトで採用されているように思えます。
ユーザーの操作をそこまで必要としない静的コンテンツが多いサイトでもReactが使われるようになってきている中で、表示速度の早いサイトが今後ユーザーに求められる状況になるのは時間の問題だと思います。

今回は初めてAstroを使用してみましたが、結論からいうとめちゃくちゃ良かったです。
Reactに触れたことがある人であれば、ほんの少しだけドキュメントを読めば直感的に書けます。
Astroの中にReactを入れる際も、特にストレスになるようなこともなかったです。

べた褒めしていますが、勿論良いことばかりではありません。

複雑な認証系の処理は現状苦手
SPAには不向き
コンテンツが増えれば触れるほどビルド時間が増加する

あくまでも私の個人的な意見ですが、複雑な認証系の処理が不要かつ静的コンテンツの中に部分的に動的コンテンツが存在するMPAを作るとなったらAstroがベストプラクティスな気がします。

ビルド時間が増える問題に関してはキャッシュを使えばうまくいくかもしれません。
いつかきっとビルド時間で悩む時が来たらその時考えます。

因みに、GadgetBlossomはヘッターとフッターの部分だけReactを使っています。
フッターは普段最下部にあって見えないので、見える部分までスクロールしたら要素を取得するようにしています。

<Header client:load showTopImage={showTopImage} />
　<main>
　　<slot />
　</main>
<Footer client:visible />

cliend: visibleと書くだけで、描画が必要になるまでの間は読み込まれなくて済みます。

また、本ブログは無駄にPWA化しましたが、プラグインが用意されていてとても簡単に実現できました。
必要なプラグインをインストールしたら、astro.config.mjsにプラグインを読み込ませてあげるだけでOK。

export default defineConfig({
  integrations: [
    react({
      include: ["**/react/*"],
    }),
    tailwind(),
    icon(),
    astroImageTools,
    serviceWorker(),
    partytown({
      config: {
        forward: ["dataLayer.push"],
      },
    }),
    webmanifest({
      icons: [
        // 省略
      ],
      name: "Gadget Blossom",
      short_name: "ガジェブロ",
      description: "ガジェットと植物のブログ",
      theme_color: "#005c07",
      background_color: "#005c07",
      display: "standalone",
      start_url: "/",
      scope: "/",
      lang: "ja",
      dir: "ltr",
      orientation: "portrait",
      categories: ["utility"],
    }),
  ],
});

サービスワーカーをJavaScriptで頑張って書いていた頃が懐かしい…。

UIライブラリは「Tailwind CSS」

MaterialUIやChakura UIなどの最初から全部揃ってるよ系のライブラリは使いませんでした。
使わなかった理由としては、ライブラリ自体のサイズが大きいですし、自分で1から書いたほうがオリジナリティが出て良さそう？と思ったからです。
もしUIコンポーネントを使うのであれば、必要なコンポーネントだけを個別に入れられるshadcn/uiあたりを使いたいなぁと思った次第です。

Tailwind CSSを使って完全に白紙の状態から実装するのは今回が初めて。
レスポンシブなヘッターを構築するだけでも半日かかりました。

Tailwind CSSはBootStrapと似ている部分がありますが、Tailwind CSSにはデザインを作るクラスがありません。
そこだけ注意ですね。あくまでもCSSプロパティのユーティリティクラスが用意されているだけになります。

class属性が長くなるのがデメリットですが、コンポーネントを使い回すのが前提なのでそこまで問題視していません。
レスポンシブ化やダークモードの実装などは色々気軽に実現できるのでおすすめです。

※アニメーションは「tailwindcss animated」というプラグインを入れています

CMSは「MicroCMS」

記事を管理する部分も自作しようかなと思いましたが、単にスキルを身に着けるのであれば良いですが正直時間の無駄です。
最初はローカル環境で動いてMDXを出力するTinaを使用する予定でした。

ローカルにデータがあればビルド時にFetchしなくて済むので長期的に考えたらビルド時間を大きく短縮できます。
しかし、そのままでは予約投稿ができなかったりと使ってみて不便な点がチラホラと..。
おそらくプラグインやら入れればもっと色々できるんでしょうけど、すべて英語なので重い腰が上がらず。

最終的にブログもポートフォリオサイトもMicroCMSで統一しました。

日本製なのでなんか親近感がありますしね。
個人ブログであれば無料枠を超えることもないと思いますし、 Webhookで記事を投稿したら自動で再ビルドされて反映される仕組みも簡単に構築できるのでおすすめです。

ホスティングは「AWS Amplify」

最初はVercelで考えていましたが、将来的に商用化するとなると月額$20。お高い。

検討の結果、お名前.comでドメインを購入してAWS Route53でDNSを管理、AWS Amplifyでホスティングするという形に落ち着きました。
今はまだAWSが無料期間なので維持費は月200円程度で収まっていますが、今後どうなっていくのか不安です..。

最後に

Gadget Blossomは今回紹介した技術を使用して制作しました。
開発期間は1週間程度です。

Astro、とても良かったです。
習熟難易度は低く学びやすいですし、高パフォーマンスのMPAのサイトを短期間で作るのであれば最有力候補かと思います。
公式ドキュメントも一部ですが日本語に対応。
おすすめです。

パフォーマンスを計測してみるとPCでは98点。
期待通りでしたがここまで来ると100点にしたいですね。

スマホは改善の余地ありです。
主に画像の最適化が不足しているので今後対応していきます。
とりあえず90点以上なので私の中では合格としておきます。

これからもユーザーエクスペリエンス向上に向けて頑張っていきます！