1.5秒以下で読み込まれるラグジュアリージュエリーサイト

2021年、メイフェアに拠点を置くジュエリーブランドが私たちのところにやって来ました。彼らのサイトは本当に美しかった — 深い黒、フルブリード編集写真、私の最初のフリーランスプロジェクトより高い費用をかけたカスタムセリフ書体。しかし4G接続で9.4秒かかって読み込まれていました。彼らのバウンスレートは74%に達していました。毎月4,000ポンドを有料検索に費やしていても、これらのクリックのほとんどは単一の製品のレンダリングが完了する前に消えていました。

そのプロジェクトは12年間のサイト構築業務の中で最も教育的な経験の一つになりました。なぜなら、課題は単に「高速にする」ことではないからです。「高速にしながら、ボンドストリートのカルティエブティックの隣に並ぶ価値があるように見えるようにする」ことです。この2つは反対方向に引っ張っているように見えます。実際にはそうではありません。ただ、ほぼすべての決定について意図的である必要があります。andstill feel like it belongs next to a Cartier boutique on Bond Street." Those two things feel like they're pulling in opposite directions. They're not. But you have to be deliberate about almost every decision.

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

ほとんどのeコマースパフォーマンスアドバイスは中堅ブランド向けに書かれています。画像を圧縮し、CDNを使用し、折り返し以下を遅延読み込みする — 完了です。ラグジュアリー層のジュエリーはこれらのルールに従いません。これらを単純に適用しようとすると、高速に読み込まれるが、Shopifyドロップシッピングストアのように見えるサイトで終わります。

具体的な問題は：

• ミディアムフォーマットカメラで撮影したヒーロー画像——80MB以上になることもあります— we're talking source files north of 80MB sometimes
• Google Fontsではなく、プライベートな書体鋳造所から読み込むカスタムタイプフェース。つまりキャッシュのショートカットは使えません, not Google Fonts, which means no caching shortcuts
• 開発者が「雰囲気のため」に追加して、その後監査することのないパラレックススクロール効果that developers add "for atmosphere" and then never audit
• 複数の角度で撮影した商品写真——SKUあたり8枚、10枚、時には14枚— 8, 10, sometimes 14 images per SKU
• ブランドデックで承認されたビデオ背景。ウェブでの表示は考慮されていませんthat someone signed off on in a brand deck without considering the web

そしてその下には、多くの場合WordPress + WooCommerceスタックがあります。独立系のジュエリー店の60～70%が私たちのところに来たときに使っているものだからです

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

一つのファイルにも手を付ける前に、測定してください。これは私の執着です。Google PageSpeed Insightsと同じページでWebPageTestを同時に実行してください。PageSpeedはラボスコアとCore Web Vitalsの内訳を提供します。WebPageTestはウォーターフォール——実際に何があなたを殺しているのかを診断する場所を提供しますGoogle PageSpeed InsightsandWebPageTeston the same page simultaneously. PageSpeed gives you the lab score and the Core Web Vitals breakdown. WebPageTest gives you the waterfall — which is where you actually diagnose what's killing you.

3つの数字を特に見てください。LCP（Largest Contentful Paint）、TBT（Total Blocking Time）、TTFB（Time to First Byte）です。高級ジュエリーサイトの場合、あなたの敵はほぼ常にLCPです。その大きなヒーロー画像——大理石の表面のエメラルドリングが写っているあの画像——がおそらくあなたのLCP要素で、おそらく巨大で、プリロードされていませんLCP(Largest Contentful Paint),TBT(Total Blocking Time), andTTFB(Time to First Byte). For a luxury jewellery site, your enemy is almost always LCP. That hero image — the one with the emerald ring on a marble surface — is probably your LCP element, and it's probably massive and not preloaded.

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

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

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

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

AVIFはもう新しくありませんが、多くのラグジュアリーサイトはまだJPEGを配信しています。理由は「フォトグラファーがJPEGで納品するから」というものですが、これは言い訳になりません。AVIFは同等の画像品質でJPEGより約50%小さいファイルサイズを実現します。JPEGで1.2MBになっている商品画像なら、AVIFで400～600KBに圧縮でき、画面上では知覚できる品質低下がありません。

