لماذا موقع WordPress الخاص بك بطيء جدًا ودليل مفيد لتسريع الأمور

أردت أن أبدأ هذا المنشور بإعلامك بأن هذه ليست مجرد مقالة عامة أخرى بعنوان "كيفية تسريع WordPress".

لن أقوم بإعادة أي شيء يمكن العثور عليه بالفعل على الويب. لن أخبرك أنه يجب عليك تثبيت مكون إضافي للتخزين المؤقت ، وتمكين الضغط ، وتقليل css / js ، إلخ ....

بعد كل شيء ، يجب أن تعرف بالفعل كيفية القيام بهذه الأشياء. وإذا لم تقم بذلك ، فيمكنك العثور على هذه المعلومات العامة في مئات المدونات الأخرى.

بدلاً من ذلك ، تحتوي هذه المقالة على كل شيء مخصص / شبه مخصص قمت بتطبيقه في الشهر الماضي أو نحو ذلك لتسريع مدونة WordPress الخاصة بي ومنع عمليات الوصول المارقة بشكل أساسي من إفساد الخادم الخاص بي.

والسبب في أنه "غير معروف" هو أن الأساليب التي سأصفها ستكون خاصة جدًا بمدونتك الخاصة اعتمادًا على أنماط حركة المرور التي تراها.

ملاحظة: إذا كانت لديك مدونة بطيئة ولا تريد حقًا التعامل مع أي من الجوانب التقنية لتسريع موقع الويب ، فمن المحتمل أن تقوم بالتسجيل في خدمة مثل WP Engine .

هؤلاء الرجال متخصصون في استضافة WordPress وسيحرصون على تشغيل مدونتك بأسرع ما يمكن. لكن بطبيعة الحال ، هذا يأتي بثمن. يجب عليك التحقق منهم إذا كان هذا المنشور يذهب فوق رأسك :)

على أي حال ، قبل أن أشرح لك كيف ولماذا فعلت ما فعلته في مدونتي ، عليك أن تفهم بعض المفاهيم الأساسية حول WordPress والتخزين المؤقت التي سأصفها أدناه.

بعض حقائق ووردبريس المثيرة للاهتمام

لنفترض أنك اتبعت جميع الإرشادات حول كيفية تسريع WordPress بالفعل. مدونتك تبدو سريعة. يخبرك Webpagetest.org بأن مدونتك سريعة مثل الجحيم. كل شيء على ما يرام ، أليس كذلك؟ ليس بالضرورة .

اعتدت أن أشعر بنفس الطريقة بالضبط تجاه مدونتي. بعد كل شيء ، أنا أتبع معظم بروتوكولات التسريع القياسية. أقوم بتشغيل عدد قليل جدًا من المكونات الإضافية وتشعر مدونتي بسرعة كبيرة في ظل الاستخدام العادي من منظور القارئ البشري (الشبكات الإعلانية هي التي تبطئ مدونتي ، لذا أقوم بتحميل الإعلانات أخيرًا).

ولكن بعد ذلك بدأت في تحليل الرسوم البيانية لاستخدام وحدة المعالجة المركزية (CPU) الخاصة بي ، وغالبًا ما لاحظت فترات تحميل عالية على الخادم على الرغم من مستويات حركة المرور المنخفضة إلى المعتدلة. من حين لآخر ، قد يصبح خادمي غير قابل للاستخدام أو غير مستجيب لفترات طويلة.

لاحظ أن السبب الوحيد الذي جعلني أبدأ في الاهتمام بهذه الإحصائيات هو أنني قبل فترة كنت أدير متجري عبر الإنترنت على نفس الخادم مثل مدونتي. وبشكل دوري سأجعل العملاء يشكون من أن المتجر كان بطيئًا للغاية. عندما أجريت بعض البحث أخيرًا ، وجدت أن مدونة WordPress المحسّنة والمخزنة مؤقتًا بالكامل كانت تجلب الخادم الخاص بي إلى ركبتيه!

المغزى من القصة؟ فقط لأن اختبار السرعة يخبرك بأن مدونتك سريعة لا يعني بالضرورة أن كل شيء على ما يرام.

