تحسين ذاكرة التخزين المؤقت للموقع الإلكتروني

عادةً لا يكون السبب الجذري لـ “بطء” الموقع الإلكتروني ليس صورة معينة، بلطلب الارتباط + توليد الخادم + توزيع الموارد الثابتةالناجمة عن التراكب:

• يكون المستخدمون بعيدين جداً عن خوادمك، وتكون سرعة نقل البيانات عبر الشبكة عالية (أكثر وضوحاً عبر القارات)
• يقوم ووردبريس بتشغيل PHP، ويتحقق من قاعدة البيانات، ويعرض القالب لكل طلب → TTFB (الوقت حتى أول بايت) لأعلى
• تقوم الصفحات أيضًا بتحميل JS/CSS/خطوط/خطوط/برامج نصية لجهات خارجية، مما يؤدي إلى إبطاء العرض والتفاعل.

المكوّن الإضافي للتخزين المؤقتيتمثل جوهر الحل في حفظ نتائج الصفحات “مزدوجة العد” بحيث لا يضطر الخادم إلى إعادة حسابها في كل مرة، وتقليل TTFB بشكل كبير من خلال السماح لعدد أكبر من المستخدمين بالوصول إلى ذاكرة التخزين المؤقت في ظل الاستراتيجية الصحيحة.وثائق ووردبريس الرسميةوأُشير أيضًا إلى أن الإضافات مثل W3 Total Cache وW3 Total Cache يمكن تخزين الصفحات مؤقتًا كملفات ثابتة ثم عرضها مباشرةً للمستخدم، مما يقلل من عبء المعالجة على الخادم.

قبل قراءة هذه الصفحة، تذكّر 3 قواعد صارمة قبل قراءة هذه الصفحة

1 - المكونات الإضافية للتخزين المؤقت للصفحات في نفس الوقت واحد فقط

النتيجة الأكثر شيوعًا لتمكين إضافات التخزين المؤقت المتعددة في نفس الوقت ليست أسرع:

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

2 - مواقع التجارة الإلكترونية/العضوية/المواقع متعددة اللغات: التخزين المؤقت ليس “مفتاح تشغيل/إيقاف تشغيل”، بل هو “نظام قواعد”.”

وثائق أداء WooCommerce الرسميةتذكير صريح: في المكون الإضافي لذاكرة التخزين المؤقت للتأكد من عربة التسوق / الدفع / الحساب يوصى أيضًا بتجنب ضغط ملفات JavaScript (حيث يميل إلى التسبب في مشاكل في التوافق).

3 - “المكون الإضافي لذاكرة التخزين المؤقت ≠ CDN”، ولكن المكون الإضافي لذاكرة التخزين المؤقت هو أساس CDN

مكوّن إضافي للتخزين المؤقت لحل مشكلة “نقصان عدد محطات المصدر”;CDN حل مشكلة “المحتوى الأقرب للمستخدمين”. العلاقة بين الاثنين متراكبة: أولاً، يتم الضغط أولاً على مصدر TTFB، ثم يتم تسليم الموارد الثابتة إلى CDN لنشرها، وهو المسار الأكثر استقراراً للمستخدمين العالميين.

اختيارات سريعة: 4 من السيناريوهات الأكثر شيوعًا للمواقع الإلكترونية

إذا كنت لا ترغب في قراءة المقال بأكمله، لا يمكنك أن تخطئ في الخيارات الأربعة التالية:

1. الرغبة في توفير المال والاستقرار والتوجه نحو الوصول العالمي → صاروخ WP(مدفوع)
2. الاستضافة بشكل صريح LiteSpeed/OpenLiteSpeed → ذاكرة التخزين المؤقت لايت سبيد(مجاني ولكن يعتمد بشدة على سعة الخادم):: تتطلب وظيفة التخزين المؤقت مكونات خادم LiteSpeedالعمل بعد ذلك فقط
3. مواقع/مدونات/مدونات المحتوى/مواقع الوثائق التي تريد أن تكون مجانية ومستقرة → ذاكرة التخزين المؤقت الفائقة لـ WP Super Cache(ذاكرة تخزين HTML ثابتة):: توليد ملفات HTML ثابتة لتقديمها إلى معظم المستخدمين غير المسجلين
4. لديك فرق تقنية لضبط التحكم الدقيق (CDN/التخزين المؤقت للأشياء/وحدات متعددة) → W3 إجمالي ذاكرة التخزين المؤقت W3(قوي ولكن معقد):: يحافظ على إطار شامل للأداء مع تكامل CDN

ما الذي تخزنه ذاكرة التخزين المؤقت بالضبط؟

“لماذا لا تزال بعض المواقع بطيئة مع التخزين المؤقت”، قمنا بتقسيم أداء ووردبريس إلى 5 طبقات:

1. ذاكرة التخزين المؤقت للمتصفح:: جعل الوصول الثانوي أسرع للمستخدمين (رؤوس ذاكرة التخزين المؤقت للموارد الثابتة، وأرقام الإصدارات)
2. ذاكرة التخزين المؤقت للصفحة:: إخراج صفحة التخزين المؤقت كـ HTML (الطابع الرئيسي لهذه الصفحة)
3. ذاكرة التخزين المؤقت للكائن:: كائنات نتائج استعلام قاعدة البيانات المخبأة (المحطات الديناميكية أكثر قيمة)
4. PHP OPcache PHP:: ذاكرة التخزين المؤقت PHP bytecode (عادةً ما يتم تكوينها بواسطة الخادم، وليس محور المكون الإضافي)
5. CDN/ذاكرة تخزين مؤقت حافة CDN:: وضع الموارد في عقد أقرب إلى المستخدمين

محور هذه المقالة: المكون الإضافي للتخزين المؤقت للصفحات;
ولكن يتم تذكيرك باستمرار أن المواقع الإلكترونية غالبًا ما تحتاج إلى مزيج من 2 + 5 لتكون “سريعة حقًا”.

المكوّن الإضافي 1:صاروخ WP(مقابل رسوم) - البرامج المتكاملة “الموفرة للعقل”

يحظى WP Rocket بشعبية كبيرة في مشهد “ووردبريس” ليس لأنه سحري، ولكن لأنه يجعل الأنواع الثلاثة الأكثر شيوعًا من الأداء تعمل في “حزم يمكن التحكم فيها”:

• التخزين المؤقت للصفحات (يقلل من موقع المصدر TTFB)
• التحميل المسبق للتحميل/التسخين المسبق لذاكرة التخزين المؤقت (لتحسين تجربة الزيارة الأولى مع الوصول الموزع عالميًا)
• التحسينات الرئيسية للواجهة الأمامية (خاصةً زمن استجابة JS، ومعالجة CSS، وما إلى ذلك)

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

1.1 لمن هو صاروخ WP Rocket؟

WP Rocket مناسب بشكل خاص لهذه المحطات:

