Wordpressの15以上の共有ホスティングのテスト、またはYandexインデックスから消えない方法

ステップ0：すべてはどのように始まりましたか？

Wordpressに名刺サイトがあります。 そして、ある晴れた日に、サーバーのサーバーの応答速度は、2000ミリ秒以上まで定期的に「ジャンプ」し始めました。 Yandexはこれに気づき、ウェブマスターに重大な警告を表示し、インデックスからサイトの25ページを削除しました（左2）。 そのため、ほとんどすべての検索トラフィックを失いました。



私のホスティングのサポートは私に動揺しましたが、何もできませんでした。「すべてのサーバーが機能しており、障害はありませんでした。」 そして、明らかに検索トラフィックが必要なので、ホストを変更する動機がありました。



次に、「wordpressのホスティング」広告および広告から17のホスティングサービスを選択し、そこにクリーンなWordpressをインストールして、サーバーの応答速度をテストしました。 以下は、それぞれの主な結果と簡単なコメントです。

試験パラメータ

• 次のようなパラメータについては、サーバーの応答速度のみがテストされました（私にとって最も重要だったため）。
  
  
  
  
  • DNSルックアップ
  • サーバー接続
  • 接続を作成する
  • 応答待ち
  • ダウンロード応答
  
  
  
• すべての結果は、デフォルトのテーマを持つWordpress 4.6.1に適用されます-ダウンロード、データベースの強化、ログイン、それだけです。 外部のテーマやプラグインは使用されていません。
  
  
  
  
• 私はテストサイトを「ワードプレスの関税」またはSSDディスクでの関税の開始に設定しました（最も安価なSSDの関税でさえ、テーマやプラグインのない1つのWPには明らかに十分なはずです）。
  
  
  
  
• 各サイトは、ピーク（すべてのグラフで算術平均値）を回避するために、60〜180秒の中断で少なくとも3回テストされました。 また、それらが1回だけ発生し、次の5〜15のテストで繰り返されなかった場合、急激にネガティブな指標を除外しました。 例：
  
  
  
  
  
  
  
  
• サイトは5つのサーバー（モスクワ、モスクワ、アムステルダム、サンクトペテルブルク、キエフ）でWEBO Pulsarを使用してテストされました（リンクは提供しませんが、希望および/または反対する人は自分で確認できることに注意する必要があります）、平均データを使用しました。
  
  
  
  

サイトの速度（Pagespeed InsightsおよびGTmetrix）をテストしなかったのはなぜですか？

サイトの速度は、多くの点で、正しいキャッシングの影響を受けます（たとえば、W3 Total Cacheを使用）。 残念ながら、ホスティング業者の多くはすぐに使用できるキャッシュをサポートしていません。誰かがMemcacheをインストールしていない、誰かが各編集後に手動でnginxを再起動する要求を行う必要がある、などです。



さらに、一部のホスティング事業者は、ローカル最適化済みのコンストラクタからWordpressをインストールします。WPを手動でインストールしたホスティング事業者は不利になります。 そのため、サーバーの応答速度に正確な問題があるため、このパラメーターでのみすべてのホスティング事業者をテストしました。

ステップ1：テスト参加者の選択

これらのホスティング事業者のほとんどは、何らかの方法（広告、検索結果など）で、ランディングページで「ワードプレスホスティング」から「ワードプレスの最速ホスティング」までを広告します。

• ルソニックス
• ムネ
• タイムウェブ
• 始める
• E-planet
• iPipe
• ハンディホスト
• Hostink
• ホタート
• ジーノ
• シャーロックホスト
• フォジ
• ブルーホスト
• インフォボックス
• ホストランド
• ユーロバイト

ステップ2：ホスティングプロバイダー自体のサイトをテストする

ホスティング事業者のサイト自体が大幅な遅延で応答する場合、基本レートで最高のパフォーマンスを期待できないことは明らかです。 そのため、最初はチェックを通じてロシア語の公式Webサイトを走りました。