فيما يلي بعض الحقائق الممتعة حول WordPress ومكونات التخزين المؤقت مثل WP Super Cache و W3 Total Cache التي يجب أن تكون على دراية بها.

• ردود ووردبريس 404 بطيئة . في أي وقت تتلقى مدونتك وصولاً إلى صفحة غير موجودة ، يجب على خادمك الضعيف تحميل WordPress ، وتشغيل مجموعة من كود php ، والقيام بمجموعة من استعلامات MySQL ، ثم إخراج صفحة WordPress 404 المخصصة الخاصة بك. هذه مهمة تتطلب موارد كبيرة ولن يساعد التخزين المؤقت.
• لا يعمل المكون الإضافي للتخزين المؤقت جيدًا عند وجود معلمات GET في عنوان URL. على سبيل المثال ، اعتدت أن ألاحظ أن مدونتي ستتباطأ في الزحف كلما أرسلت انفجارًا إلى قائمة البريد الإلكتروني الخاصة بي. من الناحية النظرية مع التخزين المؤقت للملفات الثابتة ، يجب أن يكون الخادم الخاص بي قريبًا من الهزيمة.

  ولكن نظرًا لإدراج Aweber معلمات التتبع في عنوان URL ، فلن يتم تخزين أي من ملفاتي مؤقتًا بشكل كبير. نتيجة لذلك ، يتعين على WordPress إنشاء ملف ذاكرة تخزين مؤقت جديد تمامًا (على الرغم من وجوده بالفعل) ، ثم ضغطه وإرساله في كل مرة. أسوأ جزء هو أن هذه الملفات المخزنة مؤقتًا تُستخدم مرة واحدة فقط مما يجعلها مضيعة لموارد الخادم

• عمليات الوصول المارقة بطيئة. نظرًا لأن عمليات الوصول المارقة تتطلب تحميل WordPress افتراضيًا ، فإن أي روبوت أو زاحف سيئ يقرر إرسال بريد عشوائي إلى موقعك بطلبات سيئة يمكن أن يزيل مدونتك بسهولة تامة.
• قد يحتوي المكون الإضافي للتخزين المؤقت على خطأ أو عدم توافق مع طريقة إعدادك لمدونتك . على سبيل المثال ، اعتقدت لمدة 3 سنوات أن WP Super Cache كان يفعل الشيء الصحيح حتى بدأت في مشاهدة سجلاتي ولاحظت وجود خطأ في الكود. بسبب الطريقة التي أعددت بها الأشياء ، واجهت مشكلة حيث كان WP Super Cache يقوم بمسح طريق ذاكرة التخزين المؤقت الخاصة بي كثيرًا.

النقطة الأساسية التي أحاول توضيحها باستخدام النقاط أعلاه هي أنه كلما حدث وصول غير قياسي إلى مدونتك ، فإنه يستخدم الكثير من موارد الخادم بغض النظر عن كيفية إعداد مدونة WordPress الخاصة بك. وهذه الأنواع من عمليات الوصول هي التي ستضع الخادم على ركبتيه ، وليس حركة المرور العادية.

الكشف عن عمليات الوصول المخادعة

المفتاح الأول لتحسين مدونة WordPress الخاصة بك هو فهم أنماط حركة المرور التي تتلقاها مدونتك. أنا على استعداد للمراهنة على أن 99٪ من مستخدمي WordPress لا يفعلون ذلك. بدلاً من ذلك ، يتابعون بشكل أعمى ويثبتون العديد من المكونات الإضافية ويفترضون أن كل شيء يعمل بشكل صحيح. لا تشعر بالسوء ، لقد كنت بنفس الطريقة.

لذا فإن الخطوة الأولى هي معرفة ما يجري. هناك العديد من الطرق للقيام بذلك ، ولكن أسهل طريقة هي استخدام وضع التصحيح الذي يوفره المكون الإضافي WP SuperCache. ماذا يفعل هذا الوضع؟ في الأساس ، في كل مرة تتم فيها معالجة الوصول مباشرة بواسطة WordPress (موارد مكثفة) ، سيظهر في سجل WP Super Cache. إليك كيفية تمكين هذا الوضع.

