inspiration

LINEヤフー Tech-Verse2025 Day2

2025年 07月 01日
14分

LINEヤフー Tech-Verse2025 Day2

Tech-Verse 2025、2日目のレポートです。本日はフロントエンドの発表がありました。Core Web VitalsとNext.jsに関するテーマがあり、嬉しく思いました。

本日取り上げる4つのセッションは以下の通りです。

  1. アクセシビリティ改善の実践：プロダクトにおける具体的な取り組みと課題
  2. 数字が導く洞察：Webパフォーマンスとビジネス指標の相関を探る
  3. 「Yahoo! JAPAN Search」におけるWebパフォーマンス改善の取り組み
  4. Next.js App RouterへのマイグレーションとK8sで見つけた最良のソリューション

1. アクセシビリティ改善の実践：プロダクトにおける具体的な取り組みと課題

最初のセッションでは、LINEヤフーのウェブアクセシビリティチームとLINEギフト、Yahoo! JAPAN検索チームが、ユーザーのアクセシビリティ改善のための具体的な取り組みを共有しました。

LINEギフトのアプローチはボトムアップ型プロジェクトで、デザイン、開発、QA、企画など様々な役割の担当者が集まり、主導的に改善を推進したそうです。主な改善点としては、画像に対する代替テキスト(alt text)の欠落防止システムの構築、下部タブUIの音声案内の改善や視認性向上のためのコントラスト比の調整、そして5秒以上続くアニメーションの自動停止機能の導入などがありました。特にアニメーション関連で「集中力に問題があるユーザーの妨げになる可能性がある」という点を共感してもらうため、日常的な例を挙げてコミュニケーションを取った点が印象的でした。

Yahoo! JAPAN検索の取り組みは、レガシーコードのリファクタリング経験から始まりました。デザイナーが直接コードを扱う開発文化のおかげで、UI/UXと技術的実装を共に考慮したアプローチが可能でした。Lintの導入によるマークアップ検査、altテキストの正しい使用の誘導、スクリーンリーダーの読み上げ順の改善、そして再利用可能なコンポーネントやユーティリティ関数の開発が核心でした。検索サービスはユーザー数が非常に多いため、修正のデプロイに困難が伴うことがありますが、地道に改善を進めているそうです。

LINEヤフーウェブアクセシビリティチームは、過去にLINEとYahoo!がそれぞれ持っていたアクセシビリティガイドラインを統合し、これを全社に普及させることに注力しました。ガイドラインを10個に分割して月例説明会を開催するなど、実質的な理解度を高めるための努力を傾けました。究極的な目標は、個々のプロダクトが自律的にアクセシビリティを改善する文化を作ることだと強調しました。

このセッションは、組織的な違いにもかかわらず、ボトムアップのアプローチ、地道な改善努力、そして活発な知識共有がアクセシビリティ文化の拡散に重要であるという共通のメッセージを伝えました。

2. 数字が導く洞察：Webパフォーマンスとビジネス指標の相関を探る

2番目のセッションでは、ウェブパフォーマンスとビジネス指標との相関関係を深く分析しました。

最も際立った洞察は、LCP(Largest Contentful Paint)が速いほどコンバージョン率(CVR)が高まる傾向が見られるという点です。特に1.5秒以下のLCPは、2.5秒という一般的なCore Web Vitalsの推奨基準よりもはるかに大きなビジネスインパクトをもたらすと強調しました。これは単にページの読み込み速度が速いということを超え、ユーザー体験がビジネス成果に直接的な影響を与えることを示しています。

また、**直帰率(Bounce Rate)と離脱率(Exit Rate)**は、ページの読み込み速度と強い逆相関関係を示しました。ページの読み込みが遅いほど、ユーザーが即座に離脱したり、ページを去る確率が高くなるということです。一方、CLS(Cumulative Layout Shift)とINP(Interaction to Next Paint)はCVRとの相関関係が比較的に弱く現れましたが、ユーザー体験の側面では依然として重要であると述べました。

このような分析のために、最小限のコードで実装可能な計測ライブラリを提供して容易にデータを収集し、Tableauを活用したダッシュボードで視覚化、ウェブパフォーマンスチームが技術コンサルティングを支援する全社的な支援体制を構築しました。

パフォーマンス改善のためのヒントとしては、クリティカルレンダリングパスの理解、HTMLパースを妨げる要素の除去（preload, async/deferの使用）、CSS/JSの最適化などフロントエンド技術と共に、高速なバックエンド応答時間(TTFB)、コンピューティング負荷の削減、CPUプロファイリングの活用などバックエンド最適化の重要性を強調しました。最後に、将来的にはLLMとソースコードを活用してAIベースのパフォーマンス最適化提案を自動化する研究を進めていると明かし、期待を集めました。

私もSEOチームで働いていた時にLCPやCLSを改善する作業を経験したことがあったので、より理解が深まり、共感できるセッションでした。

3. 「Yahoo! JAPAN Search」におけるWebパフォーマンス改善の取り組み

3番目のセッションでは、Yahoo! JAPAN検索チームのCore Web Vitalsを活用したウェブパフォーマンス改善事例を詳しく共有しました。Yahoo! JAPAN検索は、クエリによって画面に表示される内容が多様に変化する特性のため、パフォーマンス改善においてさらに複雑な課題を抱えているそうです。