• الموقع الإلكتروني للشركة، وموقع العلامة التجارية، وموقع تسويق المحتوى، والصفحة المقصودة (حركة المرور من بلدان ومناطق متعددة)
• أريد أن “أبدأ البث المباشر بسرعة، الاستقرار أولاً”، لا أريد تهجئة الكثير من تركيبة المكونات الإضافية المجانية
• لا يوجد مهندسو عمليات/أداء مخصصون، ولكن لديهم خبرة ومتطلبات تحسين محركات البحث
• WooCommerce يمكن استخدامه أيضًا، ولكن بحذر أكبر (المزيد عن هذا لاحقًا في هذا القسم)القواعد والمخاطر）

1.2 قيمته الرئيسية في سيناريوهات الوصول إلى الويب (وليس مجرد “تبديل ذاكرة التخزين المؤقت”)

أ. التحميل المسبق لذاكرة التخزين المؤقت: حل مشكلة “الزيارات الأولى غير المستقرة بسبب الوصول الموزع إلى المواقع الإلكترونية”

ستواجه تباطؤًا نموذجيًا للغاية عندما يكون مستخدمو الموقع مشتتين:
يفتح مستخدم في منطقة ما صفحة لأول مرة ويصادف أن تكون الصفحة خارج ذاكرة التخزين المؤقت أو لم يتم تسخينها مطلقًا → يتحمل هذا المستخدم تكلفة العرض PHP/DB كاملة.
آلية التحميل المسبقأهمية ذلك هو:دفع تكاليف “الجيل الأول” مقدماًستكون الزيارة الأولى للبرنامج “خنزير غينيا”، مما يقلل من احتمالية "الزيارة الأولى كخنزير غينيا".

• عدم التحميل المسبق: من يصل أولاً يعاني
• مع التحميل المسبق: من خلال النظام في الخلفية توليد موحد لذاكرة التخزين المؤقت، تكون تجربة الزيارة الأولى أكثر استقرارًا

ب. تنفيذ جافا سكريبت المؤجل: الميزة الأسهل “للشعور الفوري” في زيارة الموقع الإلكتروني، ولكنها أيضًا الأكثر خطورة.

يضع WP Rocket رسميًا “تنفيذ JS المتأخر” يصفه بأنه أقوى تحسينات JS: سيؤجل تنفيذ النص البرمجي إلى ما بعد أن يقوم المستخدم بتفاعل ما (تحريك الفأرة، لمس الشاشة، التمرير، الضغط على مفتاح، إلخ) لإعطاء الأولوية لعرض الصفحة.

هذا أمر مهم للوصول إلى الموقع الإلكتروني لأن تحميل البرامج النصية وحظر التنفيذ من المرجح أن يتم تضخيمه على الشبكات العابرة للقارات:

• تنزيل الموارد بشكل أبطأ → من المرجح أن يتعطل مؤشر الترابط الرئيسي بسبب البرامج النصية
• من المرجح أن تؤدي البرامج النصية للجهات الخارجية (الإحصائيات والإعلانات والمكونات الإضافية للدردشة) إلى تفاقم التأخير في INP/التفاعل

ولكن يمكن أن يسبب أيضاً مشاكل:

• من المحتمل أن تؤثر JS المتأخرة على: القوائم، والتناوبات، والنوافذ المنبثقة، والتحقق من صحة النموذج، والمدفوعات، وتتبع عمليات الدفن
• لذا فهي مناسبة لاستراتيجية “خطوة بخطوة + استبعاد القائمة السوداء”.

ج. التوافق مع المكونات الإضافية/الأنماط الأخرى: “عدم التعارض” ليس مثل "راحة البال".”

أدرجت WP Rocket رسميًا “إضافات/أنماط غير متوافقة”، لأسباب تشمل آليات مثل التخزين المؤقت للمخرجات التي من شأنها أن تؤثر على التخزين المؤقت/التحسين في WP Rocket.

• إذا كان موقعك مليئًا بالمكونات الإضافية والقوالب، فكّر في “تحسين الأداء” كمشروع صغير للتشغيل: اختبار الانحدار لكل تغيير (النماذج، وتسجيلات الدخول، والمدفوعات، والتبديل بين عدة لغات، وما إلى ذلك).

1.3 تذكير خاص لموقع WooCommerce/الموقع الديناميكي

التذكير الأساسي من وثائق WooCommerce الرسمية عند تكوين إضافة التخزين المؤقت هو

• عربة التسوق / الدفع / الحساب لا تقم بالتخزين المؤقت
• علاوة على ذلك، يوصى بما يليتجنب ضغط ملفات JS

لماذا؟ للأسباب التالية:

• اعتماد قوي على عربة التسوق والدفع وصفحة الحساب cookie / الجلسة / nonce
• بمجرد أن تتعامل ذاكرة التخزين المؤقت مع هذه الصفحات على أنها “صفحات ثابتة”، لن تعمل الأزرار وستتعطل معلومات السعر/المخزون/الحساب.
• إليك الجزء المخيف: يمكن أن تكون اختباراتك جيدة في منطقة ما وتواجه مشاكل في منطقة أخرى بسبب التناقضات في CDN/ضربات ذاكرة التخزين المؤقت!

1.4 توصيات مستوى استراتيجية البرنامج المساعد للتخزين المؤقت 1.4

المستوى 1: مزايا الأمان الأساسية (يجب على جميع المحطات تقريبًا القيام بذلك)

• تمكين التخزين المؤقت للصفحة
• يفتحالتحميل المسبق لذاكرة التخزين المؤقت(تعزيز استقرار الزيارة الأولى)
• سياسة معقولة للتخزين المؤقت للمتصفح (يمكن تنفيذ أي من الطبقتين WP Rocket/Server/CDN)

المستوى 2: مكافأة متوسطة، ومخاطر متوسطة (مناسبة لمعظم مواقع المحتوى)

• تأخر تحميل الصور/إذاrame (صفحة تحسين الصور تذهب إلى أبعد من ذلك)
• التحكم في حجم CSS (على سبيل المثال إزالة CSS غير المستخدمة)

المستوى 3: عالي المردود ولكن عالي المخاطر (يجب أن يكون لديك قائمة تحقق من اختبار الانحدار)

