اتخطّى للمحتوى
تعلّم ماجنتو بالعربي
Englishوظّفنيابدأ الكورس
ابدأ الكورسوظّفنيEnglish

نصايح قديمة لتسريع Magento 2 لازم تبطّلها في 2026

Abdulrahman Masoudآخر تحديث: 5 دقيقة قراءةRead in English

أشهر نصايح تسريع Magento 2 اللي بطّلت تنفع في 2026: دمج ملفات JS و CSS مع HTTP/2، وضبط query_cache_size اللي اتشال من MySQL 8.0، وتنضيف جداول log بتاعة Magento 1، والاعتماد على Elasticsearch أو Redis، وتفعيل الـ Flat Catalog. البديل: HTTP/2 مع minify، و OpenSearch 3، و Valkey، والـ indexers على Update by Schedule.

أشهر نصايح تسريع Magento 2 اللي بطّلت تنفع في 2026 هي: دمج ملفات الـ JavaScript والـ CSS، وضبط query_cache_size، وتنضيف جداول log بتاعة Magento 1، والاعتماد على Elasticsearch و Redis والـ Flat Catalog. كلها كانت منطقية في وقت ما، لكن الإصدارات والبنية التحتية اتغيّرت، والبديل الصح موجود في توثيق Adobe.

المشكلة إن مقالات كتير عن تسريع Magento اتكتبت أيام 2.3 أو أول 2.4، واتحدّث تاريخها من غير ما محتواها يتحدّث. وبعضها بيحط أرقام من غير مصدر، أو بينقل دراسات بشكل غلط. المقال ده بيجمع النصايح اللي لسه منتشرة، وقدّام كل واحدة الحقيقة والبديل.

إيه النصايح اللي بطّلت تنفع؟

النصيحة القديمة الحقيقة في 2026 اعمل إيه بدلها
فعّل Merge JS و Merge CSS Adobe بتعتبر الدمج deprecated ومالوش فايدة مع HTTP/2 HTTP/2 مع minify
ظبّط query_cache_size الـ query cache اتشال من MySQL 8.0 innodb_buffer_pool_size
نضّف جداول log_url و log_visitor دي جداول Magento 1 ومش موجودة في Magento 2 سيب الـ cron بتاع visitor_clean يشتغل
Elasticsearch مطلوب deprecated من 2.4.8 ومش مذكور في 2.4.9 OpenSearch 3
استخدم Redis للكاش والـ sessions آخر patches بتكتب Redis غير مدعوم Valkey 8.1 أو 9 حسب إصدارك
فعّل الـ Flat Catalog مابقاش best practice من 2.3.x جداول الـ index و OpenSearch
PHP 8.1 أو 8.2 كفاية 2.4.9 بيطلب PHP 8.5 الإصدار اللي في جدول متطلبات Adobe
Varnish بيكاش الملفات الثابتة الـ VCL الافتراضي بيعدّي /static و /media من غير كاش CDN للملفات الثابتة
Luma مابيعملش lazy loading الـ core بيضيف loading="lazy" لصور الـ listing متعملش lazy لصورة الـ LCP
فعّل الـ JS bundling المدمج وخلاص Adobe بتعتبره fallback وبيحمّل كل الـ bundles أول زيارة HTTP/2 أو advanced bundling
TTFB و TTI من المقاييس الأساسية TTFB مش Core Web Vital، و TTI اتشال من Lighthouse 10 LCP و INP و CLS
كاش Magento بيتخزّن في متصفح العميل الكاش على السيرفر: var/cache أو Valkey أو Varnish Cache Management و cache:clean

ليه دمج ملفات JavaScript و CSS بقى غلط؟

الدمج كان بيقلّل عدد الطلبات أيام HTTP/1.1، لما كل ملف كان محتاج اتصال. مع HTTP/2 المتصفح بيحمّل ملفات كتير على نفس الاتصال، فالدمج بيطلّع ملف واحد كبير من غير فايدة. عشان كده Adobe بتقول صراحة: ماتدمجش ولا تعمل bundle للملفات لو بتستخدم HTTP/2.

