copied!

3-shake Engineers’ BlogsのLighthouse Best Practicesを31点改善した話：パフォーマンス改善編

Natsubori Yuumi

2026.7.31

copied!

はじめに

この記事では、スリーシェイクが運営する技術ブログ「3-shake Engineers’ Blogs」において、Lighthouseスコアの改善のために対応したパフォーマンスと開発者体験の向上を目指した具体的な施策と、その結果についてご紹介します。

想定読者

Web開発者・エンジニア
- Lighthouseスコアの改善方法や具体的なテクニックを知りたいと考えている人
- 最新のWeb技術動向やベストプラクティスに関心のある人
Webサイト運営者・担当者
- 自社サイトのパフォーマンスやSEOに課題を感じており、具体的な改善策を探している人
- Lighthouseスコアの重要性を理解し、改善に取り組みたいと考えているが、何から手をつければ良いか分からない人
技術広報・採用担当者
- 企業の技術力や開発文化に興味を持ち、採用候補者へのアピール材料を探している人

Lighthouseスコアとは

Lighthouseは、Googleが提供するオープンソースのWebサイト品質評価ツールです。
Webページを自動的に分析し、0〜100点のスコアで評価します。

Lighthouseのスコア例（計測タイミング違い）

LighthouseスコアのAccessibilityにおける詳細例

評価カテゴリ

カテゴリ	評価内容
Performance	ページの読み込み速度・表示速度・応答性
Accessibility	コントラスト比、HTML構造の正しさ、スクリーンリーダー対応など
Best Practices	セキュリティ（HTTPS）、非推奨APIの使用有無など
SEO	メタタグ、モバイルフレンドリー、検索エンジンへの最適化

スコアの基準

スコア範囲	評価
🟢 90〜100	良好 (Good)
🟠 50〜89	改善が必要（Needs Improvement）
🔴 0〜49	不良（Poor）

優れたユーザーエクスペリエンスを提供するには、サイトのスコアを良好（90 ～ 100）にするよう努める必要があります。100 の「完璧」なスコアを達成するのは非常に困難であり、期待されるものではありません。たとえば、スコアが 99 ～ 100 の場合、90 ～ 94 の場合と同量の指標の改善が必要になります。

Performanceスコアの内訳

Performanceスコアは以下の指標の加重平均で算出されています（以下はLighthouse10のスコア）。

指標	内容	重み
TBT（Total Blocking Time）	マウスクリック、画面タップ、キーボード入力などのユーザー入力にページが応答できない時間の合計。	30%
LCP（Largest Contentful Paint）	ビューポート内の最大のコンテンツ要素が画面にレンダリングされるタイミングを測定。	25%
CLS（Cumulative Layout Shift）	ページのライフサイクル全体で発生した予期しないレイアウトシフトのレイアウト移動スコアの最大バーストを測定	25%
FCP（First Contentful Paint）	ユーザーがページに移動した後、ブラウザが最初の DOM コンテンツをレンダリングするまでに要する時間。ページ上の画像、白色以外の `<canvas>` 要素、SVGなどを含む。	10%
SI（Speed Index）	ページの読み込み中にコンテンツが視覚的に表示される速さ。	10%

このうち、LCPとCLSはCore Web Vitals（Googleが定義するユーザー体験の重要指標）
に含まれており、TBTもCore Web VitalsのINP（Interaction to Next Paintの略、インタラクティブ性の尺度。優れたユーザーエクスペリエンスを提供するには、ページの INP を 200 ミリ秒 以下にする必要がある）と強い相関があります。つまり、Lighthouseスコアの改善はCore Web Vitalsの改善にも関連があります。

背景

なぜLighthouseスコア改善に取り組んだのか

3-shake Engineers’ Blogsは、catnose氏のhttps://github.com/catnose99/team-blog-hub リポジトリをforkしてスリーシェイクの技術力を社外に発信する重要なチャネルという立ち位置として発足しました。

現在の3-shake Engineers’ Blogsのファーストビュー

作成当初の2020年はメンテナンスを行っていましたが、継続的にメンテナンスするメンバーが確立されておらず、Lighthouseスコアで特に、レンダリングブロックがパフォーマンスのボトルネックとなっていることが判明しました。

そこで今回は、ユーザー体験の向上だけでなく将来的な技術的負債を見据えた改善とチーム全体の開発効率と品質を担保するために取り組んだ対応を紹介します。

技術スタック

3-shake Engineers’ Blogsは以下の技術スタックで構成されています。
※ 技術スタックは2026年6月時点の構成です。計測時（2026/01）とは一部異なります。

カテゴリ	技術
フレームワーク	Next.js 15（Pages Router）
UI	React 19
言語	TypeScript 6
スタイル	SCSS（Sass）
パッケージマネージャ	pnpm 11
ランタイム	Node.js 24
ホスティング	GitHub Pages（静的エクスポート）
CI/CD	GitHub Actions

現状分析と課題

本記事のLighthouseスコアは以下の環境で計測しました。

項目	内容
計測ツール	Chrome DevTools Lighthouse
データ種別	ラボデータ（シミュレーション環境での計測）
計測モード	Navigation（ページ読み込み時の計測）
計測デバイス	デスクトップ
計測日	2026/01/22

ラボデータとは： Lighthouseがシミュレーション環境でページを読み込み、その結果をスコア化したもの。ネットワーク速度やCPU性能を一定の条件に固定して計測するため、
再現性が高く、改善の効果を比較しやすいという特徴があります。

一方、実際のユーザー環境（フィールドデータ）とは異なる場合があります。
フィールドデータを用いた検証は今後の取り組みとして予定しています。

