ウェブサイト「みんなのBaaS」をリニューアルした話

2024年9月7日 15時0分

デジタルバンク「みんなの銀行」のマーケティンググループオウンドチームでは、ウェブサイト「みんなのBaaS」のリニューアルを行いました（https://baas.minna-no-ginko.com/）。

みんなの銀行では、個人向け金融サービスを提供する一方で、パートナー企業の皆さまにAPI（※）を通じてみんなの銀行の金融機能やサービスを提供するBaaS（Banking as a Service）事業では、「金融」と「非金融」がシームレスに結びついた新たな価値の共創を目指しています。

※Application Programming Interfaceの略で、銀行と外部の事業者との間の安全なデータ連携を可能にする仕組みのこと。

BaaS本格スタートとなる2024年度、金融サービスの導入を検討中もしくはこれから検討する事業者の皆さまに「BaaSの活用イメージ」をより分かりやすくお伝えしていくために、マーケティンググループオウンドチームでは、ウェブサイト「みんなのBaaS」のコンテンツを拡充しました。

この記事では、サイトリニューアルにあたっての課題や技術選定、実際に導入してどうだったかについて、フロントエンドエンジニア目線でお話しできればと思います。

リニューアル前：ウェブサイト「みんなのBaaS」の課題

リニューアル前のウェブサイト「みんなのBaaS」は慣性スクロールとGSAPを使ったワンページのウェブサイトでした。

開設当時からいくつかの経緯を経て、全体的に表示速度が遅いことが悩みでした。体感だと2秒くらい待ってしまいます。そこがボトルネックとなって離脱による機会損失が生じていたのは自明の理です。

少し古いものとなりますが以下の『Think with Google』の記事では、ページの表示速度が1～3秒の場合は離脱率が32%。1～5秒の場合は90%、1～6秒の場合は106%、1～10秒の場合は123%上昇することが書かれています。
https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/

モットーは「より早く、より見やすく、よりストレスフリーに」

マーケティンググループオウンドチームでは、「より早く、より見やすく、よりストレスフリーに」をモットーにウェブサイトづくりに取り組んでいます。このモットーを貫くべく、技術選定を行いました。

技術選定とSvelteKitを採用したその理由

プレーンなHTML・CSS・JS（JavaScript）

これらは原始的で直観的ではあるものの、目指す方向とは異なり簡易的となるため、除外しました。

MPAフレームワーク

コンテンツを拡充する今回のサイトリニューアルでは、SPAフレームワークではなく、有名どころのMPAフレームワークAstroが有効ではあるものの、Astroはコンテンツ量に対しての機能量がマッチする印象を受けなかったため、除外しました。

JSフレームワーク

JSフレームワークには、Nuxt、Next、qwick等の複数の選択肢がありますが、今回は今後のことも鑑みて、癖が少なくまた知見のあるSvelteKitを採用しました。ちなみに2024年6月にオープンしたみんなの銀行採用サイト（https://corporate.minna-no-ginko.com/careers/）も、Svelte + esbuildを採用しています。

JSフレームワークは、非フロントエンドエンジニアから見ても、分かりやすいコンポーネントを作ることができます。

またルーティングも、ディレクトリ構成で定義されるため、非常に分かりやすいです。

実際にSvelteKitを導入してみて

大きな点として、アクセシビリティにおいてA11yという指標に達成していないと開発時に警告を出してくれるため、Lighthouse上で容易に高いスコアが出せました。

他のスコアも、サードパーティスクリプト（外部のプロバイダや開発者によって提供されるJavaScriptコード）の影響はあれど、悪くはない数字を出すことができました。いわずもがな表示速度の遅さ・遷移時のわずらわしさは、当初の狙い通り解消されました。

また、副次的な効果もありました。

あらかたコンテンツの実装が終わった時に、表示速度を遅くするLCP（Largest Contentful Paint）改善のために、画像の出し分けをRetina（高解像度でハイコントラストな色彩表現を可能としたディスプレイ） / 非Retinaで行う必要が出てきました。

手動で画像を管理するには、デザイナーの工数や手戻り、Retinaは対応したのに非Retina画像の差し替えが漏れていたなどのリスクが発生します。

Svelteの公式ライブラリとしてリリースされているものに、「@sveltejs/enhanced-img」という画像最適化ライブラリがありますが、これを採用した結果、次世代画像フォーマットであるAVIF、webP等の拡張子に対応しているブラウザに見合った画像でローディングしてくれるようになりました。

それにより社内のデザイナーに拡張子画像の生成を依頼する必要がなくなり、HTML側でsrcsetを書く必要もなくなり、シンプルになりました。

また画像の置き場をsource(src)配下にすることで、どの画像が加工されているかも明白になりました。これによって運用時にも画像を1つ連携するだけで済みます。