والـ JS bundling المدمج مشكلته أكبر: بيحمّل كل الـ bundles في أول زيارة حتى لو الصفحة مش محتاجاها. Adobe قاست صفحة رئيسية لمتجر جديد على شبكة Slow 3G، وتحميل الـ bundles خد حوالي 44 ثانية. البديل: minify، و HTTP/2، و advanced bundling حسب نوع الصفحة، أو theme خفيف زي Hyvä. وإزاي RequireJS بيحمّل الملفات أصلًا متشرح في درس الـ Frontend.

ليه query_cache_size وجداول log مابتفرقش؟

  • الـ query cache: MySQL 8.0 شاله نهائيًا، و MariaDB بيقفله افتراضيًا لأنه مابيتوسّعش مع الضغط. أي مقال بينصح بـ query_cache_size مكتوب لإصدار قديم.
  • جداول log: أسماء زي log_url و log_visitor و dataflow_batch_export جاية من Magento 1. في Magento 2، الـ cron اسمه visitor_clean بينضّف جدول customer_visitor يوميًا لوحده.
  • الإعداد اللي بيتسمّى أحيانًا "log cleaning": قسم MySQL Message Queue Cleanup بينضّف رسائل الـ queues اللي بتستخدم قاعدة البيانات، وقيمه الافتراضية معقولة. مالوش علاقة بسرعة الصفحات.

الإعداد اللي بيفرق فعلًا في قاعدة البيانات هو إن الجداول والـ indexes تكون في الذاكرة، وإن الـ collections تتكتب صح، وده متشرح في درس قاعدة البيانات والأداء.

ليه Elasticsearch و Redis و Flat Catalog بقوا من الماضي؟

  • Elasticsearch: موديولاته deprecated من Magento 2.4.8، ومش مذكور في متطلبات 2.4.9، و Elasticsearch 7.17 انتهى دعمه 15 يناير 2026. المطلوب OpenSearch 3.
  • Redis: متطلبات Adobe لآخر patches من 2.4.6 و 2.4.7 و 2.4.8 بتكتب إنه غير مدعوم، وبتذكر Valkey 8.1، و 2.4.9 بيطلب Valkey 9. الخطوات في مقال التحويل من Redis لـ Valkey.
  • Flat Catalog: Adobe بتقول إنه مابقاش best practice من 2.3.x، والإعدادين مقفولين افتراضيًا. Magento بيعتمد على جداول الـ index، وإزاي بتشتغل متشرح في درس الـ Indexers.

إيه الغلط الشائع في الـ lazy loading؟

فيه غلطتين عكس بعض. الأولى إن Magento مابيعملش lazy loading، والحقيقة إن template صور الـ listing في الـ core بيضيف loading="lazy" وأبعاد الصورة. والتانية إنك تعمل lazy لكل الصور، وده بيأخّر الصورة الأساسية اللي بتحدد الـ LCP: web.dev لقى إن الصفحات اللي بتعمل كده متوسط الـ LCP فيها 3,546 مللي ثانية مقابل 2,922 من غيره.

القاعدة: الصورة الأساسية اللي فوق تتحمّل على طول، والباقي lazy.

إزاي تقرا أرقام السرعة في المقالات؟

  • اسأل عن المصدر: أرقام زي «كل 100 مللي ثانية بتخسّرك 1% من المبيعات» بتتكرر كتير من غير رابط لدراسة أصلية.
  • ارجع للدراسة نفسها: دراسة Rakuten 24 على web.dev بتقول زيادة 53.37% في الإيراد لكل زائر و 33.13% في معدل التحويل، ومقالات بتبدّل الرقمين. ودراسة Tokopedia بتقول زيادة 23% في متوسط مدة الجلسة، مش في التحويلات.
  • فرّق بين المعمل والواقع: درجة PageSpeed قياس معمل، وتقييم Core Web Vitals بيتعمل من بيانات زوّار حقيقيين على الـ 75th percentile.
  • اعرف المقاييس الحالية: Core Web Vitals هي LCP و INP و CLS. الـ TTFB مؤشر مساعد، و TTI اتشال من Lighthouse 10 سنة 2023.

