コアWebバイタル– WixとWordPress、ShopifyとShopware –最速は何ですか?
公開: 2022-04-17- 主要なページ速度の調査結果の要約
- ウェブサイトの読み込み時間が重要なのはなぜですか?
- Webサイトのパフォーマンスはどのように測定されますか?
- CMS:Jimdoは最速、WixはWordPressよりもさらに遅い
- ショップシステム:フィールドの中央にShopify、下部にWooCommerce
- CDN。 FastサイトはFastlyを使用しています
- 背景:何を(そしてどのように)測定したか
- 結論
ウェブサイトの読み込み速度は来年の公式のGoogleランキング要素になります。最適化のプロセスは単純ではないため、今すぐ開始する必要があります。
あなたを助けるために、ここに私たちの分析からの最も重要な発見の簡単な要約があります:
主要なページ速度の調査結果の要約
- Googleの予想によると、英国での読み込み時間の29 %は許容できません。つまり、最大2.5秒を超えています。
- ただし、この傾向は正しい方向を示しています。 高速なWebサイトの割合は、ここ数か月で2%増加しています。
- 英国からのウェブサイトへのアクセスは、それほど速くはありません。 ヨーロッパをリードするのはスイス、スウェーデン、ノルウェー、ドイツです。
- Jimdoは、クラウドベースのCMSが非常に優れたCoreWebVitalsの価値を提供できることを示しています。 しかし、オープンソースもこれを行うことができます–Typo3は少し遅いだけです。
- Wixより遅いCMSはありません。 CMSカテゴリーの木のスプーンホルダーです。 WordPressの背後にある最後の場所では、クラウドベースのソリューションが常に高速であるとは限らないことを示しています。
- Lightspeedは非常に高速なショップシステムを提供します。 Shopifyはリストの下半分にのみあります。 WordPressアドオンのWooCommerceは、最も遅いショップシステムです。
- プログラミング言語はWebテクノロジーにとって重要ではありません。Ruby (on Rails)、 PHP (Yii&Laravel)、 Python (Django)、およびその他の言語に高速フレームワークがあります。 Angularだけが本当に遅いです。
- AMPは自動的に高速なWebサイトにつながるわけではありません。 AMPページの約70%のみがCoreWebVitalsの基準を満たしています。
もっと時間があれば、ここにすべてのデータと、読み込み時間、高速システムと低速システム、およびそれらの背後にある接続に関する他の多くの興味深い調査結果を含む完全な分析があります。
ウェブサイトの読み込み時間が重要なのはなぜですか?
ユーザーエクスペリエンスは、Webサイトの成功において最も重要な要素の1つです。 訪問者がページの読み込みを(あまりにも)長く待たなければならない場合、訪問者はジャンプして別のソースを探すため、読み込み時間は優れたユーザーエクスペリエンスの基盤です。
ある調査で、Googleは、読み込み時間を1秒から3秒に増やすと、バウンス率が32%増加することを発見しました。 読み込み時間が5秒に増えると、訪問者がページを離れる確率が90%も高くなります。
Webサイトのパフォーマンスはどのように測定されますか?
Webサイトのユーザーエクスペリエンスを測定可能にするためのさまざまなツールとアプローチがあります。 Core Web Vitalsを使用して、Googleは3つの標準化された比較可能なキー数値を提供します。 これらのコアWebバイタルは、来年(2021)にもランキング要素になるため、Google検索結果でのページの位置に直接影響します。
別の記事で、背景、さまざまな測定方法、および3つのコアWebバイタルを改善する方法をすでに示しました。 だからここに簡単なリマインダーがあります:
- 最大のコンテンツフルペイント(LCP) –コンテンツの最大のセクションがロードされるのにかかる時間。 良い:2.5秒未満。
- First Input Delay(FID) –ユーザーがページを操作できるようになるまでの時間。 良い:0.1秒未満。
- 累積レイアウトシフト(CLS) –ロード中にレイアウトがどれだけシフトするかを示すインジケーター。 良い:0.1未満。
この分析では、3つの測定値すべてを示す最初の図を除いて、Largest Contenful Paint( LCP )の値を使用しました。 3つのコアWebバイタルのうち、これはページの読み込み時間を測定するための基本的な値です。
英国–サイトの29%が十分な速度ではありません
最初のステップとして、英国からのWebサイトアクセスが3つのCoreWebVitalsキー数値に対してどのように実行されたかを分析しました。 Googleは、それぞれに3つの領域を定義しています。
- 値がGoogleの期待の範囲内であれば、良い(緑)、
- 期待を上回っているが、まだそれらから大きく逸脱していない場合は、改善が必要(黄色)
- 測定値が目標から大きく外れている場合は不良(赤) 。
これに基づいて、3つのコアWebバイタルに基づく英国の結果を以下に示します。
最大のコンテンツフルペイント(LCP)を使用すると、すべての結果の70%がすでに良好です。 Googleは結果の12.9%を悪いと評価しています。 LCPは、実際の読み込み時間を最も直接的に反映するため、CoreWebVitalsの重要な数値です。
First Input Delay(FID )、つまりインタラクションまでの時間は、最高の値を持っています。アクセスの90%はすでに良好であり、Googleによって不良と評価されているのはわずか2%です。 ここでまだやるべきことがあるなら、取り残されないように急いでください。
ロードプロセス中のレイアウトのシフトである累積レイアウトシフト(CLS)を使用すると、Webサイトがこのテストに合格(緑)または完全に不合格(赤)のいずれかであることがわかります。改善のみが必要な場合はごくわずかです。 (黄色)。
ポジティブな傾向:ウェブサイトは毎月少し速くなっています
過去数か月で読み込み時間がどのように変化したかを理解するために、次の評価では、ここ数か月の最大コンテンツフルペイントの月次変化を示します。
進歩は急速ではありませんが、わずかに前向きな傾向があります。 2019年11月以降、不良測定の数は約2パーセントポイント減少し、良好な測定は73%から75%に増加しました。 方向性は前向きです。ウェブサイトは毎月少し速くなっています。
タブレットはただの悪いデスクトップです
次の分析では、デスクトップ、携帯電話、タブレットなどのデバイスタイプに応じて評価を分類します。 結果は次のとおりです。
当然のことながら、Webサイトは携帯電話よりもデスクトップの方が高速に読み込まれます。 ここでは、多くの場合有線インターネット接続とより多くの計算能力が決定的です。 ただし、デスクトップと携帯電話の違いは予想よりも小さいです。
タブレットのパフォーマンスの低さは興味深いものです。 考えられる理由の1つは、タブレットは通常、デスクトップバージョンのWebサイトをより大きな画面で表示することですが、タブレットのハードウェアはスマートフォンに匹敵します。 これにより、読み込み時間のパフォーマンスが大幅に低下します。
20位:イギリスからのウェブサイトへのアクセスを改善する必要がある
エンドユーザーがCoreWebVitalsについて測定した値は、Webサイトのパフォーマンスに部分的にのみ依存します。ユーザーのインターネット接続の速度、スループット、および遅延も結果に影響します。
サイト運営者として、あなた自身の訪問者のインターネット接続を最適化する方法はありませんが、各国のコアWebバイタルの分析は、これらの違いを非常に明確に示しています。 選択した国の評価は次のとおりです。
中国と韓国では、すべてのWebサイトの82%がGoogleの期待されるパフォーマンスと一致しています。これは、最高の価値であり、世界をリードしています。 これに北欧諸国(スウェーデン、ノルウェー、デンマーク)だけでなく、日本と台湾も続きます。
ドイツはこの分析で9位です。すべてのユーザーリクエストの4分の3は、すでにGoogleの予想速度に対応しています。 イギリスは20位に位置しており、国外、特に米国から、そしておそらくヨーロッパの他の地域のサービスから消費されているコンテンツの量を反映している可能性があります。
ロシアと米国の読み込み時間はほぼ同等です。 タイとベトナムの価値が低いことは、アジアが常に高速インターネットと同等であるとは限らないことを示しています。
太平洋の島国であるキリバスは、非常に離れた場所と衛星経由のインターネット接続の効果を示しています。すべてのアクセスの約4分の1だけがすでに良好です。 アクセスのほぼ60%がGoogleによって悪いと評価されています。
CMS:Jimdoは最速、WixはWordPressよりもさらに遅い
コンテンツ管理システム( CMS )はインターネットのバックボーンです。ほとんどのWebサイトは、そのようなソフトウェアのコア上で運用されています。 SMBの隣の美容院から、毎日何百万人もの訪問者がいるサイトまで。
最も使用されているコンテンツ管理システムの読み込み速度を評価できるように、WebテクノロジーのデータベースとCoreWebVitalsの測定値を組み合わせました。 分析に直接取り掛かりましょう:
ドイツのハンブルクのウェブサイトビルダーであるJimdoは、最大のコンテンツフルペイントで最高のパフォーマンスを発揮します。 Jimdoで実行されているWebサイトへのアクセスの82%以上が、Googleのパフォーマンスの期待に応えています。

