ラグジュアリージュエリーウェブサイト：1.5秒以下での読み込み

2021年、メイフェアに本拠地を置くジュエリーブランドが、本当に素晴らしいサイトを持ち込んできた。深い黒、フルブリード編集写真、私の最初のフリーランスプロジェクトより高い費用がかかったオーダーメイドセリフ体。問題は、4G接続で9.4秒で読み込まれていたこと。バウンス率は74%に達していた。彼らは月に£4,000を有料検索に費やしており、そのクリックのほとんどは1つの商品がレンダリングを終える前に消えていた。

そのプロジェクトは、9年間のサイト構築経験の中で最も教えられることが多かったものの1つになりました。なぜなら、課題は単なる「高速化する」ではなく、「高速化しながらも、ボンド・ストリートのカルティエ・ブティックの隣に堂々と並んで見える」ことだからです。この2つは相反する方向に引っ張られているように見えます。実際はそうではありません。ただし、ほぼすべての決定について意図的である必要があります。

ラグジュアリージュエリーサイトが特別な種類のパフォーマンス問題である理由

ほとんどのeコマースパフォーマンスアドバイスは中堅ブランド向けに書かれている。画像を圧縮して、CDNを使って、fold下をレイジーロードして、完了。ラグジュアリーの高級ジュエリーはそのルールに従わないし、単純にそれらを適用しようとすれば、素早く読み込まれるが、Shopifyドロップシッピングストアのように見えるサイトで終わる。

具体的な問題は：

中判カメラで撮影されたヒーロー画像。ソースファイルが80MB以上になることもある。
Google Fontsではなく、プライベートな書体鋳造所から読み込むカスタムタイプフェース。つまりキャッシュのショートカットは使えません
開発者が「雰囲気のために」追加して、その後一度も監査しないパラレックススクロールエフェクト
複数の角度からの商品写真。1つのSKUあたり8、10、時には14画像。
ブランドデッキで承認されたが、ウェブでの影響を検討されていなかったビデオ背景

その全ての背後には、WordPressとWooCommerceのスタックがあることが多い。独立したジュエリーブランドの60〜70%が私たちのところに来るときに使っているのがそれだからだ。

直感ではなく、実際のベースラインから始める

1つのファイルにも手を付ける前に、測定する。これについては強迫的だ。Google PageSpeed InsightsとWebPageTestを同じページで同時に実行する。PageSpeedはラボスコアとCore Web Vitalsの内訳を提供する。WebPageTestはウォーターフォールを提供し、そこで何があなたを殺しているかを実際に診断する。

3つの数字に特に注目する。LCP（Largest Contentful Paint）、TBT（Total Blocking Time）、TTFB（Time to First Byte）。高級ジュエリーサイトの敵は、ほぼ常にLCPだ。大理石の表面のエメラルドリングのあのヒーロー画像は、おそらくあなたのLCP要素で、おそらく膨大で事前読み込みされていない。

Seahawkでは、最適化作業が始まる前に、ベースラインを共有Notionテーブルに文書化します。すべての変更がそれに対して追跡されます。明らかなように聞こえます。このステップをスキップして、実際に改善したことを証明できないエージェンシーがどれだけ多いか、あなたは驚くでしょう

画像パイプラインがすべて

ここで得られるゲインが全体の80%を占めます。この投稿の他のどのセクションもこれほど重要ではありません。

AVIFを優先、WebPをフォールバックとして使用する

AVIFは新しくないが、高級サイトの多くはまだJPEGを配信している。「写真家がJPEGで納品するから」。言い訳にはならない。AVIFはJPEGより約50%小さいファイルサイズで同等の視覚品質を与える。JPEGで1.2MBの商品画像は、AVIFなら400〜600KBになり、画面上で知覚できる品質差はない。

視覚的に品質を確認してからバッチプロセスにコミットしたい場合、手動による一度限りの変換にはSquooshを使用します。WordPressの本番パイプラインの場合、ShortPixelはAVIF変換を自動的に処理し、品質対サイズの比率は私がテストした約40個のプラグインの中で最高です。

形式だけでなく、適切なサイズを配信する

375px幅のiPhoneスクリーンに提供される4K商品画像は無責任だ。WordPressのsrcsetは理論上これを処理するが、テーマが実際に正しい中間サイズを生成して配信していることを確認する必要がある。wp_get_attachment_image呼び出しを確認する。テーマのadd_image_size登録を確認する。誰かによって構築されたテーマが単にthumbnail、medium、largeを登録した場合は、480px幅のproduct-mobileサイズを追加して、WooCommerceギャラリーがそれを使用していることを確認する。

ヒーロー画像は特殊ケース

