サイトの表示が遅いのは、デザインの問題か開発の問題か？この問題は、企業サイトを運営するほぼすべての人が遭遇します。経営者が公式サイトを開いて5秒間読み込みが続くと、まず「サーバーが悪いのではないか」と考えます。しかし実際には、サーバーは一部に過ぎず、デザインと開発がそれぞれ大きな割合を占めます。
典型的な事例を見たことがあります。設備会社の公式サイトがリニューアル後、トップページの表示が2秒から8秒になりました。経営者はデータセンターの問題だと思い、2社のサーバーに切り替えましたが、依然として遅いままでした。最終的に判明したのは、デザインカンプのトップページに高解像度の大きな画像が12枚配置され、開発が圧縮と遅延読み込みを実装していなかったため、ファーストビューで一度に30以上のリソースをリクエストしていたことでした。
したがって、この問題は直感で答えることはできません。以下、調査手順に沿って分解して説明します。
一、まず「遅い」の3つのタイプを区別する
表示が遅いといっても一種類の症状ではなく、少なくとも3つに分かれます。
- ファーストビューの白画面が長い：リンクを開いてから長時間真っ白で、通常はリソースサイズが大きい、APIが遅い、スクリプトがブロックしていることが原因です。
- 開けるが操作がカクつく：ページは表示されるが、スクロール、クリック、タブ切り替えがカクつく場合、ほとんどはフロントエンドのロジックやアニメーションが重すぎることが原因です。
- 速い時と遅い時がある：昼は遅く夜は速い、または特定の地域で遅い場合、ほとんどは帯域幅、CDN、サーバー設定の問題です。
まずどのタイプかを特定してから、責任の所在を議論します。そうしないと、「デザインは開発が最適化していないと言い、開発はデザインカンプが大きすぎると言う」という責任の押し付け合いが起こりやすくなります。
二、デザイン面：ビジュアルカンプが最初から地雷を埋めている可能性
デザインは単に見栄え良く描くことではなく、デザインの決定がページの重量を直接左右します。よくある落とし穴は以下の通りです。
1. ファーストビューの大きな画像が非現実的：4Kのメインビジュアルをそのままファーストビューに配置し、しかも圧縮しないよう要求する。
2. フォントを使いすぎ：1ページに4〜5種類の中国語フォントを導入し、それぞれ数百KBあるため、読み込みが当然遅くなる。
3. アニメーションの積み重ね：進入アニメーション、スクロールアニメーション、パララックス効果をすべて盛り込み、モバイルではそのまま固まる。
4. 画像の仕様指定がない：デザインカンプは効果のみで、サイズやフォーマットの提案がないため、開発はそのまま流用するしかない。
落とし穴を避ける方法は簡単です。デザイン段階でファーストビューのメイン画像は300KB以下、サイト全体の中国語フォントは2セット以下、アニメーションは必要な1〜2つだけに絞ると取り決めます。これは創造性を制限するものではなく、創造性が機能するようにするためのものです。
三、開発面：パフォーマンス問題のほとんどはここに起因する
デザインカンプ自体に問題がなければ、次はサイト開発の段階を見ます。よくあるパフォーマンスの弱点は以下の通りです。
- 画像が圧縮されていない、WebPに変換されていない、遅延読み込みが実装されていない。これは最も一般的で最も修正しやすい類です。
- APIの直列呼び出し：トップページがA APIの応答を待ってからB APIをリクエストし、無駄に数百ミリ秒待つ。
- サードパーティスクリプトが多すぎる：統計、チャット、地図、広告プラグインがそれぞれ1つずつ入り、どれもファーストビューを遅くする。
- キャッシュ戦略がない：アクセスのたびに全データを再取得し、サーバー負荷が高く、ユーザーも長く待つ。
- フロントエンドのバンドルが分割されていない：数MBのJSファイルを一度に読み込み、ファーストビューが必然的に遅くなる。
ここで判断のコツがあります。ブラウザの開発者ツールでNetworkパネルを見ると、ファーストビューのリクエスト数が50を超える、または単一リソースが1MBを超える場合、ほぼ開発の最適化が不十分であると確定できます。
四、サーバーとデプロイ：唯一の原因とみなさず、無視もしない
サーバーは確かに速度に影響しますが、通常はファーストビューが遅い主因ではありません。注目すべき点は以下の通りです。
- 帯域幅が十分か、特に画像の多い企業サイトでは重要です。
- CDNを導入しているか、静的リソースがユーザーに近いノードに配信されているか。
- データベースクエリにスロークエリがないか、特に管理画面で顕著です。
- GzipまたはBrotli圧縮が有効になっているか。
よくある誤解は、大金をかけてサーバーをアップグレードするのに、画像圧縮をしないことです。結果として金は使ったが、速度はほんの少ししか改善しません。順序としては、まずフロントエンドのリソースを最適化し、その後でスペック増強を検討すべきです。
五、具体的なシナリオ：予約ミニアプリや管理システムも遅い理由
企業サイトだけでなく、ミニアプリ開発やApp開発でも同様の問題が発生します。
例えば予約ミニアプリで、ユーザーが開いてから予約可能な時間が表示されるまで3秒待つとします。調査の結果、ページ進入時に店舗リスト、サービス項目、ユーザー情報、予約可能時間の4つのAPIを同時にリクエストし、しかもキャッシュを実装していないことが判明しました。スケルトンスクリーンを先に描画し、APIを並列リクエストし、時間データをローカルにキャッシュするよう変更したところ、ファーストビューは1秒以内に短縮されました。
また、管理システムでは、リストページのページ切り替えのたびに全テーブルを再クエリしていました。インデックスを追加し、ページネーションキャッシュを実装したところ、応答時間は4秒から300ミリ秒に短縮されました。
これらはデザインの問題ではなく、サーバーの問題でも完全にはなく、開発段階のパフォーマンス意識の問題です。
六、どのような場合にMIC Studioに依頼すべきか
上記の順序で調査しても原因が見つからない場合、またはチーム内にデザイン、フロントエンド、バックエンド、デプロイを同時に理解できる人がいない場合は、専門チームの介入が適しています。
MIC Studioは企業サイト、ミニアプリ開発、App開発、スクリプト開発を行い、サイトのセキュリティテストやリバーステストも手がけています。私たちがこのような問題に対処する際の考え方は、まず速度を測定して特定し、次に最適化リストを提示し、優先度順に修正するというもので、いきなり作り直しを求めることはありません。
私たちに依頼が適しているケースは以下の通りです。
- 公式サイトのリニューアル後に明らかに遅くなり、自分では原因が特定できない。
- ミニアプリやAppのファーストビュー読み込みが3秒を超え、コンバージョンに影響している。
- 管理システムが使うほどに重くなり、データ量が増えると応答が非常に遅い。
- 漠然とした「最適化を推奨」ではなく、実行可能なパフォーマンス最適化方案が必要。
まとめ：実行可能な3つの提案
1. まず測定してから修正：開発者ツールや速度測定プラットフォームでファーストビュー時間、リクエスト数、リソースサイズを記録し、データに基づいて判断する。感覚でサーバーを交換しない。
2. デザインと開発が事前にすり合わせる：ビジュアルカンプの段階で画像仕様、フォント数、アニメーション範囲を取り決めることで、後工程の大量の手戻りを省ける。
3. 最適化の順序を間違えない：まず画像を圧縮し、リクエストを減らし、キャッシュを追加し、その後で帯域幅とサーバーのアップグレードを検討するのが最もコスト効率が良い。
サイトが遅いこと自体は恐ろしくありません。恐ろしいのはずっと推測し続けることです。問題をデザイン、開発、デプロイの3つに分解し、一つずつ測定すれば、答えは自然と見えてきます。