より高速で最適化されたWordPressサイトの作成

ほとんどの消費者は、Webホスティングサービスに関する一般的な意見を持っています。 ホスティングプロバイダーに関するレビューを検索すると、多数の結果が見つかります。 そして通常、肯定的なものよりもはるかに多くの否定的なレビューがあります。 私はそれを修正できると思うので、WordPressのホスティングサポートオペレーターとして直面しなければならないタスクとそのソリューションを共有します。



悪いWebソリューションのリストを作成しました。また、サイトで何をすべきかについての推奨事項は価値がありません。 このリストは、顧客との何千時間ものコミュニケーション、および私が毎日遭遇するサポートとトラブルシューティングに基づいています。 提案されたもののいくつかは非常に原始的であり、いくつかの質問はより高度なレベルのものになります。 説明されている内容の多くは、成功したWordPressサイトと失敗したサイトを区別できます。 実際、適切なWebホスティングの選択が非常に重要であるという事実にもかかわらず、WordPressでサイトを最適化して成功させるには十分な時間を費やす必要があります。



経験豊富な開発者は、特定のWebソリューションの作成が得意であるという事実に集中しているため、関連する最適化手法の学習と適用を怠ったり、単に忘れたりすることがよくあります。 WordPressを初めて使用するか経験豊富な開発者であるかに関係なく、次のヒントは、はるかに高速で最適化されたWordPressサイトを作成するのに役立ちます。



1. ホスティングの変更が常に解決策とは限りません

2. 作業現場は開発用ではありません

3. 開発者ではない？ -コードに入らないでください

4. テーマとプラグインを保存しないでください

5. AJAXリクエストを監視する

6. 広告ネットワークと外部サービスを使用するときは注意してください。

7. 過度の最適化はパフォーマンスに悪影響を与える可能性があります。

8. 一般的なパフォーマンスの問題は簡単に診断できます。

9. WordPressのコアを変更するのは悪い

10. サイトを移行する前に、PHP 7およびHHVMとの互換性を確認します

11. 大規模なサイトはデータベースの最適化を行う必要があります

12. 普遍的なテーマが本当に必要ですか？

13. エラーログはあなたの友達です

14. Googleはここだけではありません

15. 123456は許可されなくなりました

16. スクリプトは常にサイト全体にロードする必要はありません

1.ホスティングの変更が常に解決策とは限りません

人々が知っておくべき最も重要なことの1つは、Webホスティングを変更しても、それ自体で問題が解決しないことです。 WordPressサイトにコードの問題や競合するプラグインがある場合、サイトはどこに置いても修復されません。



管理ホスティングはできる限り多くのサポートと支援を提供しますが、コードやプラグインのデバッグには関与しません。 PHPで適切なコードを記述し、プラグインとテーマの機能を作成および編集し、統合を編集し、サイトをコンテンツで満たすことは、Webホスティングの責任ではありません。 経験豊富な開発者がこれを行うことができ、サイトの作業を掘り下げ、問題を研究して解決します。

2.作業現場は開発用ではありません

千回繰り返すことができます。 作業サイトを開発に使用しないでください！ 現在、WordPressでホストされているほとんどすべてのホスティングサイトには、開発環境と実行環境があります。もちろん、理由がないわけではありません。 これらのソリューションを使用すると、何かをテストしようとして失敗したために作業サイトが偶然に落ちてしまうことを防ぎます。



そのようなソリューションを使用したくない場合は、LAMPまたはLEMPスタックと呼ばれるものを使用して、ローカル開発とテストを利用できます。 Linux、Apache / Nginx、MySQL、PHPで動作するように設計されています。 また、WAMPやMAMPなどのツールは、ローカル開発用のサーバーのアセンブリを簡素化し、高速化します。



