2021年、メイフェアを拠点とするジュエリーブランドが、見た目は本当に素晴らしいサイトを持ってやってきた。深い黒、フルブリードの編集写真、私の最初のフリーランスプロジェクトより高い金がかかったカスタムセリフフォント。ところが4G接続で9.4秒かかっていた。バウンスレートは74%。月4,000ポンドの検索広告に費用をかけていたのに、そのクリックのほとんどは単一の商品がレンダリングを完了する前に消えていた。
そのプロジェクトは、9年間のサイト構築経験の中で最も教えられることが多かったものの1つになりました。なぜなら、課題は単なる「高速化する」ではなく、「高速化しながらも、ボンド・ストリートのカルティエ・ブティックの隣に堂々と並んで見える」ことだからです。この2つは相反する方向に引っ張られているように見えます。実際はそうではありません。ただし、ほぼすべての決定について意図的である必要があります。and still 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%が私たちのところに来るときに使っているのがそれだからだ。WordPress + WooCommerce stack, because that's what 60-70% of independent jewellers are running when they come to us.
直感ではなく、実際のベースラインから始める
ファイルを一つ触る前に計測する。これについては強迫的だ。Google PageSpeed InsightsとWebPageTestを同じページで同時に実行する。PageSpeedはラボスコアとCore Web Vitalsの内訳をくれる。WebPageTestはウォーターフォールをくれる。そこが本当に何があなたを殺しているかを診断する場所だ。Google PageSpeed Insights and WebPageTest on 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), and TTFB(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になり、画面上で知覚できる品質差はない。
視覚的に品質を確認してからバッチプロセスにコミットしたい場合、手動による一度限りの変換にはSquooshを使用します。WordPressの本番パイプラインの場合、ShortPixelはAVIF変換を自動的に処理し、品質対サイズの比率は私がテストした約40個のプラグインの中で最高です。Squoosh for 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.
形式だけでなく、適切なサイズを配信する
375pxの幅のiPhoneスクリーンに4K商品画像を配信するのは過失。WordPressのsrcsetは理論的には対応しているが、テーマが実際に正しい中間サイズを生成・配信していることを確認する必要がある。wp_get_attachment_image呼び出しを確認する。テーマのadd_image_size登録を確認する。テーマが単にthumbnail、medium、largeを登録したなら、480px幅のproduct-mobileサイズを追加して、WooCommerceギャラリーがそれを使用していることを確認する。srcset handles this in theory, but you need to make sure your theme is actually generating -- and serving -- the right intermediate sizes. Check your wp_get_attachment_image calls. Check your theme's add_image_size registrations. If your theme was built by someone who just registered thumbnail,medium, and large, go and add a product-mobile size 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つだけだった。
ここが私のやり方だ：
- サイト上に実際に表示されているウェイトを監査する。すべてのページテンプレートでブラウザの計算済みスタイルパネルを使う。
- フォントをサブセット化してください。Font Squirrelのウェブフォントジェネレータを使用すると、不要なグリフを削除できます。すべての分音記号を含む完全なラテン文字書体は280KBかもしれません。英字のみの文字をカバーするサブセットはそれを40KBに削減します。Font Squirrel's Webfont Generator lets 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.
- 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. - メインの本文フォントをヒーロー画像と同じようにプリロードする。
サブセット化とプリロードの組み合わせは、通常ラグジュアリーサイトで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
- スター評価ウィジェットのみが必要なのに、完全なSDKを読み込むレビュープラットフォーム（Yotpo、Trustpilot）(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フィードプラグインが2回目のAPI呼び出しを行い、レンダリングをブロックするスクリプトを実行している that pull in a second round of API calls and render-blocking scripts
WordPressの場合、Asset CleanUp Proを使ってページテンプレート単位でスクリプトとスタイルシートを無効化している。WP Rocketのアセット最適化よりも、本当に細かい粒度で制御できる。ライブチャットはコンタクトページだけに読み込む。Klaviyoのポップアップスクリプトはユーザーインタラクションから3秒の遅延後に読み込む。これらはトリックではなく、責任あるローディング方法にすぎない。Asset CleanUp Pro to 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で全て正しくやっても、サーバーの性能が低かったり設定が悪かったりすれば、TTFBで600msになるかもしれない。ラグジュアリークライアント向けには、マネージドWordPressホスティングはKinstaに統一している。彼らのインフラはGoogle CloudのC2マシンで動作し、フルページキャッシングはPHPが実行される前のNginxレベルで発生し、CDN（Cloudflareネットワークで駆動）がアセット配信を処理する。Kinsta for 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のTTFBは私の測定では英国ロケーションから一貫して80～140msで、マネージドホストの中で測定した最高の値だ。
多くの人が見落としていることの1つとしては、WooCommerceサイトではほぼあらゆるプラットフォームよりもデータベース最適化がより重要だということです。WooCommerceはwp_optionsテーブルに積極的に書き込みを行い、1年間の運用後、そのテーブルは数万行を持つようになり、その多くはクリーンアップされなかったトランジェント（一時データ）です。WP-Optimize Proがこれに対応します。実行してください。週単位のスケジュールで設定してください。database optimisation matters more on WooCommerce sites than almost any other platform.WooCommerce writes to the wp_options table 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.
最初の画像を除いてすべての商品画像を遅延読み込みしてください。最初の画像は事前読み込みされるべきです。その他ですか？ユーザーがスクロールまたはギャラリーをタップして操作する際に読み込ませてください。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が表示する内容と、このPhone実際にレンダリングする内容のギャップは、複数回私を引っかかっている。
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 research shows 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ブロックエディターを使い、カスタムブロックの制限されたセットに限定します。
ローンチ後、サイト速度はどのくらいの頻度で再テストすべきですか？
最低でも月次で実施します。WooCommerceプラグインの更新、クライアントが黙ってインストールする新しいマーケティングスクリプト、埋め込みInstagramフィードを含む季節キャンペーンのランディングページ――これらはすべて時間とともにパフォーマンスを低下させます。継続的なリテーナークライアント向けに四半期ごとのパフォーマンス監査をスケジュールしています。完全なリビルドではなく、2時間の監査と書面でのレポート、優先度付きの修正リストだけです。ほとんどのリテーナークライアントは前回の確認以来、通常3つの新しいものをインストールしているので、この監査を非常に価値あるものと感じています。
---
スピードと高級感は相反するものではありません。どちらも尊重です――プロダクトへの尊重、そしてそれを見る人への尊重です。誰かに待たせるサイトは、あなたが彼らの時間をどれだけ大切にしているかをすでに伝えているサイトです。基本を正しく押さえ、実際に何が遅さの原因なのかについて誠実に向き合い、実機でテストする。1.5秒のターゲットは達成可能です。私は40枚の商品画像ギャラリーとスイスのファウンドリーからのカスタムセリフ書体を備えたサイトで達成しています。ほとんどのビルドが得るものより、単に意図が必要なだけです。