ضمن علامة تبويب التصحيح في WP Super Cache Plugin ، ما عليك سوى النقر فوق خانة الاختيار "تمكين التصحيح" وأنت على ما يرام!

بمجرد تمكين التسجيل ، يمكنك النقر فوق ارتباط "ملف السجل" الذي سيوجهك إلى ملف يوضح بالتفصيل حركة مرور WordPress الخاصة بك. سيبدو مشابهًا للنص أدناه.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

الشيء المهم الذي يجب ملاحظته هو أنه في أي وقت ترى شيئًا في هذا السجل ، فهذا أمر سيء لأنه يعني أن WordPress يجب أن يقوم بعمل. ونظرًا لأن WordPress هو مستهلك للموارد ، فأنت تريده أن يقوم بأقل قدر ممكن من العمل.

ما الذي تبحث عنه في السجلات

تعد سجلات WP Super Cache رائعة لأنها تخبرك بكل ما يجري. لكن الكم الهائل من المعلومات يمكن أن يكون مربكًا إلا إذا كنت تعرف ما الذي تبحث عنه. إليك ما يجب الانتباه إليه في هذه السجلات.

• 404 أخطاء - هذه في الأساس عمليات وصول إلى صفحات غير موجودة في مدونتك. يستهلك كل وصول 404 يتم التعامل معه بواسطة WordPress الكثير من موارد الخادم ، لذا فأنت تريد التخلص منها في مهدها إن أمكن
• الوصول لمرة واحدة - هذه هي الطلبات التي تجعل الخادم الخاص بك يقوم بالتخزين المؤقت وضغط الصفحات التي سيتم استخدامها مرة واحدة فقط (المزيد حول هذا لاحقًا)
• انفجارات غريبة في حركة المرور - عادة ما تكون هذه روبوتات تدق مدونتك كلها مرة واحدة
• سلوك التخزين المؤقت الغريب - هل يتم مسح ذاكراتك المؤقتة عندما ينبغي؟ هل يتم تخزين كل شيء مؤقتًا بشكل صحيح في جميع الظروف؟

بعد الاحتفاظ بسجل لحركة مرور مدونتي لمدة أسبوعين ، اكتشفت الكثير من أوجه القصور التي سأصفها أدناه.

كانت الروبوتات تدق أرشيفي

أول شيء فعلته هو إلقاء نظرة على سجلات الخادم الخاصة بي لفترات تحميل وحدة المعالجة المركزية عالية. بعد ذلك ، قمت بتحليل سجلات التخزين المؤقت الفائقة الخاصة بي خلال هذه الفترات نفسها بالضبط لمعرفة ما إذا كان هناك أي عمل مضحك يحدث. تبين أنه مرة كل يومين أو نحو ذلك ، ستأتي مجموعة من الروبوتات وتطرق جميع صفحات أرشيف مدونتي في نفس الوقت!

نظرًا لأن صفحات الأرشيف هذه لا يتم تخزينها مؤقتًا بشكل افتراضي ، فإن مجموعة من عمليات الوصول المتزامنة كانت كافية لزيادة تحميل الخادم وجعل الأمور بطيئة للغاية. وفي بعض الأحيان ، تسبب ذلك في تعطل الخادم الخاص بي.

لذلك ألقيت نظرة فاحصة على مخرجات HTML الخاصة بي ولاحظت أن لدي مجموعة من روابط الأرشيف كجزء من رأس WordPress الخاص بي. لذلك ، ستأتي الروبوتات وبرامج زحف الويب الأخرى وتحاول تصفح الأرشيف.

بعد الكثير من البحث على Google ، اكتشفت أن بعض مشرفي المواقع الآخرين يواجهون مشكلات مماثلة.