手動による1回限りの変換にはSquooshを使います。バッチ処理にコミットする前に視覚的に品質を確認したいときに便利です。WordPressの本番環境パイプラインではShortPixelがAVIF変換を自動で処理し、私が約40個のプラグインをテストした中で品質対ファイルサイズの比率が最高です。Squooshfor manual one-off conversions when I want to check quality visually before committing to a batch process. For production pipelines on WordPress, ShortPixel handles AVIF conversion automatically and the quality-to-size ratio is the best I've tested across about 40 plugins.

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

4K解像度の商品画像を幅375pxのiPhoneスクリーンに配信するのは無責任です。WordPressのsrcsetは理論上これを処理しますが、テーマが実際に適切な中間サイズを生成し、配信していることを確認する必要があります。wp_get_attachment_image呼び出しを確認してください。テーマのadd_image_size登録を確認してください。テーマが単にthumbnail、medium、largeのみを登録して構築されているなら、幅480pxのproduct-mobileサイズを追加し、WooCommerceのギャラリーがそれを使用していることを確認してください。srcsethandles this in theory, but you need to make sure your theme is actually generating — and serving — the right intermediate sizes. Check yourwp_get_attachment_imagecalls. Check your theme'sadd_image_sizeregistrations. If your theme was built by someone who just registeredthumbnail,medium, andlarge, go and add aproduct-mobilesize at 480px width and make sure WooCommerce's gallery is using it.

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

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

<link rel="preload" as="image" href="/hero-ring.avif" fetchpriority="high">

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

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

ラグジュアリーブランドがGoogle Fontsを使うことはほぼない。KlimやOptimoといったファウンドリーからタイプフェイスをライセンス取得して、セルフホストし、「ブランドガイドラインに従って」4～6ウェイトを読み込む。ブランドマネージャーから8種類のフォントバリエーションが掲載された仕様書をもらったことがあるが、サイトで実際に使われているのはそのうち3種類だけだった。

ここが私のやり方だ：

1. サイト上に実際に表示されているウェイトを監査する。すべてのページテンプレートでブラウザの計算済みスタイルパネルを使う。
2. フォントをサブセット化する。Font SquirrelのWebfont Generatorなら、不要なグリフを削除できる。すべての合字を含むフルラテン書体は280KBかもしれないが、英文字のみで十分なサブセットなら40KBまで落とせる。Font Squirrel's Webfont Generatorlets you strip out glyphs you don't need. A full Latin typeface with all diacritics might be 280KB. A subset covering English-only characters drops that to 40KB.
3. font-display: swapを使って、テキストが即座に表示され、カスタムフォントが読み込まれたら切り替わるようにする。確かに一瞬のフラッシュがある。ブランドマネージャーが文句を言うかもしれない。コンバージョンデータを見せると黙る。font-display: swapso text is visible immediately, then switches to the custom font when it loads. Yes, there's a brief flash. Yes, some brand managers will complain. Show them the conversion data and they stop complaining.
4. メインの本文フォントをヒーロー画像と同じようにプリロードする。

サブセット化とプリロードの組み合わせで、ラグジュアリーサイトなら通常300～600msの短縮が期待できる。これは無視できない改善だ。

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

これは正直さが必要だ。ブラウザのNetworkタブを開いて、JSでフィルタリングし、何が読み込まれているかを確認してほしい。数年間のプラグイン蓄積を経たWooCommerceサイトでは、製品ページで2～4MBのJavaScriptが読み込まれているのをよく見かける。これは正気の沙汰ではない。

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

• ライブチャットウィジェット。すべてのページで200KBのJSを読み込むが、チャットを開く人がいないページも含まれているthat load 200KB of JS on every page, including ones where no one ever opens the chat
• レビュープラットフォーム（Yotpo、Trustpilot）が、星評価ウィジェットだけが必要なのに、フル SDKを読み込んでいる(Yotpo, Trustpilot) loading their full SDK when you only need a star rating widget
• KlaviyoやOmnisendのメール ポップアップスクリプトが、ページ読み込み時に発火している。遅延すべきなのにemail pop-up scripts firing on page load instead of being deferred
• Instagramフィードプラグインが、追加のAPI呼び出しとレンダリングをブロックするスクリプトを引き込んでいるthat pull in a second round of API calls and render-blocking scripts

WordPressでは、Asset CleanUp Proを使ってページテンプレートごとにスクリプトとスタイルシートを無効化している。これはWP Rocketのアセット最適化よりも、本当に細かい粒度で制御できる。ライブチャットはコンタクトページだけに読み込む。Klaviyoのポップアップスクリプトは、ユーザーインタラクションから3秒の遅延後だけに読み込む。これらはトリックではない。単に責任のある読み込み方だ。Asset CleanUp Proto disable scripts and stylesheets per page template. It's genuinely granular in a way that WP Rocket's asset optimisation isn't. Load the live chat only on the contact page. Load the Klaviyo pop-up script only after a 3-second user interaction delay. These aren't tricks — they're just responsible loading.

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