الترتيب الكامل للخطوات اللي بتفرق فعلًا موجود في Checklist تسريع Magento 2 في 2026.

Checklist: راجع إعدادات متجرك

  • dev/js/merge_files و dev/css/merge_css_files مقفولين لو عندك HTTP/2
  • مفيش query_cache_size في إعدادات قاعدة البيانات
  • محرك البحث OpenSearch 3، مش Elasticsearch
  • الكاش والـ sessions على Valkey بالإصدار المطلوب
  • Use Flat Catalog Category و Use Flat Catalog Product = No
  • PHP مطابق لجدول متطلبات إصدارك
  • مفيش scripts بتنضّف جداول Magento 1
  • صورة الـ LCP مش lazy
  • بتقيس بـ LCP و INP و CLS من بيانات حقيقية

المصادر

المعلومات التقنية في المقال اتراجعت على المصادر دي:

  1. Adobe — Optimize CSS and JavaScript files
  2. Adobe — Advanced JavaScript bundling
  3. MySQL 8.0 — What is new (query cache removed)
  4. Adobe — System requirements
  5. Adobe Commerce 2.4.8 release notes
  6. Adobe — Flat catalog
  7. Magento source — varnish7.vcl (2.4-develop)
  8. Magento source — Customer crontab.xml (2.4-develop)
  9. Magento source — image_with_borders.phtml (2.4-develop)
  10. Adobe — Cache management
  11. web.dev — Lazy loading and LCP
  12. web.dev — Time to First Byte
  13. Chrome for Developers — Lighthouse 10
  14. web.dev — Rakuten 24 case study
  15. web.dev — Business impact of Core Web Vitals

أسئلة شائعة

هل أفعّل Flat Catalog في Magento 2.4؟

لأ. Adobe بتقول إن الـ flat catalog مابقاش best practice من إصدارات 2.3.x وأحدث، والإعدادين Use Flat Catalog Category و Use Flat Catalog Product مقفولين افتراضيًا في الـ core.

هل query_cache_size بيسرّع Magento 2؟

لأ. الـ query cache اتشال من MySQL 8.0، وفي MariaDB مقفول افتراضيًا لأنه مابيتوسّعش كويس. الإعداد اللي بيفرق فعلًا هو innodb_buffer_pool_size عشان الجداول والـ indexes تفضل في الذاكرة.

هل Magento 2.4.9 بيدعم Elasticsearch؟

Elasticsearch مش مذكور في متطلبات 2.4.9، وموديولاته deprecated من 2.4.8، و Elasticsearch 7.17 نفسه انتهى دعمه 15 يناير 2026. استخدم OpenSearch 3.

هل أعمل lazy loading لكل صور متجر Magento؟

لأ. Magento بيعمل lazy لصور صفحات الـ categories لوحده، لكن الصورة الأساسية اللي فوق في الصفحة لازم تتحمّل على طول. web.dev لقى إن الصفحات اللي بتعمل lazy للصور متوسط الـ LCP فيها 3,546 مللي ثانية مقابل 2,922 من غيره.

هل TTFB من Core Web Vitals؟

لأ. Core Web Vitals هي LCP و INP و CLS. الـ TTFB مؤشر مساعد بيأثّر على LCP، و web.dev بيعتبر 0.8 ثانية أو أقل كويس كتقدير عام.

دروس مرتبطة

كاتب المقال

Abdulrahman Masoud

عندك سؤال على المقال أو محتاج مساعدة في أداء متجر Magento؟ كلّمني.

وظّفني