あるECサイトの話をしましょう。売上が伸び悩んでいた通販会社が、サイトのリニューアルを検討していました。デザインは5年前に作ったもので、少し古臭く感じる。商品写真も追加していくうちに、どこか雑然とした印象になってしまった。「デザインを刷新すれば、売上が回復するのではないか」と考えたのです。
リニューアルを依頼された私たちは、まず現状のサイトを詳しく分析しました。すると、デザインよりも深刻な問題が見つかりました。トップページの表示に4.8秒かかっていたのです。
商品ページはさらに遅く、6秒を超えることもありました。ユーザーは商品を見る前に離脱し、検索エンジンからの評価も下がり、広告費をかけても成果につながらない状態でした。
デザインを変えるだけでなく、サイトの根本的な構造を見直し、コードを一から書き直した結果、表示時間は0.8秒にまで短縮されました。デザイン自体は「少しすっきりした」程度の変更でしたが、3ヶ月後には月間売上が31%増加しました。
この記事では、ユーザーには見えないけれど、ビジネスの成果を大きく左右する「コーディング品質」について、詳しく解説します。
なぜ「見えない」コードが売上を左右するのか
ホームページのソースコードを直接見るユーザーは、ほぼゼロです。「見た目さえきれいなら、コードなんてどうでもいい」と考えるのは、ある意味で自然なことかもしれません。
しかし、コードの品質はユーザー体験に直接影響します。そしてユーザー体験は、そのまま売上に直結します。
具体的な数字を見てみましょう。Googleの調査によると、ページの読み込み時間が1秒遅くなるごとに、コンバージョン率は7%低下します。つまり、表示に3秒かかるサイトは、1秒で表示されるサイトと比較して、約14%のコンバージョンを失っていることになります。
さらに衝撃的なのは直帰率への影響です。ページの読み込み時間が2秒増えると、直帰率は103%増加します。つまり、待たされたユーザーの半数以上が、ページを見ることなく離脱しているのです。
別の調査では、表示速度が1秒のサイトは、5秒かかるサイトと比較してコンバージョン率が2.5倍高いというデータもあります。
これらの数字が意味することは明確です。コードの品質が低い、つまり表示が遅いサイトは、来てくれたはずの顧客を逃し続けているということです。デザインがいくら美しくても、表示される前にユーザーがいなくなってしまっては意味がありません。
品質の低いコードが生まれる理由
なぜ、パフォーマンスの悪いサイトが生まれてしまうのでしょうか。それは多くの場合、悪意ではなく構造的な問題から生じています。
最も多いパターンは、サイトの「積み重ね」です。最初は軽量だったサイトに、新しい機能が追加されるたびにプラグインがインストールされ、新しいフォントが読み込まれ、新しいスクリプトが追加されます。一つひとつは小さな追加でも、5年、10年と積み重なると、膨大な量のコードがサイトを重くしています。
特にWordPressサイトでこの問題は顕著です。便利なプラグインを次々と追加した結果、プラグイン同士が競合したり、使っていないプラグインが残ったままになったりして、サイトが肥大化していきます。
もうひとつのパターンは、コスト優先の制作です。「できるだけ安く」という要望に応えるため、既存のテンプレートやプラグインを組み合わせて「とりあえず動く」サイトが作られます。動作確認はされていても、パフォーマンスの最適化には時間も予算もかけられていません。
さらに、技術力の問題もあります。残念ながら、すべてのWeb制作会社が高いパフォーマンスを実現する技術を持っているわけではありません。見た目は作れても、高速で動作するサイトを作る知識がない制作者も少なくありません。
品質の低いコードの典型的な症状
自社サイトのコード品質が低いかどうか、いくつかの典型的な症状から判断できます。
最もわかりやすいのは、ファイルサイズの肥大化です。HTTP Archiveの調査によると、平均的なWebページのサイズは年々増加しており、現在はモバイルで約2.3MBに達しています。しかし、適切に最適化されたサイトであれば、同等のコンテンツを500KB以下で表示できることがほとんどです。
肥大化の原因として多いのは、まず未圧縮の画像です。デジタルカメラやスマートフォンで撮影した画像をそのままアップロードすると、1枚で2MBから5MB以上になることもあります。次に使っていないCSSやJavaScriptの読み込みがあります。多機能テーマを使うと、使っていない機能のコードまで読み込まれます。重複したライブラリの読み込みも問題です。複数のプラグインがそれぞれ同じライブラリを読み込んでいるケースがあります。最適化されていないWebフォントも要因のひとつです。日本語フォントは数千文字を含むため、全部読み込むと非常に重くなります。
次の症状はレンダリングブロックです。これは、ブラウザがページを表示するまでの間、JavaScriptやCSSがブロックとなって待たされる状態です。ユーザーは画面が真っ白なまま何秒も待たされ、ストレスを感じます。
原因としては、headタグ内に大量のスクリプトが記述されている場合があります。本来は後から読み込んでもいいスクリプトが、ページの表示を妨げています。また、非同期読み込みがされていないJavaScriptの問題もあります。asyncやdeferといった属性を使えば、ページ表示と並行してスクリプトを読み込めますが、それが設定されていません。さらにCritical CSSの未抽出があります。ファーストビューに必要な最小限のCSSだけを先に読み込むテクニックが使われていません。
レイアウトシフトも典型的な症状です。これは、ページ読み込み中にコンテンツが「ガクン」と動く現象です。読もうとした記事が突然下に移動する。押そうとしたボタンが別の場所に飛ぶ。このような体験は、ユーザーの信頼を一瞬で失わせます。
主な原因は、画像のサイズ（width/height）が未指定になっていることです。ブラウザは画像の読み込みが完了するまでサイズがわからず、読み込み完了時にスペースを確保してレイアウトが崩れます。動的に挿入される広告も問題になります。広告スペースが事前に確保されていないと、広告が読み込まれたときに周囲のコンテンツが押し下げられます。Webフォント読み込み時のフラッシュも原因のひとつです。システムフォントからWebフォントに切り替わるとき、文字サイズや行間が変わってレイアウトが動きます。
アクセシビリティの問題も、コード品質の低さを示す症状です。視覚障害のある方、キーボードのみで操作する方が使えないサイトは、適切なHTML構造で作られていないことを意味します。そしてこれは、SEOにも悪影響を与えます。
よくある問題として、画像のalt属性がないか不適切なケースがあります。スクリーンリーダーを使うユーザーに画像の内容が伝わりません。フォーカス可能な要素がキーボードで操作できない問題もあります。マウスが使えないユーザーはサイトを利用できません。色のコントラスト比が不十分だと、色覚に特性のあるユーザーや、明るい場所でスマートフォンを使うユーザーにとって読みづらくなります。見出し構造が適切でない、たとえばh1からh3に飛んでh2がないような構造は、コンテンツの論理構造が壊れています。
高品質なコードの特徴
では、高品質なコードとはどのようなものでしょうか。いくつかの重要な特徴があります。
まず、セマンティックHTMLの使用です。HTMLには、それぞれ意味を持った要素があります。ナビゲーションにはnav要素、記事にはarticle要素、ヘッダーにはheader要素を使うことで、検索エンジンやスクリーンリーダーがコンテンツの意味を正しく理解できます。
悪い例として、すべてをdiv要素で作るパターンがあります。div class="header"の中にdiv class="nav"があり、その中にdiv class="button"がある、というような構造です。これでは、どこがヘッダーなのか、どこがナビゲーションなのか、機械には判断できません。
良い例では、header要素の中にnav要素があり、その中にbutton要素がある構造になります。見た目は同じでも、意味が明確に伝わります。この違いは、SEOにも、アクセシビリティにも影響します。
次に重要なのが、アセットの最適化です。
画像については、WebPやAVIFといった最新フォーマットの使用が挙げられます。同じ画質のJPEGと比較して、30%から50%ファイルサイズを削減できます。レスポンシブ画像の実装も重要です。srcset属性を使って、デバイスの画面サイズに応じた適切なサイズの画像を配信します。1920px幅の画像をスマートフォンに配信しても意味がありません。遅延読み込み（loading="lazy"）の活用も効果的です。画面に表示されていない画像は後から読み込むことで、初期表示を高速化できます。
CSSについては、未使用スタイルの削除が重要です。多くのサイトで、読み込んでいるCSSの50%以上が実際には使われていません。使われていないコードを削除するだけで、大幅な軽量化が可能です。Critical CSSの抽出とインライン化も効果的です。ファーストビューに必要なスタイルだけを抜き出してHTMLに直接記述することで、追加のリクエストなしに初期表示ができます。効率的なセレクタ設計も考慮すべきです。過度に複雑なセレクタは、ブラウザの処理時間を増加させます。
JavaScriptについては、コードスプリッティングがあります。サイト全体で使うコードを一度に読み込むのではなく、各ページで必要な部分だけを読み込みます。Tree Shakingも重要です。ライブラリをインポートするとき、使っている機能だけを抽出し、使っていないコードは除去します。defer/asyncによる非同期読み込みを使えば、JavaScriptの読み込みがページ表示をブロックしないようにできます。
そして、高品質なコードはパフォーマンス指標で測定可能な結果を出します。2024年現在のCore Web Vitalsの基準では、LCP（Largest Contentful Paint）が2.5秒以内、INP（Interaction to Next Paint）が200ミリ秒以内、CLS（Cumulative Layout Shift）が0.1以下であれば「良好」と判定されます。高品質なコードは、これらすべての指標で「良好」を達成します。
WordPressと手書きコードの実測比較
「WordPressは遅い」とよく言われますが、実際にどれくらいの差があるのでしょうか。私たちは、同じデザイン、同じコンテンツで、WordPressサイトと手書きコード（Next.js）のサイトを作成し、比較実験を行いました。
結果は明白でした。総ファイルサイズは、WordPressの標準テーマで2.4MBに対し、手書きコードでは380KBでした。約6分の1です。HTTPリクエスト数は、WordPressが47回に対し、手書きコードでは12回。初回表示時間（LCP）は、WordPressが3.8秒に対し、手書きコードでは0.9秒。PageSpeedのモバイルスコアは、WordPressが42点に対し、手書きコードでは97点。サーバー応答時間は、WordPressが680ミリ秒に対し、手書きコードでは15ミリ秒でした。
誤解のないように言っておくと、WordPressそのものが悪いわけではありません。WordPressは非常に柔軟で、適切に最適化すれば高速なサイトを構築することも可能です。しかし、多くのWordPressサイトでは、便利さと引き換えにパフォーマンスが犠牲になっています。
プラグインを追加するたびにJavaScriptとCSSが増える。テーマは汎用性を重視するため、使わない機能のコードも含まれている。データベースへのクエリが多く、サーバー応答時間が長くなる。これらはWordPressの構造的な特性であり、意識的に対策しなければ、サイトは自然と重くなっていきます。
自社サイトの品質を確認する方法
自社サイトのコード品質は、いくつかの無料ツールで客観的に確認できます。まず試していただきたいのは、Google PageSpeed Insights（pagespeed.web.dev）です。自社サイトのURLを入力するだけで、パフォーマンススコアと具体的な改善提案が表示されます。
特に注目すべきはモバイルスコアです。デスクトップとモバイルで別々のスコアが表示されますが、日本では検索の82%がモバイルから行われているため、モバイルスコアがビジネスに直結します。モバイルスコアが50点以下なら、明らかに改善が必要です。70点以下でも、改善の余地があると考えてください。90点以上であれば良好です。
Google Search Consoleも有用です。「ウェブに関する主な指標」レポートで、実際のユーザーデータに基づくCore Web Vitalsの評価を確認できます。PageSpeed Insightsはシミュレーションですが、Search Consoleは実際のユーザー体験を反映しています。
Chrome DevToolsに内蔵されているLighthouseも便利です。ブラウザの開発者ツールから直接、パフォーマンス、アクセシビリティ、SEO、ベストプラクティスを評価できます。ローカル環境でのテストや、より詳細な分析に適しています。
より詳細な分析にはWebPageTest（webpagetest.org）を使います。世界各地のサーバーからテストを実行でき、詳細なウォーターフォールチャート（各リソースの読み込み順序とタイミング）を確認できます。「何が遅延の原因になっているか」を特定するのに役立ちます。
技術的負債という考え方
ソフトウェア開発の世界には「技術的負債」という概念があります。これは、短期的な利益（開発速度、コスト削減）を優先した結果、長期的に払い続けることになる「コスト」を指します。
低品質なコードは、まさにこの技術的負債です。借金と同じで、放置すると利子がついていきます。
まず、修正のたびに時間がかかるようになります。コードが複雑に絡み合っていると、小さな修正でも予期しない副作用が発生し、修正と検証に時間がかかります。
新機能の追加が困難になります。既存のコードがスパゲティ状態になっていると、新しい機能を追加するスペースがなく、追加しても既存機能と衝突する可能性があります。
セキュリティリスクが高まります。古いライブラリ、更新されていないプラグイン、脆弱な認証システムなど、技術的負債はセキュリティホールになりやすいです。
そして最終的には、フルリニューアルが必要になります。部分的な修正では対応できないほど問題が蓄積すると、ゼロから作り直すしかなくなります。
初期費用を抑えるためにコード品質を犠牲にすると、長期的には高くつきます。「安い制作会社に頼んで50万円節約したつもりが、3年後にフルリニューアルで150万円かかった」というケースは珍しくありません。
品質の高いサイトを手に入れるために
最後に、品質の高いサイトを手に入れるための具体的なアクションをお伝えします。
まず、自社サイトの現状を把握してください。Google PageSpeed Insightsで自社サイトをチェックし、モバイルスコアを確認します。表示速度が3秒以上かかっていないか、レイアウトシフトが発生していないか、スマートフォンで快適に操作できるかを確認してください。
制作会社を選ぶ際は、その会社が制作したサイトのパフォーマンスを確認してください。ポートフォリオに掲載されているサイトのURLをPageSpeed Insightsに入力すれば、その会社の技術力がわかります。制作会社自身のサイトが遅いようであれば、クライアントのサイトも遅い可能性が高いです。
既存サイトの改善を検討する場合は、まず現状診断から始めることをお勧めします。私たちは無料でサイト診断を実施しており、PageSpeedスコアだけでなく、Core Web Vitalsの各指標、問題の原因、具体的な改善策、改善による期待効果をレポートでお伝えしています。
「見えない」からこそ、コード品質は見過ごされがちです。しかし、その「見えない」部分が、ユーザー体験を決め、SEOを左右し、最終的には売上を左右しています。
自社サイトの裏側で何が起きているのか。この記事をきっかけに、一度確認してみてください。