標準では、サーバーの応答速度は200ミリ秒未満である必要があります（サイトチェックサービスの大部分は、200ミリ秒を超えるダウンロード速度をエラーとしてフラグします。GoogleのPage Insightsは300ミリ秒または400ミリ秒でエラーを表示し始めます）。 しかし、ホスティングサービスを400ミリ秒よりも早く残しました（突然、サイトが非常に重くなるか、ぶら下がってしまいます）。



その結果、6人のホスティング業者はステップ2に進みません。

• Hostink-メインサイトの応答速度が原因で、非常に不安定で数千ミリ秒に達するため、スケジュールから除外しました（非常に長くなりました）。 現時点では、ロシアのサーバーの応答速度は通常の制限内です。ウクライナでは400〜500ミリ秒、アムステルダムでは7000ミリ秒です。
  
  
  
  
• HotHat-サイトの応答速度は魔法のようですが、システムには技術的なドメインや一時的なIPなどがありません。したがって、ドメイン（大きすぎる）を転送/購入せずにサイトをインストールおよびテストすることはできません。
  
  
  
  
• Bluehost-メインサイトの応答速度が原因です。
  
  
  
  
• iPipe-不気味なコントロールパネル（共有ホスティングとvpsの両方を購入したため）で、デザイナーを介してftpアクセスを作成しようとしたか、少なくとも20分以上それを見つけようとしました。
  
  
  
  
• InfoBox-メインサイトの応答速度が原因です。
  
  
  
  
• ホストランド - メインサイトの応答速度が原因です。
  
  
  
  

ステップ3：純粋なWordpressのテスト

すべてのWordpressは、実験の純度のために、公式サイトのアーカイブから手動でインストールされました。 デフォルトのテーマであるプラグイン（Hello Dollyなどの基本プラグインを除く）はありません。



最初は、空のサイトのインジケーターを取得した後、W3 Total CacheやWP Rocketなどのカスタムテーマとそこにキャッシュをインストールしようとしましたが、すべてのホスティングでそのまま使用できました（一部のW3TCでは、サポートとのコミュニケーションの3日目でも動作しませんでした）ステージを除外しました。

ステップ4：まとめ

理論的には、提示されたすべてのホスティング事業者のサービスの価格がほぼ同じだったため、すべてが最速のホスティング事業者、つまり一種のハッピーエンドの選択で終了するはずでした。 しかし、皮肉なことに、私は両方のリストでTOP3に入ったTimewebで行きたかったということでした。 さらに、3日間のE-planetのサポートは、nginxを手動で更新しなくても、W3TCを動作させるのに役立ちませんでした（別のプラグインを使用することを提案しました）。



その結果、Timewebサポートは「NSサーバー側のリソースレコード」を更新し、サイトをPHP7とhttpsに切り替えました（速度のためではなく、既に好奇心から）、サーバーの応答速度は適切な250-300ミリ秒に低下しましたが、どこにも残しませんでしたが、サイトのインデックスが再作成され、徐々に発行に戻ります）

ステップ5：道徳

ロシア連邦のホスティングプロバイダーの市場では、サイトへのサーバーの応答速度に大きなばらつきがあり、検索結果に非常にマイナス（またはプラス）の影響を与える可能性があります。 したがって、ホスティング事業者を選択する際には、コントロールパネルや関税などだけでなく、このパラメータも確認することが非常に望ましいです。 私のテストがこれに役立つことを願っています）



PSサーバーの応答が遅い主な理由は、後でわかったように、ドメインのCloudFare CDNとの接続の違反であり（ドメインは不払いのために切断され、更新後に失敗し始めた）、ドメインは長い間レジストラーに再リンクされました。 したがって、W3TCと組み合わせてCloudFareをCDNとして使用することを決定し、（神が禁じる）ドメインを更新する時間がない場合、どこを掘るかを知ることができます。