これらのツールはすべて時間の経過とともに改善および開発されていますが、ローカル開発には独自の問題があります。たとえば、公開されたサイトを非常に正確に模倣しない環境などです。 まず、既存のデータを上書きする必要がなく、サイトがクラッシュしないように、ローカルマシンから作業サイトに作業をリダイレクトする方法を把握する必要があります。 設定によっては、このプロセスが別の問題になる場合があります。 MySQLのバージョンの違いにより、ポートの競合やエラーが発生する場合があります。



このような問題を回避するために、WordPressでローカルで作業するときのワークフローを高速化するために専用に設計されたDesktopServerやLocalなどのツールを使用することをお勧めします。 これらには、作業サイトにデータを転送する簡単な方法が含まれており、 WP-CLIの操作やマルチサイトモードの組み込みサポートなどの追加機能もあります。 WordPressの大規模なローカルコピーの操作は、非常に複雑になることがあるため、マルチサイトサポートだけでも非常に貴重です。



ランインおよびオンサイトのテスト環境は、問題がサイトを破壊する前に対処するのに役立ちます。

3.開発者ではない？ -コードに入らないでください

WordPressに不慣れな人、またはプログラミングの基本を知らない人は、ファイルを編集しないでください。 WordPressサイトがクラッシュする最も一般的な理由の1つは、誰かがコントロールパネルの外観エディターから直接PHPファイルを編集しているためです。 また、前述のとおり、作業サイトを編集しないでください。







管理者への推奨事項： wp-config.phpファイルに、すべてのユーザーのedit_themes 、 edit_plugins 、およびedit_filesを置き換える特権を持つ次のコードを配置します。 これにより、ユーザーはコードを編集してサイトをドロップできなくなります。

define('DISALLOW_FILE_EDIT', true);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、テーマファイルを編集したり、ユーザーのプラグインをインストールしたりする機能を無効にします。 これを行うには、 wp-config.phpファイルに次のコードを追加します 。

 define('DISALLOW_FILE_MODS', true);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコマンドは、テーマとプラグインのファイルエディターも無効にすることに注意してください 。 詳細はWordPress Codexをご覧ください。

4.テーマとプラグインを保存しないでください

数ドル節約したいのは明らかですが、テーマとプラグインを犠牲にしてこれを行うべきではありません。 WordPressはサイトの基盤であり、テーマとプラグインはプロジェクトの機能を結び付ける接着剤です。 プラグインを選択するときは、評判の良い開発者に固執してください 。 開発者による製品サポートの履歴を事前に学習し、評価を表示してレビューを読んでください。 WordPressディレクトリに 50,000以上のプラグインがある場合、このような調査は困難な作業になる可能性があります。



非常に多くの場合、時代遅れまたは標準以下のテーマやプラグインはマルウェアの影響を受けやすいか、悪意のあるコンテンツやサイトへのリンクをインストールしています。 WP Loopの調査によると、公開されているすべてのプラグインのほぼ半分が2年以上更新されていません。 これは衝撃的で恐ろしいことです。







プラグインの別のソースであり、検討する価値のあるものは、低価格でプレミアムソリューションを提供するサードパーティのカタログです。 このソースを選択するとき、開発者をサポートしません。 さらに、信頼性の低い更新ソースに依存しますが、これもあまり良くありません。



インストールされたプラグインの更新を待つことは、ThemeForestのようなサードパーティのディレクトリでソリューションを購入するWordPressユーザーにとって大きな問題です。 多くのテーマ開発者は、Revolution SliderやVisual Composerなどの追加のプラグインを埋め込みます。 ここでのポイントは、組み込みプラグインで脆弱性が検出された場合、ユーザーはテーマ開発者からの更新を待つ必要があることですが、プラグイン自体は文字通りすぐに修正できます。 これにより、多くのサイトがハッカーに対して非常に脆弱になります。

5. AJAXリクエストを監視する