ここが重要だ——画像とフォントとJavaScriptですべてを正しくしていても、サーバーが低スペックか設定ミスなら、TTFB600msになるかもしれない。ラグジュアリークライアントには、Kinstaのマネージドワードプレスホスティングを標準化している。彼らのインフラはGoogle CloudのC2マシンで動作し、フルページキャッシングはPHPが実行される前にNginxレベルで行われ、CDN（Cloudflareのネットワークによってサポートされている）がアセット配信を処理する。Kinstafor managed WordPress hosting. Their infrastructure runs on Google Cloud's C2 machines, full-page caching happens at the Nginx level before PHP ever runs, and their CDN (powered by Cloudflare's network) handles the asset delivery.

WP EngineとFlywheelもラグジュアリープロジェクトで使用した。どちらも悪くない。ただし、Kinstaは私のテストではUK拠点から一貫して80～140msのTTFBを実現しており、これはマネージドホスト全体で私が測定した中で最高だ。

多くの人が見落としていることですが、データベース最適化はWooCommerceサイトではほぼあらゆるプラットフォームより重要です。WooCommerceはwp_optionsテーブルに積極的に書き込みを行い、1年の運用後、そのテーブルには数万行のレコードが溜まる可能性があります。その多くはクリーンアップされなかったトランジェントです。WP-Optimize Proがこれに対応します。実行してください。週単位のスケジュールで設定してください。database optimisation matters more on WooCommerce sites than almost any other platform.WooCommerce writes to thewp_optionstable aggressively, and after a year of operation, that table can have tens of thousands of rows, many of them transients that never got cleaned. WP-Optimize Pro handles this. Run it. Set it on a weekly schedule.

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

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

WooCommerceの商品ギャラリーについて、デフォルトギャラリーをSplide.jsを使用した軽量なカスタム実装に置き換えます。ミニファイ・gzip圧縮時で約28KBで、遅延読み込みを適切に処理し、デフォルトのWooCommerce FlexsliderのようにjQuery UIを読み込みません。商品ページのJavaScriptペイロードが約380KBから約90KBに削減されます。これはモバイルでの意味のあるLCP改善です。Splide.js— it's about 28KB minified and gzipped, handles lazy loading properly, and doesn't pull in jQuery UI the way the default WooCommerce Flexslider does. The difference in JavaScript payload on a product page goes from ~380KB to ~90KB. That's a meaningful LCP improvement on mobile.

最初の1つを除く、すべての商品画像を遅延読み込みにしてください。最初の画像はプリロードすべきです。残りですか？ユーザーがギャラリーをスクロールやタップして移動する際に読み込ませてください。except the first one. The first image should be preloaded. The rest? Let them load as the user scrolls or taps through the gallery.

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

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

ミッドレンジのモバイルデバイスでのLCPが1.5秒以下というのが私の目標です。ラグジュアリーであれば2秒でいいと言う代理店もあります。デスクトップについては完全に間違っていません。実際にはジュエリーの購入者はデスクトップで閲覧している可能性が高いからです。しかしGoogleの調査では、2.5秒のLCPしきい値ですでにコンバージョン率が大幅に低下し始めることが示されています。私はマージンを持つことを好みます。1.5秒以下なら、サードパーティースクリプトが時間とともに増加しても十分な余裕があります。Google's researchshows that the 2.5 second LCP threshold is already where conversion rates start declining significantly. I'd rather have margin. Under 1.5s gives you headroom even as third-party scripts accumulate over time.

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

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

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

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

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

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

---

スピードとラグジュアリーは対立するものではありません。どちらも尊敬についてです。製品への尊敬、そしてそれを見ている人への尊敬です。誰かに待たせるサイトは、すでにその人の時間をどの程度重視しているかについて何かを伝えているサイトです。基本を正しく理解し、実際に遅さの原因が何であるかについて正直でいること、そして実機でテストすること。1.5秒の目標は達成可能です。40枚の製品画像ギャラリーとスイスの鋳造所からのカスタムセリフフォントを備えたサイトで達成しています。ほとんどのビルドが得るよりも多くの意図が必要なだけです。