عندما نرى مشكلات في تحميل موقعك عدة مرات ، فهناك عدد كبير من الزيارات لعناوين IP للخادم الوكيل ، والنظرية هي أن هذه الخوادم الوكيلة تخزن موقعك مؤقتًا وتضرب كل روابط الأرشيف هذه. العديد من عناوين IP التي نراها عندما يتسبب موقعك في حدوث مشكلات في التحميل هي عناوين IP للوكيل الخاص بالشركات والتعليم والحكومة / العسكرية والتي يبدو أنها تجلب المحتوى مسبقًا عندما يصل شخص ما إلى موقع ما.

الحل: تحقق لمعرفة ما إذا كان لديك عبارة php "wp_get_archives" في كود الترويسة لمدونتك وقم بإزالتها. بعد حذف هذا المقتطف الصغير ، اختفت جميع مداخلات الأرشيف.

كانت الروبوتات تصل إلى ملفات غير موجودة

الشيء الرئيسي الثاني الذي لاحظته هو أن هناك مجموعة من الروبوتات التي كانت تصل إلى الملفات الموجودة على الخادم الخاص بي والتي لم تكن موجودة. تكمن المشكلة في أنه في كل مرة يحدث فيها وصول إلى الملف ، يتعين على الخادم تحميل WordPress وتنفيذ مجموعة من كود PHP ثم إصدار صفحة 404.

الحل لهذه المشكلة هو تحرير ملف .htaccess (Google هذا إذا كنت لا تعرف ما هو) وإضافة الأسطر التالية.

RewriteCond٪ {REQUEST_FILENAME}! -f
RewriteCond٪ {REQUEST_FILENAME}! -d
RewriteCond٪ {REQUEST_URI}! (robots \ .txt | خريطة الموقع \ .xml (\. gz)؟)
أعد كتابة٪ {REQUEST_FILENAME} \. (css | js | html | htm | rtf | rtx | svg
| svgz | txt | xsd | xsl | xml | asf | asx | wax | wmv | wmx | avi | bmp | class | divx | doc
| docx | exe | gif | gz | gzip | ico | jpg | jpeg | jpe | mdb | mid | midi | mov | qt | mp3 |
m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg | odp | ods | odt | ogg | pdf
| بابوا نيو غينيا | وعاء | pps | ppt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma | wri |
xla | xls | xlsx | xlt | xlw | zip) $ [NC]
أعد كتابة القاعدة. * - [L]

بمجرد إدراج هذه الأسطر في ملف htaccess الخاص بك ، سيتحقق خادم الويب أولاً لمعرفة ما إذا كان الملف موجودًا. إذا لم يكن كذلك ، فسيصدر استجابة 404 دون تحميل WordPress.

كانت الروبوتات تصل إلى عناوين URL غير الموجودة

الأمر المؤسف في طريقة كتابة WordPress هو أنه إذا كان هناك وصول إلى مقال غير موجود في قاعدة البيانات الخاصة بك ، فسيتعين على خادمك تحميل WordPress وتنفيذ مجموعة من كود PHP وإجراء مجموعة من عمليات البحث في MySQL قبل إصدار استجابة 404.

إذا نظرت إلى سجلاتك بعناية ، فستلاحظ على الأرجح أنماطًا معينة من عمليات الوصول التي يمكنك استبعادها قبل أن تصل إلى WordPress.

على سبيل المثال ، لاحظت أن مجموعة من الروبوتات كانت تصل إلى موقعي باستخدام عنوان URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . وفي كل مرة ، يقوم خادمي بتحميل WordPress ويصدر استجابة 404.

لذا بدلاً من أن يتعامل WordPress مع هذه الطلبات ، أضفت الأسطر التالية إلى ملف htaccess الخاص بي

RewriteCond٪ {REQUEST_FILENAME}! -f
RewriteCond٪ {REQUEST_FILENAME}! -d
RewriteCond٪ {REQUEST_URI} www \ .facebook \ .com / plugins [NC]
أعد كتابة القاعدة. * 404.html [L، R = 404]

في السطور أعلاه ، أجد خادم الويب الخاص بي يبحث عن "www.facebook.com/plugins" في عنوان URL وأصدر فورًا استجابة 404 دون تحميل WordPress. أثناء استعراض سجلاتك ، ستجد العديد من عمليات الوصول المارقة مثل تلك التي وصفتها أعلاه. اكتب قاعدة .htaccess لكل وصول ولن يتم تحميل خادمك بعد الآن.