• تأخر تنفيذ JavaScript (يعطي الأولوية للعرض، ولكنه قد يؤثر على التفاعل)
• ضغط/دمج JS/CSS: كن حذرًا للغاية مع التجارة الإلكترونية/الأعضاء/متعددي اللغات (يحذر WooCommerce أيضًا من مخاطر ضغط JS）

1.5 الأسعار والتراخيص

• WP Rocket هو ترخيص مدفوع، مع وجود تراخيص مختلفة حسب عدد المواقع.

المكوّن الإضافي 2:ذاكرة التخزين المؤقت لايت سبيد (LSCWP)--فرضية “القمم المجانية” هي أن الخادم هو في الحقيقة LiteSpeed.

لدى الكثير من الأشخاص فكرة خاطئة عن LiteSpeed Cache: فهم يعتقدون أنه مجرد مكون إضافي لـ WordPress يمكنك تثبيته والحصول على كل القوة على أي مضيف تمامًا مثل WP Rocket. إنه ليس كذلك.

وثائق LiteSpeed الرسميةشرح واضح: تتطلب ميزة التخزين المؤقت لـ LSCWP ميزة التخزين المؤقت لـ LSCWP LiteSpeed Server لأنها تتصل بذاكرة التخزين المؤقت للصفحات المدمجة في LiteSpeed Web Server (LSCache)؛ المكون الإضافي مسؤول عن إخبار الخادم بالصفحات القابلة للتخزين المؤقت، ومدة التخزين المؤقت، وتشغيل التنظيف بالعلامات.

تأتي القوة الأساسية لذاكرة التخزين المؤقت LiteSpeed Cache من “التخزين المؤقت للصفحات على مستوى الخادم (LSCache)”. بدون خوادم LiteSpeed/OpenLiteSpeed، لا توجد مثل هذه الميزة الأساسية.

2.1 ذاكرة التخزين المؤقت لايت سبيدلمن

تناسب:

• لوحة الاستضافة الخاصة بك مصنفة بوضوح لايت سبيد / أوبن لايت سبيد(على سبيل المثال، سيكتب العديد من مضيفي cPanel)
• أنت تريد “حلاً مجانيًا يمكنه أيضًا تشغيل TTFB قويًا وتزامنًا.”
• أنت على استعداد لقبول: إنه قوي جدًا، ولكنه أيضًا أكثر مفاهيمية (TTL، العلامة، التطهير، ESI، الزاحف...)

ليس تماماً:

• أنت لست متأكدًا من ماهية خادم الويب الذي يستضيفه المضيف، أو التأكد من أنه Nginx/Apache (إلا إذا كنت تريد فقط استخدام بعض ميزات تحسين الواجهة الأمامية، ولكن بعد ذلك السعر/الأداء والتعقيد ليس بالضرورة أن يكون فعالاً من حيث التكلفة)
• أنت موقع تجارة إلكترونية/عضوية/موقع متعدد اللغات معقد، ولكن ليس لديك عملية اختبار (LSCWP قوي، ولكن من السهل أيضًا “تخزين المحتوى الخاطئ مؤقتًا”)

2.2 آلية التخزين المؤقت الخاصة به: لماذا هو أشبه بـ “جزء من سعة الخادم”

يمكنك كتابة آليات عمل LiteSpeed Cache كـ “شرح هندسي”:

• WP Rocket / WP Super Cache هذا أكثر على جانب WordPress/PHP من التخزين المؤقت والتحسين;
• LSCWP إنه مزيج من لوحة تحكم ووردبريس + ذاكرة التخزين المؤقت LSCache المدمجة في LiteSpeed Server: المكوّن الإضافي مسؤول عن إصدار القواعد وإشارات التنظيف، ويحدث التخزين المؤقت الحقيقي عالي السرعة للصفحة فيطبقة الخادم。

هذا له تأثير مباشر على تجربة موقع الويب: عادةً ما يكون التخزين المؤقت للبصق على مستوى الخادم أخف وأسرع وأكثر تزامنًا (خاصةً مع تدفق الزيارات والزيارات عالية التردد من برامج زحف محركات البحث).

3.2.3 “الطريقة الصحيحة” لفتح LSCWP لسيناريوهات مستخدم الموقع الإلكتروني”

لقد قسمنا “الطريقة الصحيحة للفتح” إلى 4 مستويات:

الطبقة 1: سياسة ذاكرة التخزين المؤقت للصفحة (تحدد ما إذا كان يمكن أن تنخفض TTFB بالفعل)

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

هذه الطبقة، إذا تم تنفيذها بشكل صحيح، تكون أكثر وضوحًا بشكل مباشر للموقع الإلكتروني حيث أن TTFB لأسفل، الشاشة الأولى أكثر استقراراً。

الطبقة 2: الإحماء/الزاحف (تحدد “الزيارة الأولى البطيئة لصفحة باردة”)

يأتي “عدم اتساق التجربة” الشائع في الوصول إلى الموقع الإلكتروني من “الاختلافات الساخنة/الباردة” في التخزين المؤقت:

• تتم زيارة الصفحات الشائعة دائمًا وتكون ذاكرة التخزين المؤقت ساخنة دائمًا
• لم يتم النقر على الصفحات الباردة منذ وقت طويل، والنقر لأول مرة بطيء

إن الإحماء ليس مجرد تزيين الكعكة، بل هو المفتاح لتجربة متناسقة لزوار الموقع الإلكتروني

الطبقة 3: برامج الأمان للمحتوى الديناميكي (التجارة الإلكترونية/العضوية/التعددية اللغوية)

تكمن قوة LSCWP في أنه يمنحك الكثير من “الأدوات المتقدمة”، على سبيل المثال:

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

المستوى 4: الخدمات عبر الإنترنت والتحسينات الاختيارية

سيجد العديد من مشرفي المواقع الإلكترونية أن خدمات QUIC.cloud عبر الإنترنت (مثل خدمات من نوع التحسين على الصفحة) مفيدة في برنامج تحسين المواقع الإلكترونية.وثائق QUIC.cloudكما أنه مكتوب بشكل صريح أنه يوفر خدمات التحسين على الصفحة لـ LSCWP، بما في ذلك CSS الحرجة (CCSS) وCSS الفريدة (UCSS) وViewport Images (VPI) وغيرها.

• هذا النوع من الخدمة اختياري:: يمكنك فقط استخدام التخزين المؤقت للخادم وعدم تمكين التحسين عبر الإنترنت
• بمجرد تمكين الخدمات عبر الإنترنت، ستتغير موارد موقعك/روابط معالجة الصفحات (هذه معلومات مهمة للشركات/المتعاملين الحريصين على الخصوصية)

2.4 الحفرة المشتركة لـ LSCWP

1. الخادم ليس LiteSpeed، ولكنه يستخدم LSCWP كمكوِّن إضافي كامل الميزات للتخزين المؤقت
   النتيجة: التخزين المؤقت ليس فعالاً كما هو متوقع ويزيد أيضاً من تعقيد التكوين. الحل: قم بتأكيد مكدس المضيف أولاً؛ إذا لم يكن لايت سبيدعلى سبيل المثال، ضع في اعتبارك WP Rocket أو WP Super Cache.
2. يؤدي تمكين الكثير من التحسينات في الواجهة الأمامية إلى حدوث اختلالات وظيفية
   غالبًا ما تتسبب التحسينات على الصفحة (CSS/JS) في حدوث مشكلات في التوافق أكثر من “التخزين المؤقت نفسه”. اقتراح: قم بتشغيل ذاكرة التخزين المؤقت للصفحة أولاً، ثم قم بتشغيل التحسينات واحدة تلو الأخرى، وقم بإنشاء قائمة باختبارات الانحدار (النماذج، والقوائم، والمدفوعات، والتتبع، وتبديل اللغة، وما إلى ذلك).
3. عدم وجود استراتيجيات استبعاد/تشريح للصفحات الديناميكية
   الحوادث النموذجية: عربة التسوق، أو الخروج، أو صفحة الحساب التي يتم تخزينها مؤقتًا؛ أو التبديل غير الصحيح بين عدة لغات/عملات متعددة. يجب أن تأخذ مواقع التجارة الإلكترونية هذا الأمر بعين الاعتبار كتحقق قبل الإطلاق (ويؤكد مسؤولو WooCommerce أيضًا)لا تقم بتخزين الصفحات الرئيسية مؤقتاً）。

المكوّن الإضافي 3:ذاكرة التخزين المؤقت الفائقة لـ WP Super Cache(مجانًا) - حل كلاسيكي “منخفض المخاطر، عالي المردود” لمواقع المحتوى.

ذاكرة التخزين المؤقت الفائقة لـ WP Super Cache لماذا كان شائعاً لفترة طويلة؟ لأنه يحل المشاكل بطريقة مباشرة جداً و“صديقة للخادم”:
إنشاء ملفات HTML ثابتة من صفحات ووردبريس الديناميكيةثم يتم عرض ملفات HTML مباشرةً من خادم الويب، متجاوزةً بذلك معالجة PHP المكلفة.

تشير صفحة الإضافة أيضًا إلى أنه سيتم عرض HTML ثابت للغالبية العظمى من المستخدمين غير المسجلين في الموقع، وتعطي عبارة بديهية جدًا - “سيتم عرض ملفات HTML ثابتة لزوار 99%”، ويمكن عرض ملف واحد مخبأ مؤقتًا آلاف المرات. مرات.

3.1 لمن هو WP Super Cache؟

موصى به للغاية:

• المدونات، ومواقع المحتوى الإعلامي، ومواقع المستندات، ومواقع عرض الشركات، وصفحات الاستقبال
• الزوار هم في الأساس مستخدمون غير مسجّلين في الموقع
• تريد: تكاليف صيانة مجانية وثابتة ومنخفضة التكاليف

توخّ الحذر/احرص على استراتيجيات أقوى:

• موقع ديناميكي بقوة: الكثير من المحتوى المخصص، والصفحات التي تتغير وفقًا لحالة المستخدم
• التجارة الإلكترونية الكبيرة: يمكن أن تنجح، ولكن تأكد من عدم تخزين الصفحات الرئيسية مؤقتًا والعمل مع عملية الاختبار الخاصة بك

3.2 طرق التخزين المؤقت الثلاثة:

يسرد وصف إضافة WP Super Cache الإضافية 3 طرق للتخزين المؤقت حسب السرعة ويشرح الاختلافات:

• تعديل_إعادة الكتابة (خبير):: الأسرع، متجاوزًا تمامًا PHP، ولكن تحتاج إلى تغيير .htaccess، قد يؤدي التكوين غير الصحيح إلى عدم توفر الموقع خطر أعلى!
• بسيط (النهج الموصى به):: الملفات الثابتة “فائقة التخزين المؤقت” التي يوفرها PHP، وهي قريبة من سرعة mod_rewrite، ولكن أسهل في التهيئة.
• ذاكرة التخزين المؤقت لـ WP-Cache Cache:: أكثر مرونة بالنسبة للمستخدمين المعروفين وعناوين URL ذات المعلمات وموجزات الاشتراك وما إلى ذلك، ولكن أبطأ

الخيار الموصى به:

• المبتدئين/الباحثين عن الاستقرار: استخدم الطريقة الموصى بها (بسيطة)
• أنت على دراية بقواعد الخادم وترغب في المخاطرة بإعادة كتابتها: فكر في نموذج الخبير مرة أخرى!
• تحتاج إلى تعامل أكثر مرونة مع “المستخدم المعروف/مع المعلمات”: فهم وضع ذاكرة التخزين المؤقت لـ WP-Cache

3.3 مزايا وعيوب ذاكرة التخزين المؤقت الفائقة لـ WP Super Cache

الميزة:

1. مثالي للاستخدام مع CDN.
   نظرًا لأنه في الأساس “توليد HTML ثابت”، فإن هذا يتناسب بشكل طبيعي مع فكرة CDN/ذاكرة التخزين المؤقت للحافة.
2. التحسينات في المحطة المصدرية CPU/ضغط قاعدة البيانات مباشرة للغاية
   كما قد تأتي محركات البحث وبرامج الزحف على مواقع التواصل الاجتماعي من جميع أنحاء العالم عندما تكون حركة المرور على الموقع الإلكتروني متفرقة. يعتبر التثبيت فعالاً في مكافحة “إعادة العرض”.

لوحة قصيرة:

1. إنها ليست “مجموعة تحسين الأداء الشاملة”.”
   إنه قوي بشكل أساسي على التخزين المؤقت للصفحة، والتحسينات العميقة لـ CSS/JS ليست مجمعة كما هو الحال في WP Rocket. قد تحتاج إلى القيام بالمزيد في “صفحة تحسين الصور” و“صفحة تحسين الواجهة الأمامية” (أو استخدام تحسينات أخرى على مستوى الإضافة/القالب).
2. كن أكثر حذراً بشأن “التخصيص الديناميكي”
   على سبيل المثال، عرض محتوى مختلف حسب المنطقة، أو عرض أسعار/لغات/ توصيات مختلفة حسب حالة المستخدم، إلخ. في هذه المرحلة، يجب عليك إما إنشاء سياسة استبعاد أو تقديم مخطط تخزين مؤقت أكثر ملاءمة للتخزين المؤقت.

3.4 توافق WooCommerce: لماذا هو “أكثر أمانًا”

مساعدة WooCommerce الرسميةمذكور: يتوافق WooCommerce أصلاً مع WP Super Cache ويرسل WooCommerce رسالة إلى WP Super Cache بحيث لا يقوم بتخزين صفحات عربة التسوق والدفع وحسابي مؤقتًا بشكل افتراضي.

• حتى إذا كنت جديدًا على WP Super Cache + WooCommerce، فمن غير المرجح أن تخطو على منجم “الصفحات الرئيسية المخزنة مؤقتًا”!
• ومع ذلك، لا يزال من المستحسن إجراء اختبار الانحدار قبل بدء البث المباشر (المدفوعات، والقسائم، والشحن، وأسعار الضرائب، والعملات المتعددة، وما إلى ذلك).

المكوّن الإضافي 4:W3 Total Cache (W3TC)-- “إطار عمل الأداء” الأكثر تنوعًا للفرق الهندسية.

W3 إجمالي ذاكرة التخزين المؤقت W3 بدلاً من “مكون إضافي واحد لذاكرة التخزين المؤقت”، يتم وضع WordPress.org كشيء أشبه بـ “إطار عمل لتحسين أداء الموقع الإلكتروني”: فهو يركز على تحسين تحسين محركات البحث، و"حيوية الويب الأساسية" والتجربة الشاملة من خلال تكامل CDN وأفضل الممارسات. المؤشرات الحيوية والتجربة الشاملة من خلال تكامل CDN وأفضل الممارسات.

يسرد وصف الإضافة مجموعة واسعة من الإمكانيات: التخزين المؤقت للصفحات/المشاركات والتخزين المؤقت لـ CSS/JS والتخزين المؤقت للموجز والتخزين المؤقت لنتائج البحث والتخزين المؤقت لكائنات قاعدة البيانات والتخزين المؤقت للكائنات والتخزين المؤقت للأجزاء (ذاكرة التخزين المؤقت للأجزاء) ودعم مجموعة متنوعة من طرق التخزين المؤقت مثل Redis/Memcached/APC، كما يتضمن أيضًا التخزين المؤقت لتجميع الأجهزة المحمولة حسب UA/المُعرِّف, دعم AMP، وتكامل الوكيل العكسي (Nginx/Varnish) وما إلى ذلك.

4.1 لمن هو W3 Total Cache؟

مثالي لـ

• لديك مهارات التطوير/التشغيل ولديك استعداد للقيام بـ “التمكين + اختبار الضغط + اختبار الانحدار”.”
• موقعك الإلكتروني معقد: متعدد اللغات، والتبديل بين عدة مواضيع، والتبديل بين المواضيع، والتمايز بين الأجهزة المحمولة، وهيكل المحتوى المعقد
• أنت لا تريد فقط التخزين المؤقت للصفحات، بل تريد دمج التخزين المؤقت للكائنات/التخزين المؤقت للأجزاء في النظام (خاصةً للمواقع الديناميكية)

لا يناسبها:

• تريد “التثبيت والانطلاق”، ولا تريد فهم التسلسلات الهرمية لذاكرة التخزين المؤقت.
• ليس لديك عملية اختبار، ولكنك تريد تشغيل العناصر عالية الخطورة مثل الضغط والبرامج النصية المتأخرة بضربة واحدة

4.2 لماذا هي “قوية ولكن معقدة”: المواقع الإلكترونية تقدر “إمكانية التحكم”.”

لا تكمن قيمة W3TC في أنه “يجب أن يكون أسرع من أي شخص آخر”، ولكن في أنه يمنحك مقابض تحكم كافية لهندسة استراتيجية الأداء:

• ذاكرة التخزين المؤقت للصفحات: يمكن أن تكون في الذاكرة أو على القرص أو CDN
• ذاكرة التخزين المؤقت لكائن قاعدة البيانات، وذاكرة التخزين المؤقت للكائنات: متوفرة Redis/Memcached، إلخ.
• التخزين المؤقت للأجزاء: جيد “للصفحات شبه الديناميكية”
• دعم الهاتف المحمول: التخزين المؤقت للصفحات حسب المحيل أو مجموعة وكيل المستخدم على التوالي
• إدارة CDN: إدارة شفافة CDN لمكتبات الوسائط وملفات القوالب وغيرها.

هذه الإمكانيات ذات قيمة خاصة للمواقع الإلكترونية، حيث يتم الوصول العالمي بشكل متكرر:

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

4.3 “طلب التمكين الموصى به من W3TC”

الطلب الموصى به:

1. ابدأ بتمكين التخزين المؤقت للصفحة فقط
   التحقق: تحقق من: TTFB معطل، والمحتوى متناسق، وعمليات تسجيل الدخول إلى الحالة/متعددة اللغات/التجارة الإلكترونية الرئيسية تعمل.
2. إعادة تمكين ذاكرة التخزين المؤقت للمستعرض
   الهدف: جعل زيارات العودة والموارد الثابتة يتم تحميلها بشكل أسرع وتقليل التنزيلات المتكررة عبر القارات.
3. إعادة تقييم ذاكرة التخزين المؤقت للكائنات/ذاكرة التخزين المؤقت لكائنات قاعدة البيانات
   قابل للتطبيق: موقع ديناميكي (WooCommerce، نظام العضوية، الاستعلامات المعقدة).
   غير متاح: قد يكون لمحطات المحتوى فقط عوائد محدودة أو حتى تزيد من استهلاك الموارد.
4. البرامج النصية للضغط / زمن الاستجابة / تحسين الواجهة الأمامية
   نظرًا لأن هذه هي الطبقة التي من المرجح أن تؤدي إلى حدوث حالات شاذة وظيفية، يجب إنشاء قائمة اختبار الانحدار (المدفوعات، والنماذج، والتتبع، والنوافذ المنبثقة، والقوائم، وتبديل اللغة، وما إلى ذلك).

تذكير WooCommerce لـ “تكوين ملحق ذاكرة التخزين المؤقت”:: لا يتم تخزين الصفحات الحرجة مؤقتًا ويوصى بتجنب ضغط ملفات JS.

مصفوفة المقارنة بين المكونات الإضافية الأربعة

ملاحظة: الأمر لا يتعلق بـ “من الأفضل”، بل بـ “من الأفضل في السيناريو الخاص بك”.

البُعد (رياضيات)	صاروخ WP	ذاكرة التخزين المؤقت لايت سبيد	ذاكرة التخزين المؤقت الفائقة لـ WP Super Cache	W3 إجمالي ذاكرة التخزين المؤقت W3
التموضع الأساسي	تكامل موفر للعقل (التخزين المؤقت + التحسين)	التخزين المؤقت على مستوى الخادم (يعتمد على LSCache)	التخزين المؤقت لـ HTML الثابت	إطار الأداء (طبقات ذاكرة تخزين مؤقت متعددة + CDN)
تعتمد على المضيف	منخفض (عالمي)	عالية (تتطلب LiteSpeed/OpenLiteSpeed لتعمل كذاكرة تخزين مؤقت أساسية)	منخفض (عالمي)	متوسطة (عالمية، ولكنها تعتمد بشكل أكبر على البيئة/قابلية التهيئة)
تكاليف التعلم	منخفضة-متوسطة	متوسط	أسفل (رأس المرء)	مرتفع
توصية محطة المحتوى	مرتفع جدًا	عالية جدًا (بشرط استيفائها)	مرتفع جدًا	متوسط-عالي (حسب الفريق)
موقع التجارة الإلكترونية/العضوية	متاح ولكن مع استبعاده بحذر (لا يتم تخزين صفحات WooCommerce الرئيسية مؤقتًا)	متاح ولكن هناك حاجة أكبر للقواعد/استراتيجيات التقطيع	متاح، ويذكر WooCommerce التوافق الأصلي وعدم التخزين المؤقت للصفحات الرئيسية افتراضيًا	متاح ومناسب للتحكم الهندسي
الميزانية	تغطية التكاليف	برنامج مجاني	برنامج مجاني	إصدار مجاني + مدفوع

“حوادث التخزين المؤقت” وقائمة التحقق من الوقاية منها

1 - ثلاثة أسباب جذرية “للمحتوى الخاطئ” بسبب التخزين المؤقت

أ. التعامل مع الصفحات “ذات الحالة” على أنها “صفحات ثابتة بلا حالة”

نموذجي: يتم تخزين صفحة الحساب، وعربة التسوق، وصفحة الدفع مؤقتًا. أكد المسؤولون مرارًا وتكرارًا على يجب عدم تخزين عربة التسوق/الدفع/الحساب مؤقتاً.

ب. لا يتم تخزين المتغيرات متعددة اللغات/متعددة العملات/المناطق بشكل صحيح

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

ج. تحسين الواجهة الأمامية (JS / CSS) إعادة كتابة الواجهة الأمامية مما يؤدي إلى اختلالات وظيفية

على وجه الخصوص، ضغط JS، والدمج، والتنفيذ المتأخر.تجنب ضغط ملفات JS。

2- القائمة المرجعية لاختبار الانحدار قبل الإطلاق

• تسجيل الدخول/الخروج أمر طبيعي
• عمليات إرسال النماذج (نموذج الاتصال، والاشتراك، وتسجيل تسجيل الدخول) تعمل بشكل صحيح
• عملية التجارة الإلكترونية: إضافة شراء ← قسيمة ← الشحن/الضرائب ← الدفع ← صفحة الطلب
• ثبات التبديل متعدد اللغات (المحتوى، وعناوين URL، واللغة الإنجليزية، والعملة بعد التبديل)
• تعمل قوائم الهاتف المحمول والنوافذ المنبثقة والتمرير والتحميل البطيء بشكل صحيح
• تتبع ما إذا كانت النصوص البرمجية لا تزال قيد التشغيل (GA، Meta Pixel، أحداث التحويل)

المشاكل الشائعة

س 1 ： لماذا لا يزال الوصول إلى الخارج بطيئًا على الرغم من أنني قمت بتثبيت المكون الإضافي للتخزين المؤقت؟

السبب الأكثر شيوعًا لذلك هو أنك لم تحل سوى “تكرار العرض في المصدر”، ولكن ليس “زمن انتقال الشبكة عبر القارات”.
تسمح إضافات التخزين المؤقت للخادم بإخراج المحتوى بشكل أسرع (TTFB لأسفل)، ولكن لا تزال هناك حاجة إلى الموارد الثابتة (الصور، CSS، JS، JS، الخطوط)، و RTT للروابط العالمية CDN لتقصير المسافة.
👉 إذن المسار الصحيح هو:اجعل ذاكرة التخزين المؤقت للمحطة المصدر مستقرة أولاً.ثم CDN للتوزيع العالمي.。

س2: لماذا لا يتم تحديث المحتوى بعد أن أقوم بتغييره بعد التخزين المؤقت؟

لأنك ترى “ذاكرة التخزين المؤقت القديمة”. فكرة الحل:

• إنشاء استراتيجية للتنظيف: تنظيف ذاكرة التخزين المؤقت المقابلة بعد تحديث المقالات/الصفحات (بدلاً من التنظيف على مستوى الموقع)
• بالنسبة للسيناريوهات التي تنطوي على عمليات الإحماء/الزحف: قم بالتنظيف ثم الإحماء، وإلا ستكون الزيارة الأولى بطيئة
• بالنسبة إلى CDN: يجب الأخذ في الاعتبار أن حواف CDN قد تخزن الموارد القديمة أيضًا مؤقتًا

س3: هل يمكنني تثبيت WP Rocket + WP Super Cache في نفس الوقت؟

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

س4: أليس من الخطورة استخدام التخزين المؤقت لمواقع التجارة الإلكترونية؟

الأمر ليس خطيراً، بل “عدم وجود قواعد” هو الخطير.توصيات WooCommerceإنه واضح جدًا: لا يتم تخزين العربة/المسحوبات/الحسابات مؤقتًا ويتم تجنب ضغط JS.
بالإضافة إلى ذلك، تذكر WooCommerce أيضًا أنها متوافقة مع توافق WP Super Cache الأصليوتجنب التخزين المؤقت للصفحات المهمة افتراضيًا.
لذلك يمكن تخزين موقع التجارة الإلكترونية مؤقتًا، ولكن يجب اختباره كـ “تغيير مباشر”.

س5: هل يجب أن أختار LiteSpeed Cache أو WP Rocket؟

• هل أنت متأكد من أن المضيف هو LiteSpeed/OpenLiteSpeed؟:: ذاكرة التخزين المؤقت ذات الأولوية LiteSpeed Cache (مجانية وقوية، مع مزايا أساسية من ذاكرة التخزين المؤقت على مستوى الخادم)
• أنت لست متأكدًا من حزمة الاستضافة / لا تريد تقديم تنازلات / تريد الدمج والحفظ.:: صاروخ WP Rocket أكثر استقرارًا
• أنت موقع محتوى وميزانيتك حساسة للميزانية:: WP Super Cache أكثر استقرارًا وأخف وزنًا.

المكونات الإضافية لذاكرة التخزين المؤقت مع CDN

يحل المكوِّن الإضافي للتخزين المؤقت مشكلة “قلة عدد المحطات المصدرية وانخفاض TTFB”؛ ويحل CDN مشكلة “الموارد الثابتة والصفحات الأقرب للمستخدمين العالميين”. تراكب الاثنين هو الحل الأمثل المشترك للوصول العالمي.

• مزيج شائع من محطات المحتوى:ذاكرة التخزين المؤقت للصفحات + التوزيع الثابت CDN
• مجموعات شائعة من المحطات الديناميكية:ذاكرة التخزين المؤقت للصفحات (التحكم في الاستبعاد المحكم) + ذاكرة التخزين المؤقت للكائنات (عند الطلب) + التوزيع الثابت CDN

👉 اقرأ:تسريع CDN (العقدة العالمية وسياسة التخزين المؤقت)

المجموعات الموصى بها للتخزين المؤقت للموقع الإلكتروني

1 - موقع المحتوى / المدونة / موقع الوثيقة

الهدف: تقليل TTFB، وجعل الشاشة الأولى أكثر استقرارًا، وتقليل ضغط الخادم، والعمل مع CDN للتوزيع العالمي.

1.1 مزيج الأعمال الأكثر خلوًا من المتاعب

• WP Rocket (التخزين المؤقت للصفحة + التحميل المسبق + تحسين الواجهة الأمامية)
  • CDN (انتقل إلى صفحة CDN الحديث)

قابل للتطبيق:

• أنت تريد “إعدادًا منخفضًا، ونتائج سريعة، ومخاطر منخفضة.”
• وفرة من القوالب/المكونات الإضافية، تريد تقليل إلقاء التوافق

نقاط الاهتمام:

• يتم تمكين تحسينات الواجهة الأمامية (خاصةً زمن استجابة JS) على مراحل لتجنب حدوث خلل وظيفي (القوائم، والنماذج، والتتبع، وما إلى ذلك)
• يجب أن يكون لدى مواقع المراجعة/النشر المتكرر استراتيجية “التنظيف + الإحماء”، وإلا فإن الزيارة الأولى للصفحات الباردة ستكون بطيئة.

1.2 تركيبات كلاسيكية مجانية ومستقرة

• ذاكرة التخزين المؤقت الفائقة ل WP Super Cache (ذاكرة تخزين HTML ثابتة):: توليد HTML ثابت من الصفحات الديناميكية، خاصة للمستخدمين غير المسجلين.
  • CDN

قابل للتطبيق:

• حساسة للميزانية ولكنها مستقرة
• لا يقوم الزوار أساساً بتسجيل الدخول
• التحكم في وتيرة تحديثات المحتوى

نقاط الاهتمام:

• هذا مزيج من “التخزين المؤقت للصفحة أولًا”، لا تتوقع أن يحل جميع تعقيدات CSS/JS على طول الطريق!

---

2 - موقع الشركة/موقع العلامة التجارية/صفحة الاستقبال

الهدف: كن سريعًا، ولكن الأهم من ذلك “لا تقطع رابط التحويل بسبب التحسين”.

2.1 قوي ويمكن التحكم فيه (محطات التنسيب/التحويل العالمية الموصى بها)

• صاروخ WP
• + (اختياري) تحسين خفيف الوزن للصور (لديك صفحة “تحسين الصورة”)
  • CDN

لماذا هو جيد لمحطات التحويل:

• مواقع التحويل تخشى من “النماذج/النوافذ المنبثقة/النصوص البرمجية للتتبع التي أفسدها التحسين”
• يعد WP Rocket أكثر “تكاملاً” بمعنى أنه يمكنك تمكين كل عنصر في النظام واختباره بشكل متراجع.

“مبدأ ”على الإنترنت" للموقع الإلكتروني للمؤسسة:

• يعد تحسين الأداء “تغييرًا في الأداء” ويجب أن يكون له قائمة مراجعة لاختبار الانحدار
• يجب التحقق من أي إعدادات تتضمن وقت استجابة JS/دمج/ضغط JS في بيئة ما قبل الإصدار قبل بدء البث المباشر!

---

3 - موقع WooCommerce للتجارة الإلكترونية (الطلبات + أمان الصفحة الديناميكية)

الهدف: من المهم أن تكون سريعًا، ولكن من المهم أيضًا التأكد من أن صفحات عربة التسوق والدفع والحساب صحيحة تمامًا.

نقاط WooCommerce الرسمية لإضافة التخزين المؤقت واضحة للغاية:عربة التسوق / الخروج / صفحة الحساب لا تخزن مؤقتًايوصى أيضًا بتجنب ضغط ملفات JavaScript لتقليل مشاكل التوافق.

3.1 الطرق المجانية والآمنة الأكثر “ملائمة للمبتدئين”

• WP Super Cache + WooCommerce
  • CDN

لماذا تم إدراجها على أنها “مكان أكثر أماناً للبدء”:

• يذكر WooCommerce رسميًا أنه متوافق أصلاً مع WP Super Cache، وسيُعلم WP Super Cache أنه لا يقوم بالتخزين المؤقت للصفحات الرئيسية مثل عربة التسوق/التسجيل/الحساب بشكل افتراضي.
• بالنسبة للمواقع التي تبدأ في التجارة الإلكترونية، فإن “عدم وقوع حوادث أولاً” أهم من “الأداء الفائق”.

3.2 إذا كنت تستخدم مضيف LiteSpeed (مجاني ولكن قوي)

• ذاكرة LiteSpeed للتخزين المؤقت (يجب أن يكون المضيف LiteSpeed/مضيف LiteSpeed مفتوح للاستفادة من التخزين المؤقت للخادم الأساسي)
• + (اختياري) التخزين المؤقت للكائنات (Redis/Memcached، حسب سعة الاستضافة وحجم الموقع)
  • CDN

قابل للتطبيق:

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

3.3 الفرق الهندسية/التجارة الإلكترونية المعقدة (متعددة الوحدات التي يمكن التحكم فيها)

• W3 إجمالي ذاكرة التخزين المؤقت W3 Total Cache (إطار عمل الأداء، طبقة ذاكرة تخزين مؤقت متعددة مدمجة مع CDN)
  • التخزين المؤقت للكائنات (عند الطلب)
  • CDN

قابل للتطبيق:

• باستخدام Dev/Ops، يمكنك بدء العمل بـ “تمكين الوحدة خطوة بخطوة + اختبار الضغط + اختبار الانحدار”.
• الحاجة إلى التخزين المؤقت للأجزاء/المتغيرات الأكثر تعقيدًا للاستراتيجية (مثل التخزين المؤقت الدقيق حسب الجهاز/المنطقة/اللغة)

---

4 - موقع العضوية/المجتمع/الدورات التدريبية عبر الإنترنت (العديد من عمليات تسجيل الدخول، والتخصيص القوي)

الهدف: اجعل المحتوى العام سريعًا مع ضمان عدم تعليق “محتوى المستخدم الذي قام بتسجيل الدخول”.

4.1 الحفظ ولكن تحتاج إلى استراتيجيات استبعاد صارمة

• صاروخ WP
• + (اختياري) التخزين المؤقت للكائنات (إذا كانت الاستعلامات الديناميكية عديدة)
  • CDN

النقاط الرئيسية:

• يجب أن تستبعد من التخزين المؤقت صفحات “التغيير حسب المستخدم”: المركز الشخصي، والطلبات، والتقدم، والرسائل، وعربة التسوق، وما إلى ذلك.
• هذا النوع من المواقع هو الأكثر عرضة لـ “رؤية محتوى الآخرين/الأذونات الخاطئة”، ويجب توضيح المخاطر في الصفحة.

4.2 استضافة LiteSpeed + السياسة المتقدمة

• ذاكرة التخزين المؤقت LiteSpeed (التخزين المؤقت للخادم + أدوات سياسة أكثر تطوراً)
• + التخزين المؤقت للكائنات (عند الطلب)
  • CDN

النقاط الرئيسية:

• تميل مواقع العضوية إلى عقلية “جسم قابل للتخزين المؤقت + جزء غير قابل للتخزين المؤقت”.
• يجب أن تكون استراتيجيات الإحماء والتنظيف أكثر دقة، وإلا فإن “استمرار رؤية المستخدمين للمحتوى القديم بعد التحديث” سيكون متكررًا جدًا

ذاكرة التخزين المؤقت للويب “دفتر حالات إزالة الألغام”

الحالة 1: تثبيت المكون الإضافي للتخزين المؤقت، السرعة لم تتغير تقريبًا

الظاهرة

• السرعات المحلية/الإقليمية جيدة، أما في الخارج (عبر القارات) فلا تزال بطيئة
• لقد تحسنت TTFB، ولكن لم تنخفض أوقات التحميل الإجمالية بشكل كبير

الأسباب الشائعة:

• أنت تقوم فقط بالتخزين المؤقت للمصدر (TTFB)، ولكن لا يزال يتم تحميل الموارد الثابتة (الصور/JS/CSS/الخطوط) من المصدر عبر القارات
• البرامج النصية للجهات الخارجية (الإعلانات والدردشة والإحصائيات) تبطئ العرض والتفاعل
• بطء التنزيل بسبب أحجام الصور الكبيرة (لا يحل التخزين المؤقت مشكلة حجم “التنزيل الأول”)

فكرة الحل:

• يتكفل المكون الإضافي لذاكرة التخزين المؤقت بـ “نقصان عدد الزيارات + المصدر” أولاً.”
• تتحرك الموارد الثابتة CDN
• تحسين الصورة بعيدًا عن الصورة
• البرامج النصية للجهات الخارجية تقوم باستراتيجيات التأخير/التقسيم

القراءة:

• تسريع CDN: العقد العالمية واستراتيجيات التخزين المؤقت
• تحسين الصورة: التنسيق/الضغط/التحميل البطيء

---

الحالة 2: بعد تمكين التخزين المؤقت، يتم تغيير الصفحة ولكن لا يتم تحديث الواجهة الأمامية.

الظاهرة

• تم تحديث المحتوى/الأسلوب في الواجهة الخلفية ولا تزال النسخة القديمة معروضة في الواجهة الأمامية
• أو يتم تحديث بعض المناطق فقط وتبقى مناطق أخرى كما هي (شائع في المحطات العالمية)

الأسباب الشائعة:

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

فكرة الحل:

• إنشاء “استراتيجية للتنظيف بعد الإصدار/التجديد”: تنظيف الصفحات ذات الصلة، وليس التنظيف الشامل للموقع
• إنشاء استراتيجية إحماء للصفحات المهمة (الصفحة الرئيسية، والصفحات المقصودة الأساسية) لتجنب “التنظيف = الإبطاء”
• CDN طبقة CDN للقيام بتنظيف الحواف عند الحاجة

---

الحالة 3: محتوى في غير محله بعد التبديل بين عدة لغات/عملات متعددة

الظاهرة

• لا تزال الصفحة تعرض اللغة السابقة بعد تبديل اللغات
• أو يرى المستخدمون في مناطق معينة عملة خاطئة/محتوى خاطئاً/محتوى خاطئاً

الأسباب الشائعة:

• لا تميز ذاكرة التخزين المؤقت بين “الأبعاد المتغيرة” (cookie / المعلمات / بادئات اللغة / النطاقات الفرعية).
• يعطي ضرب ذاكرة التخزين المؤقت نتائج صفحة اللغة (أ) لمستخدم اللغة (ب)

فكرة الحل:

• توضيح برنامجك متعدد اللغات: الدلائل/المجالات الفرعية/المعلمات/cookie
• إضافة “السياسات المتغيرة” إلى قواعد التخزين المؤقت أو استبعاد الصفحات الرئيسية
• تتطلب بعض المواقع أفكارًا أكثر تقدمًا للتخزين المؤقت “للتقطيع والتقطيع” (W3TC هو الأنسب للتحكم الهندسي).

---

الحالة 4: مشاكل في عربة التسوق/الدفع على موقع التجارة الإلكترونية مع تمكين التخزين المؤقت

الظاهرة

• عربة التسوق بكمية خاطئة، وسعر خاطئ، وزر الخروج لا يعمل
• تسجيل الدخول ورؤية محتوى لا يخصك (بجدية)

الأسباب الشائعة:

• يتم تخزين الصفحات المهمة مثل عربة التسوق/سحب النقود/حسابي مؤقتاً.
• يتسبب تصغير/دمج JS في عدم توافق الدفع/المكون الديناميكي

فكرة الحل:

• WooCommerce رسمي: لا ينبغي تخزين عربة/سحب/الحسابات مؤقتًا، ويوصى بتجنب ضغط ملفات JS.
• قم بتشغيل “ذاكرة التخزين المؤقت للصفحة + الاستبعاد” أولاً، ثم فكر في تحسين الواجهة الأمامية
• إذا كنت تستخدم WP Super Cache، يذكر WooCommerce أنه متوافق أصلاً ويتجنب التخزين المؤقت للصفحات الرئيسية بشكل افتراضي.

---

الحالة 5: القائمة/النموذج/المنبثقة معطلة بعد تمكين “تأخير JS/Merge Scripts”.

الظاهرة

• قائمة التنقل لا تفتح
• فشل التحقق من صحة النموذج أو تعذر إرساله
• الاستثناء المنبثق/الاستثناء المنبثق
• لا يتم تشغيل الإحصائيات/أحداث التحويل (أكبر مشكلة في مواقع الإطلاق)

الأسباب الشائعة:

• تغيّر JS المؤجلة توقيت تنفيذ البرامج النصية: لا يتم تنفيذ البرامج النصية حتى يتفاعل المستخدم معها، وتعتمد بعض المكونات على “التهيئة عند تحميل الصفحة”.”
• قد يؤدي الدمج/الضغط إلى تغيير ترتيب النص البرمجي أو كسر التبعيات

يصف WP Rocket رسميًا “تنفيذ JS المؤجل” بأنه أحد أقوى تحسينات JS الخاصة به: يتم تأجيل النصوص البرمجية إلى ما بعد تفاعل المستخدم لإعطاء الأولوية لعرض الصفحة. هذه قدرة رائعة، ولكنها تعني أيضًا زيادة مخاطر التوافق.

فكرة الحل:

• التمكين على مراحل: ذاكرة التخزين المؤقت، ثم الصور، ثم CSS، ثم JS.
• إضافة استثناءات إلى البرامج النصية الرئيسية (المدفوعات والنماذج والقوائم والتتبع)
• قم بإجراء قائمة مراجعة اختبار الانحدار لكل تغيير

---

الحالة 6: تم تثبيت ذاكرة التخزين المؤقت LiteSpeed Cache فقط، ولكن لا يبدو أنها تعمل.

الظاهرة

• ذاكرة التخزين المؤقت LiteSpeed قيد التشغيل، ولكن TTFB لا ينخفض كثيرًا.
• الضربات ليست واضحة أيضاً

الأسباب الشائعة:

• الخادم لديك ليس LiteSpeed/OpenLiteSpeed ولا يمكنه استخدام الإمكانيات الأساسية ل LSCache
• أو ربما تكون قد قمت بتمكين مجموعة من التحسينات لها، ولكن لم يتم إنشاء “سياسة التخزين المؤقت للصفحة/التسخين المسبق/الاستبعاد”!

فكرة الحل:

• تحقق من مكدس المضيف أولاً: هل هو LiteSpeed/OpenLiteSpeed (هذا شرط أساسي)
• إعادة التركيز على “استراتيجية التخزين المؤقت للصفحة + الإحماء + استكشاف الأخطاء وإصلاحها + التنظيف”
• إذا لم يكن مضيف LiteSpeed: فكِّر في WP Rocket أو WP Super Cache