サイトでのAJAXリクエストの使用方法と、AJAXを使用したプラグインをご覧ください。 たとえば、WordPress Heartbeat APIは/wp-admin/admin-ajax.phpを使用して、ブラウザーを介してAJAXにアクセスします。 これらの魅力の多くは不要です。 このファイルは、トラフィックが急増し、プロセッサに負荷がかかるときに特に頻繁に使用されます。 これにより、サイトの速度が著しく低下する可能性があります。 これは、それ自体に対してDDoS攻撃を仕掛けることにいくらか似ています。







admin-ajax.phpを使用するサードパーティのプラグインがある場合、それらが正しく対話することを確認してください。 HTTP POSTリクエストを簡単に追跡し、名前に基づいて、どのプラグインが呼び出されるかを判断できます。 たとえば、私が発見したget_shares_countは 、admin-ajax.phpをオーバーロードしたソーシャルネットワークと対話するための人気のあるプラグインであることが判明しました。 トラフィックの多いサイトでは、輻輳が何度も増加します。



ただし、AJAXはページ自体をロードした後にのみロードされるため、速度テストで対応する警告が表示された場合、AJAXは必ずしも問題ではありません。

6.広告ネットワークと外部サービスを使用するときは注意してください。

トラフィックの多いほとんどのサイトは広告収入を得ており、サードパーティの広告プロバイダーの拒否は不可能です。 ただし、サードパーティサービスの数が最小限であることが重要です。サイトの読み込み量を理解する必要があります。



広告ネットワークがWordPressサイトに与える影響を簡単に比較してみましょう。



テストパラメーター：サイズが300×250のGoogle AdSenseの3つの広告をテストリソースに追加しました。 このサイトにはデフォルトのテーマ-Twenty Sixteenがあります。 AdSenseをインストールする前と後にダウンロード速度を測定しました。

AdSenseの前（ テスト結果 ）

• 最初のロード：1.372秒
• リロード：1.013秒

接続によるコンテンツの内訳：

AdSenseの後（ テスト結果 ）

• 最初のロード：4.103秒。
• リロード：3.712秒

接続によるコンテンツの内訳：







3つのGoogle AdSense広告をインストールするだけで、6つの接続が追加されました。 広告があるWordPressサイトは、ない場合より2.7倍遅いです。 これは主に、追加のDNSルックアップ時間とページでのJavaScriptの使用によるものです。 これはすべて、1つのページに10個の広告を挿入する大規模なサイトで何が起こっているかの写真を作成する必要があります。 どんなに高速なホスティングを使用しても、サードパーティの広告接続による遅延は修正されません。



以下に、WordPressに大きな負荷をかける多数の外部HTTP広告リクエストがあるサイトの別の例を示します。







非常に多くのリクエストがあったため、アプリケーションサーバーはまったくロードしませんでした。 サイトは単に利用できず、すべての外部リクエストを満たそうとしました。







もう1つの良い例は、 Huffington Postの Webサイトです。 ロード速度テストを実行すると、広告ネットワークへの膨大な数のHTTPリクエストが表示されます。 簡単なテストでは 、ダウンロード速度が13秒以上であることが示されました。

• 最初のロード：15.908秒。 | 221 HTTPリクエスト
• リロード：13.957秒 | 66 HTTPリクエスト

しかし、多くのサイトが広告の大部分を獲得しているため、単に広告を削除するだけでは良い解決策にはなりません。 スクリプトの読み込みを最適化する必要があります。 スクリプトの非同期読み込みを使用するか、ページのレンダリングを中断しないように読み込みを遅らせることができます。 パフォーマンスに関しては、常に知覚されるパフォーマンスと実際のパフォーマンスのバランスを取る必要があります。

非同期JavaScriptの例：

 src="example.js" async
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JavaScript保留中の例：

 src="example.js" defer
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Patrick SextonにはJavaScriptを遅延させる別の方法があります 。 WordPressバージョン4.1以降には、スクリプトに簡単に非同期または遅延属性を追加できるフィルターがあります。