كانت الروبوتات تدق روابط التعليقات الخاصة بي

تذكر عندما أخبرتك أن عناوين URL التي تحتوي على معلمات GET يتم التعامل معها بشكل مختلف عن طريق المكون الإضافي للتخزين المؤقت؟ اكتشفت أن هناك عددًا هائلاً من الروبوتات تطرق مقالاتي بمجموعة معلمات "الرد على التعليق".

عندما يحدث هذا (اعتمادًا على إعدادات التخزين المؤقت) ، يتم تحميل Wordpress ويتم تقديم ملف ذاكرة التخزين المؤقت / مضغوط على الرغم من أنه ربما لن يتم الوصول إليه مرة أخرى على الأرجح. هذا مضيعة للموارد.

مثال مأخوذ من سجلي
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

الحل هو إعادة توجيه جميع برامج التتبع وبرامج الزحف باستخدام معلمات GET هذه إلى صفحة المقالة الرئيسية. هذا هو الكود الذي أضفته إلى ملف htaccess الخاص بي.

أعد كتابة٪ {QUERY_STRING} replytocom
أعد كتابة٪ {HTTP_USER_AGENT} ^ (. *) (bot | crawl | spider | slurp) [NC]
RewriteRule. * https: //mywifequitherjob.com٪ {REQUEST_URI}؟ [L]

يبحث هذا الرمز عن معلمة "replytocom" GET ثم يزيل هذه المعلمة من عنوان URL النهائي قبل تقديم الوصول إلى WordPress.

كانت برامج الزاحف تصل إلى المشاركات بدون شرطة مائلة

لست متأكدًا من سبب حدوث ذلك ، لكنني لاحظت مجموعة من برامج زحف الويب التي بدت وكأنها تحاول بشكل شرعي الوصول إلى المقالات الموجودة على مدونتي دون استخدام شرطة مائلة في عنوان URL.

كما كنت قد تكون أو لا تكون على علم، وURL ما هو مكتوب مثل http://yourblog.com/article/ مختلفة من URL مكتوبة مثل http://yourblog.com/article.

نتيجة لذلك ، عند مواجهة عنوان URL بدون شرطة مائلة ، يجب على WordPress التدخل وتشغيل مجموعة من كود PHP ثم إصدار إعادة توجيه 301 للمقالة بشرطة مائلة لاحقة. لإخراج WordPress من الصورة ، يمكنك ببساطة إدراج القاعدة التالية في ملف htaccess الخاص بك.

# إضافة مائلة زائدة
RewriteCond٪ {REQUEST_FILENAME}! -f
RewriteCond٪ {REQUEST_URI}! (. *) / $
أعد كتابة٪ {QUERY_STRING}!. * =. *
أعد كتابة القاعدة ^ (. *) $ 1 / [L، R = 301]

من خلال إضافة شرطة مائلة لاحقة ، فإنك تصدر إعادة التوجيه 301 إلى عنوان URL الصحيح قبل أن تصل إلى WordPress مما سيوفر موارد وحدة المعالجة المركزية.

لقد وجدت خطأ في WP Super Cache

على عكس معظم الأشخاص ، ليس لدي مدونة WordPress الخاصة بي مثبتة في جذر دليل public_html الخاص بي. بالإضافة إلى ذلك ، فإن الصفحة الأولى من مدونتي ليست صفحة "المنشورات" الخاصة بي أيضًا. عندما يتم تكوين مدونتك بنفس الطريقة التي أقوم بها ، هناك خطأ في WP Super Cache حيث يمكن حذف جميع ملفات ذاكرة التخزين المؤقت قبل الأوان حتى إذا قمت بتحميل ذاكرة التخزين المؤقت الخاصة بك مسبقًا.