遅延読み込みはしないでください。逆に聞こえるかもしれませんが、LCP要素を遅延読み込みすると、読み込みシーケンスの後ろに押しやられます。代わりにプリロードしてください。`<head>`内で：

その1行でMayfairプロジェクトのLCPが0.8秒低下した。大げさじゃない。たった1行だ。

フォント：高級サイトにおける隠れたパフォーマンス殺し

ラグジュアリーブランドがGoogle Fontsを使うことはまずない。KlimやOptimoといったファウンドリーからタイプフェイスをライセンスして、自分たちでホストし、4～6ウェイトを読み込んでいる。理由は「ブランドガイドラインに書いてあるから」だ。ブランドマネージャーから8つのフォント書体仕様書を受け取ったことがあるが、サイトで使われているのはそのうち3つだけだった。

ここが私のやり方だ：

サイト上に実際に表示されているウェイトを監査する。すべてのページテンプレートでブラウザの計算済みスタイルパネルを使う。
フォントをサブセット化してください。Font Squirrelのウェブフォントジェネレータを使用すると、不要なグリフを削除できます。すべての分音記号を含む完全なラテン文字書体は280KBかもしれません。英字のみの文字をカバーするサブセットはそれを40KBに削減します。
font-display: swapを使用して、テキストがすぐに表示され、カスタムフォントがロードされたら切り替わるようにします。はい、簡潔なフラッシュがあります。はい、いくつかのブランドマネージャーは文句を言うでしょう。彼らにコンバージョンデータを見せると、彼らは文句を言わなくなります。
メインの本文フォントをヒーロー画像と同じようにプリロードする。

サブセット化とプリロードの組み合わせは、通常ラグジュアリーサイトで300～600msの短縮をもたらす。決して無視できない数字だ。

JavaScript：実際に読み込んでいるものを監査する

これは正直さが必要だ。ブラウザのNetworkタブを開いてJSでフィルタリングし、何が読み込まれているか見てみるといい。何年もプラグインが蓄積されたWooCommerceサイトでは、製品ページだけで2～4MBのJavaScriptが読み込まれていることが普通だ。これは狂っている。

特にジュエリーサイトでよくある犯人はこれだ：

すべてのページに200KBのJSをロードするライブチャットウィジェット。チャットを開く人が誰もいないページも含めて。
スター評価ウィジェットのみが必要なのに、完全なSDKを読み込むレビュープラットフォーム（Yotpo、Trustpilot）
KlaviyoまたはOmnisendのメールポップアップスクリプトがページ読み込み時に発火し、遅延読み込みされていない
Instagramフィードプラグインが2回目のAPI呼び出しを行い、レンダリングをブロックするスクリプトを実行している

WordPressの場合、Asset CleanUp Proを使用してページテンプレートごとにスクリプトとスタイルシートを無効にする。WP Rocketのアセット最適化とは異なり、本当にきめ細かい。連絡先ページにのみライブチャットを読み込む。3秒のユーザーインタラクション遅延後にのみKlaviyoポップアップスクリプトを読み込む。これらはトリックではなく、単に責任ある読み込みだ。

ホスティングとインフラストラクチャ：スタックの最上部で安物を選ぶな

ここが重要だ。画像とフォントとJavaScriptですべてを正しく行うことができても、サーバーが十分でないか、設定が誤っていると、600msのTTFBを取得できる。ラグジュアリークライアントの場合、Kinstaの管理WordPressホスティングに標準化している。彼らのインフラストラクチャはGoogle CloudのC2マシン上で実行され、フルページキャッシングはPHPが実行される前にNginxレベルで発生し、彼らのCDN（Cloudflareネットワークの電力駆動）がアセット配信を処理する。

WP EngineとFlywheelもラグジュアリープロジェクトで使ったことがある。両方とも悪くない。だがKinstaのTTFBは私の測定では英国ロケーションから一貫して80～140msで、マネージドホストの中で測定した最高の値だ。

多くの人が見落としていることの1つとしては、WooCommerceサイトではほぼあらゆるプラットフォームよりもデータベース最適化がより重要だということです。WooCommerceはwp_optionsテーブルに積極的に書き込みを行い、1年間の運用後、そのテーブルは数万行を持つようになり、その多くはクリーンアップされなかったトランジェント（一時データ）です。WP-Optimize Proがこれに対応します。実行してください。週単位のスケジュールで設定してください。

チェックアウトページと商品ページはホームページとは異なります

多くのエージェンシーがホームページをPageSpeedスコア95に最適化して、商品一覧ページ、個別商品ページ、チェックアウトページは無視しているのを見かけます。それらが売上を生み出すページです。ジュエリーサイトの場合、個別商品ページが最も重い画像負荷を抱えています。そこに14角度の商品ギャラリーが存在します。