通常、外部サービスを使用して、応答をキャッシュします。 なんで？ そうしないと、 「死の問題の白い画面」が発生する可能性があるためです。 追加する各外部サービスは、信頼できる信頼できるソースからのものでなければなりません。 最終的に、それらが落ちた場合、それはあなたのサイト全体またはあなたのビジネス運営に影響を与えます。

7.過度の最適化はパフォーマンスに悪影響を与える可能性があります。

インターネットには、WordPressサイトの高速化と最適化の方法に関する「ヒント」を提供する何千もの記事があります。 しかし、ユーザーがサイトを過剰に最適化する場合ほど悪いことはありません。 はい、これはあなたが思っているよりもずっと頻繁に起こります。 WordPressサイトの所有者は、何かを追加するとダウンロード速度が2倍になると感じることがよくあります。



以下に、定期的に発生するいくつかの問題をリストします。

キャッシュをキャッシュしようとしました

通常のVPSまたは通常のサーバーとは異なり、多くのWordPressホストには独自のキャッシングがあり、サーバーレベルで実行されます（たとえば、RedisやMemcache）。 多くのプロバイダーは、すべてのタイプの問題を引き起こす可能性があるため、キャッシュプラグインの使用を禁止していますが、ほとんどの場合、502 Bad Gatewayです。 私が呼ぶように、「キャッシュをキャッシュする」ことは決して良い考えではありません。



WP RocketやCache Enablerなどのプラグインは優れていますが、サイトを高速化するために特別な支援が必要なサーバー向けに設計されています。 今日よく使用される一般的なサーバー側のキャッシュ形式であるオブジェクトキャッシュについて詳しく読むことをお勧めします。

2×CDN = 2×ダウンロード速度ですよね？

CDNは、適切な構成を使用する場合にのみ、地理的に異なる地域のコンテンツの読み込み時間を大幅に短縮できます。 最も一般的なサービスの1つであるCloudflareは、技術的にはプロキシサーバーであり、サイトのコンテンツだけでなくすべてのDNSを送信するため、通常のCDNプロバイダーとは若干異なります。



通常、Cloudflareに接続し、さらにKeyCDNまたはMaxCDNを追加するユーザーが表示されます。 これは、多くの場合、新しいサービスを試すための推奨事項が表示されている誰かのブログ投稿を読んでいるという事実によるものです。 彼らは新しいサービスをインストールし、すでに接続されているサービスを忘れ、この組み合わせは特定のシナリオで機能しますが、多くの場合、すべてが混乱して終わります。 ほとんどの場合、CloudflareまたはサードパーティのCDNプロバイダーのいずれかを使用する必要があります。それぞれに長所と短所があります。

膨大な数のSEOプラグインが検索結果の上位に位置しない

検索結果を支配したい、これは理解できる。 ただし、SEO用の3つのプラグインを追加しても、この目標の達成には役立ちません。 実際、 重複したメタタグを表示するなど、All In One SEO、Yoast、およびSEO用の他のプラグインを同時に使用すると、多くの互換性の問題が発生します 。 追加のプラグインをインストールしても、検索エンジン最適化の改善が保証されるわけではありません。

8.一般的なパフォーマンスの問題は簡単に診断できます。

あなたが上級のWordPressユーザーでなくても、一般的なパフォーマンスの問題を見つけるのはかなり簡単です。 上級ユーザーの場合、最新のHTTP / 2プロトコルをサポートするため、 WebPageTestの使用をお勧めします。 それ以外の場合は、 Pingdomが適しています。 単純なカスケード分析により、不必要なリダイレクト、ファイルの欠落、過剰なDNSクエリ、またはサードパーティのスクリプトまたは広告ネットワークを介したサイトの過負荷があるかどうかがわかります。



パフォーマンスレーティングとレスポンスコードを確認すると、サイトのエラーの解決を開始する方法がわかります。

9. WordPressのコアを変更するのは悪い