改善対応前のLighthouseスコアは以下の通りでした。

Performance: 76
Accessibility: 87
Best Practices: 65
SEO: 92

特に、Performanceスコアが76点、Best Practicesスコアが65点という結果からユーザー体験の低下や、将来的な技術的負債に繋がる可能性を示唆していました。

運用を始めてから技術スタックの刷新を行っておらず、また、この3-shake Engineers’ Blogsにも多くのメンバーが参画したことによりパフォーマンスの懸念はありました。

改善策

これらの課題に対し、以下の３つの改善策を実施しました。

1. フォント・画像周りのセルフホスティング

課題

Google Fonts・Google Favicon サービスへの外部リクエストが LCP 悪化・サードパーティ Cookie 警告・実行時 404 の原因になっていた
ブラウザが <head> 内の外部 CSS を取得するまでページ描画を止めてしまうレンダリングブロッキングが生じていた

解決策

フォントは next/font/google で、ファビコンはビルド時スクリプトで、それぞれビルド時にセルフホストする方式に統一

_document.tsx で Google Fonts の外部 CSS を <link> タグで読み込んでいた。
// Before: _document.tsx
<link
href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;500;700&family=Roboto:wght@300;400;500;700&display=swap"
rel="stylesheet"
/>

// Before
font-family: "Roboto", "Open Sans", sans-serif;

next/font/google を使ってビルド時にフォントファイルをダウンロードし、自サーバーから配信する方式に変更した。

// After: _app.tsx
import { Roboto, Open_Sans } from "next/font/google";

const roboto = Roboto({
	weight: ["300", "400", "500", "700"],
	subsets: ["latin"],
	display: "swap",
	variable: "--font-roboto",
});

const openSans = Open_Sans({
	weight: ["400", "500", "700"],
	subsets: ["latin"],
	display: "swap",
	variable: "--font-open-sans",
});

export default function MyApp({ Component, pageProps }: AppProps) {
return (
	<div className={`${roboto.variable} ${openSans.variable} app-wrapper`}>
		...
	</div>
	);
}

CSSは変数参照に変更した

// After
font-family: var(--font-roboto), var(--font-open-sans), sans-serif;

取得できなかったファビコンは <img> タグごと出力しない設計で、事後 fallback ではなく事前除外に改善することで、404エラーを減らした

2. ツールチェーンの刷新とビルド最適化

課題

ライブラリが長期間更新されておらず、RSS フィード取得が逐次処理のためビルド時間が長く、CI も毎回フルビルドで遅い

解決策

Renovateを使って週1で各種ライブラリの更新を定期的に行った。
フィード取得を並列化（バッチ10件同時処理）し、GitHub Actions に Next.js ビルドキャッシュを追加してインクリメンタルビルドを高速化。
ts-node → tsx + ESM 化・pnpm 移行によりツールチェーンを整理し、TypeScript v6 対応や Renovate の自動更新で依存管理の手間を削減したことでDXの向上に貢献した。

以下が主な対応です。

変更内容	更新前	更新後	備考
パッケージマネージャ	yarn	pnpm	依存管理の効率化
TypeScript	v5	v6	最新バージョンへの追従
モジュール形式	CJS	ESM	feed v5のESM対応が契機
スクリプト実行	ts-node	tsx	ESM化に伴う移行
フォント読み込み	Google Fonts（外部CDN）	next/font/google（セルフホスト）	LCP改善・レンダリングブロック排除

3. 画像フォーマットの最適化（webp化）とスクリプト化

課題

アバター画像が PNG/JPG のまま管理されており、ファイルサイズが大きく転送コストが高かった
画面外の画像も初期ロード時に一括取得され、ネットワーク負荷が無駄に発生していた
メンバーが増えることでフォーマット変換が手動で行う形式だと、変換の抜け漏れが発生する可能性がある

解決策

cwebp を使った WebP 変換スクリプト（build:avatars）をビルドパイプラインに組み込み、PNG/JPG を自動で WebP に変換することでメンバーが増えても抜け漏れを防ぎ、READMEにもその手法を掲載した
<img> に loading="lazy" を追加し、画面外画像の遅延読み込みで初期ロードの負荷を軽減
CI（GitHub Actions）に webp システムパッケージをインストールするステップを追加し、ローカルと同じ変換がデプロイ時にも再現できるよう整備

結果

これらの改善策の結果、Lighthouseスコアは以下の通りでした。（2026/06時点）

Performance: 95 (+19)
Accessibility: 87 (維持)
Best Practices: 96 (+31)
SEO: 92 (維持)

特に、Performanceスコアは目標としていた85点を大きく上回り、Best Practicesスコアも大幅に改善しました。フォントのセルフホスティングで LCP 警告が解消され、ファビコンのビルド時取得でサードパーティ Cookie 警告が消えたことが Best Practices スコア改善の主な要因です。

まとめ

今回のLighthouseスコア改善は、パフォーマンスチューニングの重要性と、そのための具体的な手法に取り組めるよいきっかけでした。

個人的にWebサイトの運用はかなり久しぶりの経験だったため、特にレンダリングブロックの特定と解消、セルフホスティング戦略、そして開発者体験向上のためのツール導入は、今後の開発においても活かせる貴重な経験となりました。

また、今回はデスクトップ環境での計測に絞りましたが、次のステップとしてモバイル環境での計測に取り組んでいく予定です。パフォーマンス改善と並行して、UI/UXの刷新も視野に入れており、引き続き改善を重ねていきます。

ブラウザの外で WebAssembly を動かして見えたコンテナとの違いと実用上の課題