ليست كل تحسينات الأداء كبيرة، لكن جمع التحسينات الصغيرة المعقولة يخفف ما تحمله الصفحة بلا فائدة. في قالب GZ تقنية استخدمنا خطوط النظام بدل خطوط خارجية، ثم قسنا طلبات الصفحة الرئيسية قبل وبعد إزالة سكربتات توافق Emoji الخاصة بووردبريس من الواجهة العامة.
ما الذي كان يُحمّل؟
ووردبريس يطبع سكربت فحص Emoji لتوفير توافق إضافي، وقد يحمّل ملفات Emoji مرتبطة به. في اختبارنا كانت هذه الملفات تأتي من نفس الخادم، لا من جهة خارجية، لكنها لم تكن ضرورية للجمهور المستهدف الذي يستخدم متصفحات حديثة.
لا نخلط ذلك بالخطوط: القالب يستخدم Tahoma وArial وخطوط النظام المتاحة، لذلك لم تظهر طلبات إلى Google Fonts أو ملفات WOFF في القياس. هذا قرار تصميمي يفضّل سرعة العرض والخصوصية والبساطة على خط ويب مخصص.
التغيير الذي اختبرناه
أزلنا خطاف Emoji من الواجهة فقط باستخدام إضافة الموقع:
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );لم نلمس محرر لوحة التحكم، ولم نستبدل رموز Emoji داخل المقالات. المتصفحات الحديثة تعرض الرموز أصلًا من نظام التشغيل. إذا كان جمهورك يستخدم متصفحات قديمة جدًا أو تعتمد على مظهر Emoji موحّد في كل نظام، اختبر قبل اعتماد هذا القرار.
لماذا لا نعده حلًا سحريًا؟
الفرق في هذا الاختبار حقيقي لكنه صغير مقارنة بصورة ضخمة غير محسنة أو إضافة ثقيلة أو استجابة خادم بطيئة. لا تعطّل ميزة فقط لأن مقالة على الإنترنت قالت إنها تسرّع الموقع. افحص ما تحمله صفحتك أنت، ثم قارن قبل وبعد على نفس الصفحة والبيئة قدر الإمكان.
كيف تكرر الاختبار؟
- افتح الصفحة في نافذة خاصة وسجل عدد الطلبات والحجم المنقول من تبويب Network.
- ابحث عن
wp-emoji.jsوtwemoji.jsأو أي خطوط خارجية. - طبّق التغيير في بيئة اختبار لا في الموقع الحي مباشرة.
- امسح cache واختبر الصفحة على هاتف ومتصفح مكتبي.
- افتح مقالًا يحتوي Emoji للتأكد أن القراءة لا تتضرر.
- احتفظ بالنتيجة. إن لم تجد فرقًا مفيدًا أو ظهر أثر جانبي، أعد الخطاف كما كان.
ما الذي بقي في الصفحة بعد التغيير؟
بقيت طلبات ووردبريس والقالب والإضافة اللازمة لتشغيل الصفحة. هدفنا ليس جعل عدد الطلبات صفرًا، بل إزالة ما لا يخدم تجربة القارئ. كذلك لا نضيف خطوطًا خارجية لمجرد الزينة؛ وإذا احتجنا خطًا خاصًا مستقبلًا سنقيس أثره ونفكر في استضافته محليًا.