ルールにする：コードを機能させるためにWordPressコアを変更するのは悪い考えです。 特に作業現場で。 このような操作により、サイトに脆弱性が生じる可能性があります。 また、新しいカーネルバージョンの変更の更新を提供しなかった場合、新しいWordPressの更新ごとに編集内容が失われます。 とりわけ、組み込みのWordPressツールと機能、プラグイン、子テーマ、フックを使用する場合。

10.サイトを移行する前に、PHP 7およびHHVMとの互換性を確認します

PHP 7とHHVMは、WordPressサイトのパフォーマンスを向上させるのに非常に役立つことが知られています。 そしてもちろん、最新かつ最高のものを使用することは常に素晴らしいことです。 ただし、最初に、サイトがこれらのテクノロジーと互換性があることを確認してください。 たとえば、PHP 5.6からPHP 7にアップグレードする場合、フレームワーク環境またはローカルでWordPressサイトのすべての機能をテストして、互換性の問題がないことを確認する必要があります。 古い、しかし非常に重要なプラグインはPHP 7では動作しない可能性があります。つまり、最新の技術ソリューションに移行する前に、PHP 7のアップグレードを待つ必要があります。

11.大規模なサイトはデータベースの最適化を行う必要があります

大規模なWordPressサイトの速度を低下させる最も簡単な方法の1つは、データベースの最適化を行わないことです。 WordPressの古いバージョンのトレースのクリーンアップや未使用のテーブルの削除などの単純なタスクは、サイトの速度低下を防ぐことができます。 また、多くの古いサイトがまだデータベースでMyISAMを使用していることに気付きました。 現時点では、InnoDBははるかに高速で信頼性の高いソリューションです。



わずか数ステップでテーブルを変換できます。 開始するには、MySQL 5.6.4以降を使用していること、および予防措置としてバックアップしていることを確認してください。 この例では、 wp_commentsテーブルを使用します。 ALTERコマンドを実行して、InnoDBで動作するように変換します。

 ALTER TABLE wp_comments ENGINE=InnoDB;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

phpMyAdminの現在のバージョンを使用している場合は、必要なテーブルを開いて[操作]タブに移動し、そこでストレージメカニズムを変更できます。







別の簡単な最適化方法は、データベースに保存されている修正の数を無効にするか制限することです 。 以下をwp-config.phpに追加して、完全に無効にすることができます。

 define('WP_POST_REVISIONS', false );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、投稿またはページごとに保存される金額を変更します。

 define('WP_POST_REVISIONS', 3);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

200を超えるバージョンの投稿がある多くのサイトに出会いました。 ホスティングに内部最適化がない場合は、WordPressの設定を手動で設定する必要があります。デフォルトでは、無制限の数の修正が保存されるためです。



多くの変更がサイトに保存されている場合、phpMyAdminでこのスクリプトを実行して削除できます。

 DELETE FROM wp_posts WHERE post_type = "revision";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの目的でWP-Optimizeプラグインを使用することもできます。

12.普遍的なテーマが本当に必要ですか？

WordPressコミュニティで私が見ている大きな問題があります。 人々は普遍的なテーマを購入し、その機能の1％しか使用しません。 彼らはデモページを見て、購入の必要性を説得する美しいスライダーとカスタムブロックを見ますが、実際には、これらの機能は決して有用ではないかもしれません。 よりシンプルで機能性の低いテーマを購入することで、お金と時間の両方を節約できます。シンプルなテーマは箱から出してすぐに速くなるため、最終的には最適化に費やされます。



すべての普遍的なトピックが悪いとは言いたくありません。 実際、適切な設定を行うと、非常に迅速に機能します 。 ロードに700ミリ秒かかるAvadaテーマの例を次に示します 。







ただし、既存のトピックを最適化するには多くの知識と時間がかかります。 ほとんどのWordPressユーザーにとって、テーマの機能の半分を使用しない場合は、よりシンプルなテーマを使用するのが効果的です。 美しいバナーや派手なスライダーに惑わされないでください。 多くの場合、これらのオプションセットはすべて、サイトの速度を低下させるだけです。

13.エラーログはあなたの友達です