لست متأكدًا مما إذا كان مؤلف المكون الإضافي على دراية بهذه المشكلة ، لكنني وجدت بشكل أساسي أنه كلما تم إصدار تعليق غير مرغوب فيه على مدونتي ، سيتم مسح ذاكرة التخزين المؤقت بالكامل بشكل خاطئ. نظرًا لأنني أتلقى التعليقات والبريد العشوائي عبر التتبع طوال الوقت ، فقد تم إفراغ ذاكرة التخزين المؤقت باستمرار مما جعل التخزين المؤقت أقل كفاءة.

لذلك قضيت عطلة نهاية الأسبوع في تصحيح هذه المشكلة وأخيراً طورت حلًا بديلًا. إذا كان أي منكم يعاني من نفس المشاكل ، فيرجى إبلاغي بذلك وسأوضح لك إصلاحي. المغزى من القصة هنا هو عدم افتراض أن المكون الإضافي للتخزين المؤقت يعمل فقط. أنت بحاجة إلى إلقاء نظرة على السجلات!

تعطيل الإضافات المكثفة لوحدة المعالجة المركزية

حتى إذا كنت قد اتبعت جميع خطواتي المذكورة أعلاه ، فمن المستحيل تصفية جميع عمليات الوصول المارقة قبل أن تصل إلى مدونة WordPress الخاصة بك.

لذلك ، ستتلقى دائمًا زيارات إلى موقعك لن يتم التعامل معها بكفاءة. لا توجد طريقة للتغلب عليها.

لكن الشيء المهم الذي يجب إدراكه هو أنه على الأرجح لن تواجه مشكلة في النطاق الترددي ، فستواجه مشكلة في وحدة المعالجة المركزية.

نتيجة لذلك (وقد يكون هذا غير بديهي) ، فأنت في الواقع لا تريد أن تفعل أي شيء مكثف لوحدة المعالجة المركزية مثل "تصغير" أو "ضغط" صفحاتك أثناء التنقل. يساعد التصغير والضغط في عرض النطاق الترددي على حساب استخدام وحدة المعالجة المركزية.

آخر شيء تريد القيام به هو تصغير وتخزين عمليات الوصول المارقة. في الواقع ، ربما يجب أن تفكر في عدم تصغير أو ضغط عناوين URL باستخدام معلمات GET أيضًا.

الأهم من ذلك ، يجب ألا تقوم بتشغيل أي مكونات إضافية مكثفة لوحدة المعالجة المركزية على موقعك. يحتوي WP-Engine على قائمة كبيرة من المكونات الإضافية المكثفة لوحدة المعالجة المركزية والتي ربما يجب أن تحاول تجنبها.

أثناء الاطلاع على قائمة المكونات الإضافية الخاصة بي ، لاحظت أنني كنت أستخدم مكونًا إضافيًا "منشورات مماثلة". وعندما ألقيت نظرة على الكود المصدري ، شعرت بالذهول عندما اكتشفت أن المكون الإضافي كان يقوم بمقارنة النصوص الكاملة للعثور على مقالات مماثلة والتي تمثل استنزافًا رئيسيًا لوحدة المعالجة المركزية وغير قابلة للتطوير.

بمجرد أن أجد بديلاً مناسبًا ، فإن هذا المكون الإضافي ينتقل بالتأكيد إلى سلة المهملات.

المغزى من القصة

فقط لأن اختبار السرعة عبر الإنترنت يخبرك أن مدونتك سريعة لا تعني الكثير في المخطط الكبير للأشياء.

لا تفهموني خطأ. تعد سرعة تحميل الصفحة مهمة لمحركات البحث ولعملائك المنتظمين ، ولكن عليك أيضًا حساب عمليات الوصول المارقة التي قد تتجاوز ذاكرة التخزين المؤقت وتجلب الخادم الخاص بك إلى ركبتيه.

لذلك لا تقم فقط بتثبيت التخزين المؤقت ومكونات التسريع الأخرى بشكل أعمى. خذ بعض الوقت لتحليل حركة المرور الخاصة بك وكتابة أكبر عدد ممكن من قواعد .htaccess لتقليل العمل الذي يتعين على WordPress القيام به. حظا طيبا وفقك الله!