Astroでサイト構築1

はじめに

こんにちは！
都内で主にフロントエンド業務とマネージメント半々でお仕事しているジュウドー・富岡です。

いままで業務では主にwebpackをベースに、TypescriptやSassをメインに使って業務でサイト構築をしていました。
ビルドの遅さや設定の複雑さに見て見ぬふりをし、開発・運用メンバーへの説明の手間と業務量を言い訳にして、気持ちとは裏腹になあなあな関係でwebpackとここまで付き合ってきました。
そんなときにCore Web Vitalを意識したハイパフォーマンスなサイト構築を要求している案件があったのでそれを機（盾）に、非エンジニアで構成された運用チームへの負担を限りなく考慮した環境構築のお話です。

背景と方針

現在所属している会社の制作部門には主に3つのチームがあります。
更新・運用、デザイン、エンジニアチームです。
弊社では作って終わりという案件がほぼなく、その後の運用や改善提案まで担当することが大半です。
なので技術的に詳しい人だけが理解できる構成はあまり好まれないです。
この環境がいいか悪いかはさておき、新しい技術や仕組みを使ってサイトパフォーマンスを最大化しつつ、社内で運用可能な構成にすることを目標にしました。

要件

今回のクライアントからの要件ですが制作部門で担当する事になった大きな項目が3つあり、
1つ目がCore Web Vitalを基準としたパフォーマンスに優れたサイト構築。
2つ目がアクセシビリティ基準であるWCAG2.2/AAへの対応。
最後に決済機能の実装です。

細かい要望は他にもあるのですがそれ以外には、更新頻度が高いいくつかのコンテンツはCMSで管理する必要があったりします。

また社内ごとでは現環境と使い方にあまりにも違いがあると「難しすぎる」、「業務量が増えた」などの声があがると予想されたのでクライアントの要件を満たしつつ、全メンバーのスキルを考慮してぎりぎりを攻め込んでいきました。

選定

フレームワーク

迷いましたがAstroを使うことに決めました。
事前調査では主に3つに絞っており、候補はNuxt、Next、Astroでした。

まずNuxtは実務経験があり、Vue.js自体が初学者でも比較的触りやすそうだったため第一候補でした。
ただ僕がNuxt3をinitして環境構築をしようとした際に、ローカルで警告が出ていたり
そもそもNuxt3の評判が全体的に気になりました。

Nextも既存サイトに部分的に組み込む形でReactを使用したことがあったのですが
webサイト構築にはオーバースペックに感じたのと、運用チームの負担が大きくなりそうだったため躊躇っていました。

そんな中NuxtやNextにシェア率は及ばないものの、シンプルな構成で高いパフォーマンスを出せるAstroに出会いました。
SassやTypescriptはもちろん、ReactやVueも手軽にコンポーネント単位で導入でき、
規模的や運用コスト的にもベストだと思いAstroに決めました。
ファイル名が異なるだけで実質htmlと変わらない扱い方ができるので、
普段Javascriptを触らない更新チームでも運用ができそうで、エンジニアチームにとってはよい勉強になりそうな点もちょうどよかったです。

CMS

国内産HeadlessCMSの中ではmicroCMSが強い印象ですが、今回はKurocoCMSを使うことにしました。

こちらに関してはホスティング先にKurocoFrontというKurocoCMSに付随しているサービスを使えて、要件にある決済機能もEC用の機能がデフォルトで入っていたのでこちらにしました。
本当はホスティング先もVercelだったりCloudflareあたりを選定できればベストだったのですが
納期との兼ね合いもありホスティング機能もついているKurocoを採用してみました。

また普段の業務では8割くらいのサイトをWordPressで構築しています。
シェア率と既存資産の多さからくる安定感は偉大ですが、今回はパフォーマンスも考慮してHeadlessCMSを使うことにしました。
WordPressは好きで使っていたというより、見慣れた管理画面と運用コストでクライアントから好まれることが多く、社内に財産も多くあるのでよく採用していました。

様々な意見があるとは思うのですが僕は要件を満たせてクライアントが満足できれば、WordPressでもHeadlessでもはたまたフルスクラッチでもいいと思っています。
いやエンジニアなら最先端の技術を使ってなんぼという意見もあるとは思うし、まさにその通りだと思います。スキルも上がるし、成果物の質も高いものが納品できる可能性が高いので。
この辺の話をしていると書き切れる気がしないので、気が向いたら記事にしてみます。

既存webpack構成

スタイルはデザイナーや運用チームも利用することがあるので、Sassは引き続き利用することにしました。
CSS-in-JSなど他の手法もあるのですが、おそらくいまの社内状況だと触る人が限られてしまい
属人的になりそうなので今回は据え置きにしました。
このあたりも要件や規模によって最適なツールを選定できるように、社内メンバーのレベルアップも進めないといけないなと改めて感じます。

またクライアントによっては古いブラウザへの対応を求められていたこともありbabel-loaderなども組み込まれていたり、jqueryを使っていたりしていましたが、こちらは引き継がず削除しています。

最後に

本当はひとつの記事にまとめたかったのですが長くなりそうなのでこのあたりで一旦区切ろうと思います。
次回は実装のお話だったり、技術的な内容も混ぜて書いていく予定です。

こういった記事はいくつか見かけるのですが案件の規模だったり、社内の内情が違うのでベストな選択は環境によって異なってくると思ってます。
なのでレガシーな環境の案件もあったり、社内の内情もあったりする中で試行錯誤している方の参考になったり後押しができればいいなと思います。
最後まで読んでいただきありがとうございました！