WordPressファイルとwp-config.phpファイルの処理方法を知っている場合、エラーログが役立ちます。 定期的にチェックすることで、あらゆる種類の頭痛から身を守るだけでなく、WordPressをより深く理解することができます。 ホスティングのテクニカルサポートに連絡する前にログを確認するユーザーはほとんどいません。 wp-config.phpのいくつかの簡単な設定で、エラーロギングを有効にできます。これはデフォルトで/wp-content/debug.logに保存されます。



ロギングを有効にします。

 define( 'WP_DEBUG_LOG', true );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ページごとのログ出力：

 define( 'WP_DEBUG_DISPLAY', true );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

詳細については、 WP_DEBUG codexを参照してください 。

14. Googleはここだけではありません

Googleで回答を検索することを恐れないでください。 インターネットには、多くのヒントとソリューションがあります。 数分以内に、ほとんどの問題を修正できます。 「GoDaddyでDNSを変更する方法」や「sFTPを使用する方法」などの一般的な質問への回答は、Googleで簡単に見つけることができます。



StackExchangeやWordPress Codexなど、インターネットには大規模なWordPressリソースがあります。もちろん、チュートリアルを含む数百のブログもあります。



さらに、優れたWordPressホスティングには、ユーザーが質問への回答を見つけるのに役立つ独自の便利なナレッジベースが備わっている可能性が高く、一般的な場合、ホスティングはユーザーサポートの時間を短縮します。

15. 123456は許可されなくなりました

SpashDataは、毎年最も一般的に使用される（200万を超える）パスワードパスワードのリストを作成します。 2015年に最も一般的なパスワードが「123456」であったことは驚くことではありません-2014年と同じです。 このようなパスワードを使用すると、サイトが文字通りハッキングから一歩離れたままになるため、これはホスティングにとってかなり不快です。 最適なソリューションの1つは、 KeePassまたはその同等物を使用することです。 クラウド内の暗号化されたパスワードは、常に「123456」よりもはるかに安全です。

16.スクリプトは常にサイト全体にロードする必要はありません

残念ながら、手動で制御される静的なWebサイトとは異なり、WordPressサイトはテーマ開発者とプラグインによって支配されています。 また、すべての開発者がソリューションのパフォーマンスを気にするわけではありません。 サイトのすべてのページにスクリプトをアップロードする膨大な数のプラグインがありますが、プラグイン自体はそのうちの1つでのみ使用されます。 数十のプラグインが存在する可能性があることを考えると、問題は倍増し、サイトの速度は低下します。



そのような例の1つとして、人気のあるContact Form 7プラグインがあります。以下に示すように、CSSおよびJavaScriptファイルをWebサイトのホームページにアップロードしますが、連絡先フォームは使用しません。







これを修正するにはいくつかの方法があります。 1つ目は、WordPress 3.1で導入されたwp_dequeue_script（）関数を使用することです。 サイトのダウンロードキューからスクリプトを削除できます。 Contact Form 7でこの関数を使用する方法の例を次に示します。ContactForm 7開発者には、必要な場合にのみJavaScriptとCSSを使用する方法に関するドキュメントもあります 。



2番目の方法は、 GonzalezやPlugin Organizerなどの特別なWordPressプラグインを使用することです。 以下は、当社のサイトでゴンザレスを使用した例です。 便利な設定ウィンドウを使用すると、数回のマウスクリックで連絡先ページを除くすべてのページからContact Form 7プラグインのJavaScriptファイルとCSSファイルを削除できるため、サイトの残りの読み込み速度が向上します。

おわりに

WordPressがすべてのWebサイトの28％以上で使用されている理由があります 。 これは非常に信頼性が高く、便利で多機能なCMSです。 ホームブログの著者から数百の企業まで、誰もが彼に毎日依存しています。 しかし、ほとんどのプラットフォームと同様に、WordPressを誤って使用したり、最適化しない場合、WordPressを使用するとすぐに頭痛の種になります。