Core Web VitalsCore Web Vitals
Yahoo! JAPAN検索チームは**LCP(2.5秒未満推奨)、INP(200ms未満推奨)、CLS(0.1未満推奨)**といったCore Web Vitals指標を通じて定量的にパフォーマンスを測定しており、これらの指標改善は単にSEOのためだけでなく、ユーザー体験の向上に重点を置いています。実際にパフォーマンス数値が良くなると、クリック数やインプレッション数が増加し、ユーザーがクリックしない割合が減少する傾向を確認したそうです。

パフォーマンスの可視化のために、**ラボデータ(Lab data)とフィールドデータ(Field data)**の両方を活用しています。ラボデータは制御された環境で代表的なクエリに対して測定し、改善点を見つけ出すのに有用であり、フィールドデータは実際のユーザーのブラウザから収集され、実際のパフォーマンス状況を把握するために使用されるそうです。また、ダッシュボードを通じてクエリ領域別のパフォーマンス推移を把握し、問題のある領域を特定してHTML要素レベルまで分析するとのことです。

具体的な改善事例としては、人物情報領域で共通して発生するレイアウトシフトを特定し、Lighthouseツールで確認して修正したことや、地域情報クエリでLCPを低下させる大きな画像要素を特定して最適化したことなどが挙げられました。

4. Next.js App RouterへのマイグレーションとK8sで見つけた最良のソリューション

最後のセッションでは、LINE Plusのコンテンツサービスウェブチームのチョン・ギュソン氏とチョ・ジョングン氏が、Open ChatサービスのNext.js App Routerへの移行およびKubernetes(K8s)導入の経験を共有しました。Open Chatは日本、タイ、台湾で提供されている匿名チャットサービスで、LINE本体だけでなく、複数のウェブサービスで構成されています。

Multi TenancyMulti Tenancy
既存のJenkinsベースのデプロイ方式の限界（サービスごとのサーバー構成、環境管理の困難さ）を克服するため、Kubernetesのマルチテナンシー(Multi-Tenancy)戦略を選択したそうです。これは一つのクラスター内にネームスペースを通じてリソースを論理的に分離し、リソースの隔離、トラフィックの分離、運用およびモニタリングの効率を高める方式で、PhaseとStageという概念を導入して環境やバージョンの管理を細かくできるそうです。デプロイツールとしてはHelm ChartとArgoCDを活用したとのことです。

what Nextjswhat Nextjs
そして、Next.js App Routerへのマイグレーションは、FCPとLCPの改善によるユーザー体感性能の向上を目標としたそうです。そのため、既存のCSR処理をHybrid CSRとSSRに変更したとのことです。実際のマイグレーションの結果、FCPは61%、LCPは78%改善されるという劇的な効果を得たそうです。
デプロイ時には、DockerコンテナとStandalone Buildを活用して必要な依存関係のみを抽出し、静的ファイルはCDNにアップロードすることで、イメージサイズを94%(10GBから600MB)削減することに成功したそうです。

マイグレーション過程で経験した主な問題と解決策も共有されました：

  • ページ遷移アニメーションの問題: コード分割による遷移遅延。解決策: Linkコンポーネントのprefetch機能を積極的に活用して事前にページを読み込む。
  • タブUIの状態維持の問題: タブ切り替え時のサーバーサイドAPIの繰り返し呼び出しとスクロール復元の問題。解決策: 初回アクセス時のみSSRを行い、その後のタブ変更はクライアントサイドレンダリング(CSR)で処理し、router.replaceの代わりにNative History APIを使用してページをリロードせずにURLを書き換える。
  • Server Actionのバージョンの問題: リファクタリングやビルド環境の変更時にServer Action IDが変更されて発生するエラー。解決策: デプロイ時に旧バージョンのServer Actionを維持し、NEXT_SERVER_ACTIONS_ENCRYPTION_KEY環境変数を設定してビルド間で一貫したIDを維持し、将来的にはスティッキーセッション方式の導入を検討。

将来的には、マルチコンテナK8s環境でのインメモリキャッシュの分散問題を解決するため、Redisのような外部ストレージにキャッシュを統合する方策を模索中だと述べました。

やはりNext.jsがテーマだっただけに、最も理解しやすい発表でした。現在働いている場所でもDocker + AWSでサービスを提供しているので、Standalone Buildに切り替えてイメージサイズを削減する方法を導入したことがあり、驚きました。
また、prefetchを活用することは以前SEOチームで試したことがあったので、発表を聞きながら私も色々やってみた記憶が思い出しました。

本日共有されたフロントエンドのセッションは、ユーザー体験と開発生産性の向上に関するものが多かったです。特にCore Web Vitalsに関連するものが多かったですね。やはりフロントエンドはユーザー体験が最優先のようです。

🔗 出典

アクセシビリティ改善の実践:プロダクトにおける具体的な取り組みと課題
数字が導く洞察：Webパフォーマンスとビジネス指標の相関を探る
「Yahoo!検索」におけるWebパフォーマンス改善の取り組み
Migration to Next.js App Router