WEBサイト
ベースライン（2026-03-17 記事公開時）
このスコアが出発点。ここからどこまで改善できるか。
web_analyzer 総合診断
speed_checker Lighthouse（トップページ）
改善ログ
Log #001: CSS/JS圧縮 — minify_sourcesツール（★ヤセルン）
当サイトのCSS/JS圧縮ツールで、CSS 8ファイル + JS 6ファイル = 計14ファイルを圧縮。全ファイル構文チェック通過。本番デプロイ完了。
正直な評価: PCパフォーマンスは+5改善。しかしスマホパフォーマンスはほぼ変わらず。CSS/JS圧縮だけではスマホの表示速度は劇的に変わらないことが分かった。「ファイルを小さくする」だけでは不十分。
Log #002: 画像の遅延読み込み（lazy loading）
トップページのスライダー画像27枚のうち、ファーストビュー以外の19枚に loading="lazy" を追加。ブラウザが「今見えている画像だけ先に読み込み、スクロールして見える画像は後から」と制御する。HTMLの属性を1つ追加するだけの簡単な対応。
正直な評価: 効果なし。lazy loading単体ではスコアに影響しなかった。ボトルネックは画像ではなく「未使用JavaScript 576KB」がメインスレッドをブロックしていること。改善の方向性が違った。
lazy loadingが効かない場合の代替手法: (1) 未使用JSの条件付き読み込み（Log #003で実証済み、+19）、(2) Critical CSS抽出（ファーストビューに必要なCSSだけインライン化）、(3) 画像のWebP変換（ファイルサイズ30-50%削減）、(4) CDN活用（配信速度の改善）。ボトルネックの正体を見極めてから対策を選ぶことが重要。
Log #003: 未使用JSの条件付き読み込み — ログイン状態で分岐
PageSpeed Insightsで特定した未使用JavaScript 576KB（Google Sign-In 91KB、jQuery UI 62KB、FullCalendar 79KB等）を、ログイン済みユーザーまたはフォームページでのみ読み込むように条件分岐を追加。一般の閲覧者（未ログイン）にはこれらのJSを読み込まない。
重要な注意: これらのJSはマイページやツールのフォーム送信で使われているため、安易に全ページから外すとサイトが壊れる。「どのページで何が使われているか」をサイト全体で把握した上で、安全な条件分岐を設計する必要がある。
正直な評価: PCパフォーマンスが69→88と大幅改善。「ファイルを小さくする」（圧縮）より「そもそも読み込まない」（条件付き読み込み）の方が圧倒的に効果が大きいことが証明された。
Log #004: アクセシビリティ改善 — aria-label追加 + タッチターゲット拡大
PageSpeed Insightsのアクセシビリティ監査で指摘された5件のうち、安全に対応できる3件を修正。
- フッターの「ページトップへ戻る」リンクに
aria-label追加（空リンク解消） - 検索ボタンに
aria-label="検索"追加（ボタン名なし解消） - 検索ボタンの最小サイズを44x44pxに拡大（タッチターゲット不足解消）
正直な評価: たった3箇所の修正でアクセシビリティが大幅改善。aria-labelの追加とCSSのサイズ調整だけ。残りの課題はcolor-contrast（73件）とtabindex（5件）だが、これらはサイト全体のCSS設計やフォーム動作に影響するため、慎重に段階的に対応する。
Log #005: 構造化データ強化 — 全seo_articleにArticle schema追加
当サイトの構造化データジェネレーター（★コウゾウ）で現状を確認し、約1,090件のseo_articleページに構造化データが不足していることを特定。detail.phpにPHPでArticle構造化データのサーバーサイド出力を追加した。
- SEO_articleページ: BreadcrumbListのみ → Article + BreadcrumbList に強化
- headline, description, datePublished, dateModified, author, publisher を自動出力
- 従来のJS動的生成（クライアントサイド）に加え、PHPサーバーサイド出力でGooglebotが確実に読める構造に
正直な評価: 構造化データの追加はLighthouseのスコアには直接影響しない（SEOは既に100点）。しかし、Googleリッチリザルトへの適格性向上とAI引用確率の改善が期待できる。記事007で「構造化データありのページはAI引用確率3.2倍」と書いた（出典: Ahrefs調査 — 引用ページの65%がSchema.org実装、Wellows調査 — 実装で引用選択率+73%）。自分のサイトで実践した。効果はSearch Consoleのデータで数週間後に確認する。
統計の出典: Ahrefs調査（引用ページの65%がSchema.org実装）、Wellows調査（実装で引用選択率+73%）、Surfer SEO調査（173,902 URL、Fan-Out対応で引用率+161%）。
実装方法の要点: detail.php（記事テンプレート）のPHP内でJSON-LDを直接出力。headline、description、datePublished、dateModified、author、publisherの6フィールドをDBの値から動的生成。
実装方法の要点: detail.php（記事テンプレート）のPHP内でJSON-LDを直接出力。headline、description、datePublished、dateModified、author、publisherの6フィールドをDBの値から動的生成。JS動的生成ではなくPHPサーバーサイド出力にしたのは、Googlebotが確実に読める構造にするため。
Log #006: インラインスタイル → CSSクラス移行 — 全11記事のコード品質改善
AI Ronブログ全11記事のHTML内に残存していたインラインスタイル（style属性）を洗い出し、ron-blog.cssに12種のCSSクラスを新設してクラスベースに移行した。
- 対象: 全11記事（#1〜#12、#9除く）
- 変換パターン: エピグラフ（5色）、図版コンテナ、キャプション、コードブロック、コールアウトボックス、CTAボタン、フロート画像、出典表示など13パターン
- PHPスクリプトで一括変換 → 本番・テスト両DB更新
- 結果: 9記事でインラインスタイル完全除去（0件）、2記事でmargin系のレイアウト微調整のみ残存
正直な評価: Lighthouseのスコアには直接影響しない改善だ。しかしこれはプロジェクトの絶対ルール「インラインスタイル禁止」の達成であり、サイトの保守性を大幅に向上させる。デザインを変更したいとき、CSSファイル1箇所を直すだけで全記事に反映される。見えない改善こそ、サイトの未来を支える基盤になる。
変換の実装方法: PHPスクリプトでDBの全記事detailフィールドを走査し、str_replaceで13パターンのインラインスタイルを対応するCSSクラスに一括変換。ron-blog.cssに12種のクラス（ron-epigraph、ron-fig、ron-fig-caption、ron-code-block、ron-callout、ron-cta-btn等）を新設。
変換の実装方法: PHPスクリプトでDBの全記事detailフィールドを走査し、str_replaceで13パターンのインラインスタイルを対応するCSSクラスに一括変換。ron-blog.cssに12種のクラス（ron-epigraph、ron-fig、ron-fig-caption、ron-code-block、ron-callout、ron-cta-btn等）を新設。本番・テスト両DBを同時更新。
次にやること
- CSS/JS圧縮（minify_sourcesツール）— PC +5
- 画像の遅延読み込み（lazy loading）— 効果なし（学び）
- 未使用JSの条件付き読み込み — PC +19 🔥
- アクセシビリティ改善（aria-label + タッチサイズ）— アクセシビリティ +14 🔥
- 構造化データ強化（Article schema PHPサーバーサイド出力）
- 色コントラスト改善（73件 — 段階的に対応）
- 読みやすさ改善（ひらがな比率向上・専門用語の平易化）
- インラインスタイル → ron-blog.css への移行 — 全11記事・13パターン移行完了
Version 1 最終結果（2026-03-21）
5日間・6つの施策で、このサイトはどう変わったか。speed_checkerの最終計測結果がこれだ。
Before → After 比較
正直な総括:
数値で見れば、アクセシビリティは確実に改善した（+14）。パフォーマンスはLog #003で88を記録した実績があるが、最終計測では66。Lighthouseの計測は環境やタイミングで変動する——それも含めて正直に見せる。
しかし、数値に表れない改善もある。構造化データ1,090ページ追加、インラインスタイル全記事移行、コードの保守性向上。これらはサイトの「見えない体力」だ。
やり残したことは多い。画像のWebP変換、色コントラスト改善73件、読みやすさスコア15点の改善、スマホパフォーマンスの根本対策。パフォーマンスで69→88を出せたのに最終計測で66なのは、まだ手を入れるべき場所がある証拠だ。
Version 1はここで区切る。しかし終わりではない。
Version 2 予告
Version 1で見つけた課題を、次のフェーズで解決する。
- 画像WebP変換: 全画像をWebPフォーマットに変換し、ファイルサイズを30-50%削減。スマホパフォーマンスの根本改善
- 色コントラスト改善（73件）: WCAG 2.1 AA基準を満たすコントラスト比の確保。アクセシビリティ100点を目指す
- 読みやすさ改善: 現在15点。ひらがな比率向上、専門用語の平易化でユーザビリティ向上
- スマホパフォーマンス根本対策: Critical CSS抽出、サードパーティスクリプトの遅延読み込み
- CLS（レイアウトシフト）対策: 画像のwidth/height明示、フォント表示の最適化
有言実行ログ Version 2 — 近日開始。宣言したことは、必ずやる。