WooCommerce商品ギャラリーについては、デフォルトのギャラリーをSplide.jsを使った軽量なカスタム実装に置き換えています。minify + gzip後で約28KBで、遅延読み込みも適切に処理でき、デフォルトのWooCommerce FlexsliderのようにjQuery UIを引き込むこともありません。商品ページのJavaScriptペイロードは約380KBから約90KBに減ります。モバイルでの意味のあるLCP改善です。

最初の画像を除いてすべての商品画像を遅延読み込みしてください。最初の画像は事前読み込みされるべきです。その他ですか？ユーザーがスクロールまたはギャラリーをタップして操作する際に読み込ませてください。

DevToolsのスロットリングだけではなく、実際のデバイスでテストしてください

Chrome DevToolsのスロットリングはシミュレーションです。相対的な比較には役立ちますが、それが真実とは限りません。私のデスクに正確にはMoto G Power(2021)、150ポンド以下のAndroidスマートフォンを置いています。ミッドレンジプロセッサーで、世界的な中央値のモバイルハードウェアに近い状態です。DevToolsが表示する内容と実際のこのスマートフォンのレンダリングのギャップに何度も引っかかっています。

Mayfairプロジェクトでは、DevToolsが「Fast 3G」スロットリング下で1.3秒のLCPを表示していました。Moto G Powerはロンドン中部の実際の4G接続で1.9秒を表示していました。これらは同じ問題ではありません。実デバイステストで、メインスレッドが追加したフォントアニメーション、見出しの書体の微妙なフェードインによってブロックされていることが判明しました。見た目は素晴らしかったです。実ハードウェアで400ms のコストがかかっていました。削除しました。

---

FAQ

ラグジュアリージュエリーウェブサイトのリアルな読み込み時間目標は何ですか？

ミッドレンジモバイルデバイスでのLCP1.5秒以下を目指しています。一部のエージェンシーは高級品向けには2秒で十分だと言います。デスクトップに関しては完全には間違っていません。実際に閲覧しているのは、典型的なジュエリーの購入者かもしれません。ただしGoogleの調査では、2.5秒のLCP閾値はコンバージョンレートが大幅に低下し始める地点です。マージンが欲しいです。1.5秒以下なら、時間の経過とともにサードパーティースクリプトが蓄積しても余裕があります。

フルブリード動画背景を使いながら1.5秒を達成できますか？

モバイルではほぼ不可能です。代わりに私がやることは、モバイルではポスター画像（最適化されたAVIF）を配信し、CSSのブレークポイント上のデスクトップでのみ動画を読み込むということです。Network Information APIを使ってJavaScriptで接続速度を検出し、遅い接続では動画の読み込みを完全にスキップできます。単一のソリューションほどエレガントではありませんが、制約条件が何かについて正直です。

ラグジュアリージュエリーサイトでElementorやDiviなどのページビルダーを使うべきですか？

カスタムビルドに真剣にお金をかけているクライアントであれば、両方とも避けます。これらは大量のCSSとJavaScriptのオーバーヘッドを注入し、外科的に削除することが難しいのです。Seahawkのラグジュアリープロジェクトでは、軽量のカスタムテーマか、ブロックベースのテーマ（必要なブロックだけを登録したKadence）のいずれかで構築し、ページビルダーを使いません。マーケティングチームの編集可能性がクライアントに必要な場合は、ネイティブのWordPressブロックエディターを使い、カスタムブロックの制限されたセットに限定します。

ローンチ後、サイト速度はどのくらいの頻度で再テストすべきですか？

最低でも毎月です。WooCommerceプラグイン更新、クライアントが告げずにインストールする新しいマーケティングスクリプト、埋め込みInstagramフィードを含む季節キャンペーンランディングページ。これらすべてが時間とともにパフォーマンスを低下させます。継続的なリテーナークライアント向けに四半期ごとのパフォーマンス監査をスケジュール設定しています。フルリビルドではなく、2時間の監査と書面によるレポート、優先度付きの修正リストです。ほとんどのリテーナークライアントは、前回のチェック以来3つの新しいものをインストールしているので、非常に価値があると感じています。

---

スピードと高級さは対極ではありません。どちらも尊重についてです。製品への敬意と、それを見ている人への敬意です。誰かを待たせるサイトは、あなたが彼らの時間をどの程度重視しているかについてすでに何かを伝えているサイトです。基本を正しく理解し、実際に遅さの原因は何かについて正直に、実ハードウェアでテストしてください。1.5秒のターゲットは達成可能です。40枚の商品画像とスイスの鋳造所のカスタムセリフ書体を備えたサイトで達成しています。ほとんどのビルドが受け取るよりも多くの意図が必要なだけです。