Typo3は、評価の2位が示すように、自己ホスト型CMSでも非常に優れたパフォーマンスを提供できることを示しています。 Typo3で開発しなければならなかった人は誰でも、恐怖の複雑さをよく覚えています。 ただし、これはこのPHPベースのCMSの速度には影響しません。
WordPressは、最も普及しているCMSであり、最後の位置から2番目にはるかに遅れています。 すべてのウェブサイトの約半分がWordPressで実行されていますが、WordPressを使用していて、読み込み時間をあまり重視していない人もたくさんいます。 Googleは、WordPressに基づくWebサイトでのヒットの約20%を不良として分類し、さらに21%を改善が必要であると分類しています。
この分析でWordPressが木のスプーンを持っていないという事実は、 Wixという名前のプロバイダーのおかげです。 このクラウドソリューションは、すべてのアクセスの約半分のみを適切な読み込み時間で提供します。 ほぼ4分の1がGoogleのコアウェブバイタルを悪いと評価しました。
この分析の勝者(Jimdo)と敗者(Wix)の両方が同じ開始条件を持っていることを考えると、このパフォーマンスの低下は特に注目に値します。プロバイダーがシステム全体を制御し、すべての部分を最適化できるクラウドソリューション(ただし、明らかに常にそれを行うとは限りません)。
ショップシステム:フィールドの中央にShopify、下部にWooCommerce
早くも2006年に、Amazonは、読み込み時間が0.1秒増加すると、売上が1%減少すると判断しました。 過去14年間でそれはこれ以上良くなりませんでした。 オンラインショップにとって、適切な読み込み時間は基本的に重要です。
私たちのテクノロジーデータベースと読み込み時間に関するデータの組み合わせにより、インターネットの荒野で頻繁に見られるすべてのショップシステムについて次の分析が行われます。
勝者であるLightspeedは、その名に恥じない存在です。 Lightspeedを使用するドメインは、最大のコンテンツフルペイントの93%の「良い」評価に貢献します。 悪いと評価されたのはわずか2%です。 これらは、すべての評価にわたってこの分析で測定した最良の数値です。
Lightspeedには、クラウドソリューションであるというシステム関連の利点があります。 プロバイダーはシステム全体を制御し、すべての領域の速度を最適化できます。 オープンソースソリューションosCommerceは、非常に優れた84 %のセルフホストショップでも、非常に優れた読み込み時間を達成できることを示しています。
現在の流れ星Shopifyは、分析の下半分にしか入りません。 原則として、Lightspeed(プロバイダー自体によって完全にホストされている)と同じベースラインアーキテクチャを使用しますが、この利点は平均以上のロード時間に変換されません。
WordPressの拡張機能であるWooCommerceは、最後の場所ではるかに遅れています。 現在、WooCommerceショップの半数弱がGoogleの仕様を満たしています。 驚くべき26%は実際には悪いです。 パフォーマンスの低いマスプロバイダーを使用した自己運用型ホスティングソリューションは、ここで明らかです。
Webテクノロジー:AMPが予想より遅い
この評価では、ウェブサイトを作成するためのバックエンドテクノロジーから、デザインやインタラクションのためのJavaScriptやCSSライブラリ、Google AMPまで、さまざまなウェブテクノロジーを扱います。
次の表は、データで最も特定された用途のテクノロジーのみを示しています。 あまり使用されていないWebテクノロジーは除外されています。 もちろん、公的にアクセス可能なWebサイトのみを評価できます。 分析は次のとおりです。
Basecampの創設者によって開発されたRubyベースのフレームワークであるRubyonRailsは、圧倒的にリーダーです。このテクノロジーを使用するすべてのWebサイトのほぼ85%が、Googleが設定した制限内のWebサイトを配信し、最大のコンテンツフルペイントを評価しています。
しかし、 Yii (74%)やLaravel (73%)のようなPHPフレームワークも良い時間を提供します。 誰もが取り残されていると感じないように、 PythonはDjangoフレームワーク(75%)でもよく表されており、ASP.NET(77%)も2位になっています。 これから何を学びますか? 速度はプログラミング言語ではなく、実装に依存します。
AMPが最速のテクノロジーの1つではないことは注目に値します。 Accelerated Mobile Pages(AMP)は、主にGoogleによってプッシュされたHTMLの派生物です。 多数の制限があるため、携帯電話でのAMPページの読み込みは従来のHTMLページよりも大幅に速くなります。
結果は説得力がありません。AMPドメインの70%未満がGoogleの要件を満たしています。 グーグルは明らかにこれをすでに認識しており、将来的にはトップストーリーボックスのAMP特権を高速のコアウェブバイタルを持つサイトに遺贈する予定です。
ストーリーがモバイルのトップストーリーに掲載されるためにAMPは不要になります。 どのページでも開くことができます。
Googleウェブマスターセントラルブログ、より良いウェブのためのページエクスペリエンスの評価
すべてのドメインの半分以上をGoogleの要件に適合させることができない唯一のWebテクノロジーはAngularです。 皮肉なことに、Googleによって開発および提供されたフロントエンドアプリケーションのフレームワーク…
CDN。 FastサイトはFastlyを使用しています
コンテンツ配信ネットワーク(CDN)は、コンテンツがサイトへの訪問者へのより短い、したがってより速い伝送パスをカバーできるように、世界中に分散されたサーバーを提供します。 アカマイのようなスペシャリストに加えて、主要なクラウドプロバイダーもCDNを提供しています。
本質的に、すべてのCDNは同じように機能します。 また、アーキテクチャの物理的な制限を変更することもできません。 したがって、次の分析では、因果関係と相関関係を区別する必要があります。
より高速なCDNがリードの原因であるとは想定できませんが、パフォーマンス指向のWebサイト運営者はこれらのCDNに頼る可能性があります。
CDNとしてFastlyに依存するドメインは、平均して、他のプロバイダーに依存するドメインよりもはるかに高速です。 Googleは2位にランクインしていますが、 AmazonとMicrosoft (Azure)もそれほど遅れをとっていません。
アカマイがさらに遅れをとっているという事実は、アカマイの典型的な顧客と関係がある可能性があります。これらは、低速のレガシーシステムを運用することが多いかなり大規模な国際企業であり、最新の高速Webサイトを提供するための最良の前提条件ではありません。
この分析の下部にあるFirebladeは、従来のCDNを提供していませんが、 Webアプリケーションファイアウォールを提供しています。アプリケーションは、潜在的に危険な通話のインターネットトラフィックをフィルタリングし、それらをブロックします。 このようなアーキテクチャに頼らなければならない人は、平均して、古くて最適化されていないWebアプリケーションも操作するため、この評価ではすでに構造上の欠点があります。
背景:何を(そしてどのように)測定したか
読み込み速度の測定には長い歴史があります:純粋なHTML( TTFB 、最初のバイトまでの時間)の配信の開始の最初の測定から、最初のコンテンツフルペイント、コアWebバイタルの現在の3つの測定値まで中央のメトリックが大幅に変更されたため、最大のコンテンツフルペイントを使用します。
分析には、Google CoreWebVitalsの公式計算ベースを使用しました。 これには基本的に2つの異なる測定方法があります:実験室データ、すなわちあなた自身の実験室条件とフィールドデータの下であなた自身によって測定された値。 これらはユーザーパネルによって測定されます。 この分析のためにフィールドデータを評価しました。 SISTRIXでは、ラボデータとフィールドデータの両方にアクセスできます。 合計で、1850万ドメインの読み込み時間を分析しました。
英国からの測定値のみに関連する最初の3つの評価を除いて、残りの分析には世界中からの測定値が含まれています。 デスクトップ、モバイル、タブレットの価値もそこで評価されます。
これらの測定値をSISTRIXのテクノロジー検出と組み合わせて、ソフトウェアソリューションとテクノロジースタックに関するステートメントを作成できるようにしました。 テクノロジーを認識するために、インターネットの大部分を定期的にクロールし、見つかった機能(「フィンガープリント」)を1,000を超える関連するインターネットテクノロジーのリストと比較します。 最終的な分析には、統計的有意性を達成するのに十分な数のドメインで発生するテクノロジー-コア-ウェブ-バイタルの組み合わせのみを含めました。
結論
Googleは、 Core Web Vitalsを公式のランキング要素にすることで、ユーザーエクスペリエンスを脚光を浴びています。 私たちの分析では、現在の値の範囲がどれほど広いかを示すことができました。 使用するソフトウェアとテクノロジーに応じて、すべてが「すでに完璧」と「仕事の山」の間で表されます。
SEOの場合と同様に、読み込み時間の改善は継続的なプロセスである必要があります。 これは1回限りのタスクではなく、継続的な監視対象のプロセスです。 それは定期的な注意を必要とし、目標は時々調整される必要があります。
読み込み時間を最適化することはSEOの中心的なタスクではありませんが、それでもこの変更は検索結果でのWebサイトの有機的なパフォーマンスに影響を与えます。 SEOは、企業の多くの領域をまとめる必要のある横断的な機能です。
私たち自身は長い間私たちのウェブサイトの読み込み時間を無視してきました。 過去数週間で、私たちはこのトピックに取り組み、(非常に)良い値がどれだけの努力を必要とするかに気づきました。 それでもそれだけの価値はあります。Googleはそれに満足しているだけでなく、特に実際のユーザーは私たちに感謝しています。 したがって、トピックについては眠らないでください。 来年に延期するよりも、今年から始めるほうがいいです。