لما تيجي تنشر حاجة تفاعلية على ووردبريس — حاسبة، اختبار قصير، أداة صغيرة، لعبة — الإغراء الأول إنك تركّب منشئ صفحات، وحزمة حركات، وتلات إضافات تحسين. والنتيجة CSS أكتر، و JavaScript أكتر، وأماكن أكتر تتكسر منها صفحة كان المفروض تكون بسيطة.
القاعدة اللي بتخلص المشكلة دي بسيطة: ووردبريس مسؤول عن النشر، والعنصر التفاعلي تطبيق صغير قائم بذاته. الكلام ده مش نظري؛ ده الفرق بين إنك تنشر عنصرًا جديدًا في نص ساعة وبين إنك تقضي يومًا بتصلّح تعارضًا بين إضافتين.
احبس العنصر في حاوية واحدة
كل عنصر تفاعلي بيتلف في حاوية ليها كلاس فريد، وكل أنماط الـ CSS بتبدأ من الكلاس ده مش من عناصر عامة زي body أو button أو h2.
/* مثال: كل شيء يبدأ من القالب كاملًا والنماذج والنوافذ المنبثقة.">Elementor وينظّم ترتيبها واتجاهها ومسافاتها، وتعتمد على Flexbox أو Grid. حلّت محل الأقسام والأعمدة القديمة، وتنتج صفحات أخف وأسهل…">الحاوية */
.acms-tool-quiz .btn { font-size: 18px; }
.acms-tool-quiz h2 { margin-block: 12px; }
ونفس المبدأ في JavaScript: المحدّدات بتبدأ من جوّه الحاوية، والمستمعات بتتربط بعناصر مملوكة للأداة دي بس.
const root = document.querySelector(‘.acms-tool-quiz’);
root.querySelector(‘.btn’).addEventListener(‘click’, onClick);
القرار الصغير ده بيخلي النشر اليومي آمنًا. تقدر تنشر أداة جديدة بواجهة مختلفة تمامًا من غير ما تتخانق مع القالب (Theme) أو تكسر الهيدر والفوتر في صفحة تانية.
حمولة واحدة لكل صفحة
للعناصر الخفيفة، خلي HTML والـ CSS المعزول و JavaScript مع بعض في بلوك HTML مخصص جوّه المقالة نفسها. من غير إطار عمل خارجي، ومن غير طلب إضافي لمكتبة مكوّنات.
بكده المتصفح بيستقبل الكود اللازم للصفحة الحالية بس، مش مكتبة كاملة عشان زرار واحد.
لكن ده مش معناه إن كل حاجة تتحط داخل الصفحة. الكود المشترك بين صفحات كتير مكانه ملف في القالب أو إضافة صغيرة، عشان يتخزّن في المتصفح مرة واحدة ويشتغل في كل الصفحات. الحد الفاصل بسيط: مستخدم في صفحة واحدة؟ جوّه الصفحة. مستخدم في عشرة؟ في ملف مشترك.
أخّر أي شغل مش جزء من التفاعل
المنطقة التفاعلية لازم تبقى جاهزة قبل التأثيرات الجمالية والودجتات الجانبية. يعني:
- من غير مكتبات حركات ضخمة لمجرد ظهور تدريجي ينفع يتعمل بـ CSS.
- من غير تشغيل تلقائي للفيديو أو الصوت قبل أول تفاعل.
- الصور تحت العنصر التفاعلي تتحمّل بالتحميل الكسول (Lazy Loading).
- الصورة البارزة تتضغط وتتحدد أبعادها عشان التخطيط مايقفزش.
وشاشة التحميل مش استراتيجية أداء. لو العنصر خفيف أصلًا، شاشة التحميل بتضيف تأخيرًا محسوسًا بدل ما تشيله؛ الأفضل إن عناصر التحكم تبقى متاحة على طول.
اللمس والكيبورد مع بعض من الأول
الأداة الواحدة ممكن تتستخدم بالماوس، أو باللمس، أو بالكيبورد، أو بلوحة تتبع. التعامل مع ده بعد ما تخلص نسخة الديسكتوب بيطلع دايمًا ترقيعًا.
- استخدم أحداث المؤشر (Pointer Events) بدل ما تكتب مسارين منفصلين للماوس واللمس.
- خلي مساحات اللمس مريحة، ولا تقل عن 44 بكسل في الاتجاهين.
- امنع تحديد النص داخل منطقة التفاعل النشطة بس، مش في الصفحة كلها.
- خلي حالة التركيز (Focus) ظاهرة للكيبورد، وماتخطفش مفاتيح والمستخدم بيكتب في حقل تاني.
والتصميم المتجاوب (Responsive) جزء من منطق الأداة نفسها مش خطوة أخيرة: المؤقتات والنتائج والأزرار محتاجة أبعادًا ثابتة عشان الأرقام وهي بتتغير ماتحركش اللي حواليها.
نقطة تخص المواقع العربية: لو الأداة فيها أرقام بتتغير بسرعة، استخدم font-variant-numeric: tabular-nums مع خط عربي زي Cairo أو Tajawal. من غيرها عرض الرقم بيختلف من قيمة لقيمة والعداد بيرقص أمام الزائر. وجرّب الأداة في وضع RTL تحديدًا، لأن أي margin-left ثابت في الكود بيقلب مكانه.
وزّع المسؤوليات بوضوح
خلي القالب مسؤولًا عن التنقل والألوان والأرشيف والبحث وتخطيط المقالات. وخلي صفحة الأداة فيها الأداة والمحتوى اللي بيشرحها بس.
النتيجة إن إضافة أداة جديدة مابتحتاجش تعديلًا في القالب، وتحسين القالب مابيحتاجش إعادة كتابة كل الأدوات. والفصل ده بيساعد صفحات الأرشيف والبحث كمان: ووردبريس بيعرض أحدث الصفحات تلقائيًا، والكود بيفضل محبوسًا في صفحته.
اختبر الصفحة اللي الزائر بيشوفها فعلًا
الملف المحلي بيفتح فورًا. الصفحة المنشورة بيبطّئها الخط، والإعلانات، وسكربت التحليلات، وإعدادات التخزين المؤقت. الاتنين مش نفس الصفحة.
افتح الرابط المنشور على الديسكتوب والموبايل، وراجع أربع حاجات:
- أول تفاعل بيشتغل من غير إعادة تحميل.
- التخطيط مابيتحركش لما النتائج أو الأرقام تتغير.
- عناصر التحكم شغالة باللمس والكيبورد.
- الصفحة لسه قابلة للاستخدام على اتصال بطيء — جرّب 3G بطيء في أدوات المطور، وده مش سيناريو نادر في المنطقة.
وكرّر الاختبار بعد كل تحديث لووردبريس، لأن فلاتر المحتوى وإعدادات الكاش بتغيّر أحيانًا طريقة تسليم السكربتات المضمّنة.
قائمة فحص قبل النشر
- كل الأنماط معزولة داخل حاوية الأداة؟
- الأداة شغالة من غير مكتبة خارجية؟
- أول تفاعل متاح بسرعة؟
- اللمس والماوس والكيبورد كلهم بيشتغلوا؟
- الصور مضغوطة وأبعادها محددة؟
- الصفحة المنشورة شغالة بعد تفعيل الكاش؟
القائمة دي قصيرة كفاية إنك تستخدمها كل مرة، وده اللي بيخليها مفيدة أكتر من عملية أداء معقدة بتتعمل مرة وتتنسي.
اقرأ أيضًا
الأسئلة الشائعة
س: الكود المخصص في بلوك HTML ولا في القالب؟ ج: الخاص بصفحة واحدة في بلوك HTML جوّه الصفحة. المشترك بين صفحات كتير في ملف بالقالب أو إضافة صغيرة عشان يستفيد من التخزين المؤقت.
س: إزاي أمنع تعارض الأنماط مع القالب؟ ج: كلاس فريد على الحاوية، وكل محدّد CSS يبدأ منه، ومستمعات JavaScript تتربط بعناصر داخل الحاوية بس.
س: ليه الصفحة بتقفز وأنا بستخدمها؟ ج: عناصر بغير أبعاد محددة. حدّد عرضًا أدنى للأرقام والأزرار وأبعادًا للصور، وهتشوف تحسنًا مباشرًا في مقياس CLS.
س: هل أستغنى عن إضافات التحسين خالص؟ ج: لو الصفحة خفيفة أصلًا، أغلب الإضافات دي بتضيف تعقيدًا أكتر من الفايدة. إضافة تخزين مؤقت واحدة على مستوى الموقع كفاية في الغالب.
س: إيه أسرع اختبار أعمله دلوقتي؟ ج: افتح أثقل صفحة تفاعلية عندك على موبايل حقيقي باتصال بيانات، وشوف أول تفاعل بياخد قد إيه. ده بيكشف أكتر من أي تقرير أدوات.
الخلاصة
الدرس هنا مش إن الإضافات وأطر العمل وحشة. الدرس إن كل اعتماد لازم يستاهل مكانه في صفحة وظيفتها الأساسية إن الزائر يستخدمها فورًا.
خد أثقل صفحة تفاعلية عندك النهارده، شيل منها أول مكتبة مش مستخدمة فعليًا، وقيس الفرق. ابن موقعك قطعة قطعة، وخلي كل قطعة تثبت إنها لازمة.
مرجع المقال (بالإنجليزية): How I Kept a WordPress Browser-Game Site Fast Without Heavy Plugins
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.
