في الصفحة دي
أغلب مقالات سرعة ووردبريس كاتبها ناس عمرهم ما راجعوا هل التغيير حرّك بيانات المستخدمين الحقيقيين. بيحسّنوا الرقم، وينشروا، ويصوّروا الدايرة الخضرا، وعمرهم ما بيرجعوا يبصوا على Chrome UX Report تاني. التغييرات اللي بترفع رقم Lighthouse والتغييرات اللي بتحسّن تجربة الزوار الحقيقيين كتير مش هي هي.
ودي التغييرات اللي غالبًا بتبان في بيانات المستخدمين الحقيقية، مترتبة حسب المكسب لكل ساعة شغل.
بيانات المعمل، وبيانات الواقع، وليه رقم PageSpeed بيضللك
PageSpeed Insights بيعرض حاجتين الناس بتخلط بينهم طول الوقت. الجزء اللي فوق بيانات الواقع: مستخدمين Chrome حقيقيين على أجهزة حقيقية في آخر 28 يوم. والجزء اللي تحت اختبار معمل بيحاكي موبايل متوسط وشبكة متوسطة، بيتعمل مرة واحدة من مركز بيانات جوجل.
بيانات الواقع بس هي اللي بتتحسب في إشارة تجربة الصفحة عند جوجل. رقم المعمل أداة تشخيص، وفي منطقتنا أداة مش مظبوطة، لأن الشبكة اللي بيحاكيها مالهاش أي علاقة بالـ4G في القاهرة الساعة 9 بالليل، والموبايل اللي بيحاكيه غالبًا أسرع من اللي في إيد عميلك.
- LCP: بيقيس الوقت لحد ما أكبر حاجة في أول شاشة تظهر، وغالبًا بتبقى صورة أو عنوان في أول الصفحة.
- INP: الصفحة بتاخد قد إيه علشان ترد بعد ما تدوس. ده اللي مواقع ووردبريس بتسقط فيه.
- CLS: الصفحة بتتنطط قد إيه وهي بتحمّل.
لو موقعك مش بيجيله زيارات Chrome كفاية، PageSpeed ممكن ما يعرضش بيانات واقع خالص. ساعتها إنت شغال وإنت مغمّض، ولازم تضيف سكريبت صغير بيقيس المستخدمين الحقيقيين بدل ما تصدّق أرقام المعمل.
ليه مواقع ووردبريس بتسقط في INP
INP بيقيس قد إيه الخيط الرئيسي في المتصفح مشغول لما حد يدوس على حاجة. مواقع ووردبريس بتسقط فيه لسبب في تركيبتها: التثبيت العادي بيحمّل jQuery، وكذا إضافة كل واحدة بتضيف سكريبتاتها فوقه، وكل واحدة بتربط أحداث بالحاجات اللي الناس غالبًا هتدوس عليها. دوسة واحدة على عنصر في القايمة ممكن تشغّل سلسلة أحداث من أربع إضافات عمرهم ما اتكتبوا علشان يشتغلوا مع بعض.
أكبر المتهمين اللي بشوفهم كل مرة، بالترتيب:
- أدوات إدارة التاجز الخارجية اللي بتشغّل أكوادها بشكل متزامن أول ما الزائر يتفاعل.
- ودجتس الشات اللي بتحمّل واجهتها كلها مع أول دوسة في أي حتة في الصفحة.
- مكتبات السلايدر اللي بتتحمّل في كل صفحة، حتى الصفحات اللي مافيهاش سلايدر.
- سكريبتات التحليلات اللي بتتحمّل في الهيد من غير
async. - أدوات بناء الصفحات اللي بتحمّل محركها كله في صفحات معمولة من بلوكات ثابتة.
ست تصليحات مترتبة حسب الأثر لكل ساعة
| # | التصليح | المجهود | غالبًا بيحسّن |
|---|---|---|---|
| 1 | أخّر كل السكريبتات الخارجية اللي مش ضرورية (الشات، والخرايط الحرارية، وبيكسلات إعادة الاستهداف) لحد أول تفاعل | ساعة | INP، و LCP بشكل غير مباشر |
| 2 | اعمل preload لصورة الـLCP وشيل منها loading="lazy" | نص ساعة | LCP |
| 3 | قدّم صورة أول الصفحة بصيغة حديثة وبالمقاس الصح لكل عرض شاشة | ساعة لساعتين | LCP |
| 4 | وقّف تحميل CSS و JS بتوع الإضافات في الصفحات اللي مش بتستخدمها | من ساعتين لأربعة | INP |
| 5 | حط عرض وطول لكل صورة، واحجز مكان للإعلانات والحاجات المضمّنة | ساعتين | CLS |
| 6 | صلّح طريقة تحميل الخطوط (الجزء الجاي) | ساعة لساعتين | LCP و CLS |
ابدأ بالتصليح الأول في أي موقع تقريبًا. هو كود واحد، ومافيهوش أي خطر على التصميم، ومن تجربتي غالبًا هو أكبر تحسين متاح في INP.
خطوط الويب العربي: التكلفة الخفية على LCP
تقريبًا محدش بيكتب عن ده، وهو السبب إن مواقع عربي كتير الـLCP بتاعها أسوأ من نسختها الإنجليزي على نفس الاستضافة.
- ملفات الخطوط العربي كبيرة. العربي محتاج شكل الحرف في أول الكلمة ونصها وآخرها ولوحده، وكمان ربطات كتير، فالنسخة العربي من نفس الخط غالبًا أتقل من اللاتيني بكذا مرة.
- تقليل حروف الخط (subsetting) أصعب. ما تقدرش تشيل حروف من خط عربي بأمان زي ما بتقصّ خط لاتيني على مدى حروف معيّن، لأن أشكال الحروف وجداول الربط معتمدين على بعض.
- الصفحات اللي بلغتين بتحمّل عيلتين خطوط. صفحة عربي فيها أي كلام إنجليزي بخط لاتيني بتنزّل عيلتين قبل ما العنوان يظهر.
- تبديل الخط البديل مزعج. الخطوط العربي في النظام مختلفة في العرض وخط الأساس لدرجة إن التبديل بيعمل قفزة باينة، وده بيتحسب CLS وشكله وحش.
اللي بيشتغل: استضيف الخط بنفسك بدل ما تحمّله من طرف تالت، واعمل preload للوزن الواحد اللي مستخدم في أول شاشة بس، واستخدم font-display: swap مع خط بديل إنت قارنت مقاساته فعلًا، وقلّل عدد الأوزان. مواقع عربي كتير بتحمّل أربع أو خمس أوزان وبتستخدم اتنين. ولو خط العناوين وخط النص عيلتين مختلفتين، بتدفع التكلفة دي مرتين.
اختبر الجانب العربي من الموقع بالذات. موقع ووردبريس بلغتين ممكن ينجح في Core Web Vitals بالإنجليزي ويسقط بالعربي، ولأن أغلب الناس بيختبروا الصفحة الرئيسية بلغة واحدة بس، محدش بياخد باله شهور.
الحاجات اللي بطّلت أتعب فيها
- الجري ورا 100 على الموبايل. بعد نقطة معيّنة بتحسّن محاكاة، مش تجربة الناس.
- تصغير الـHTML. بيتقاس بالبايتات، ومش باين في بيانات الواقع.
- دمج كل الـCSS في ملف واحد. كانت نصيحة كويسة أيام HTTP/1.1، ودلوقتي تقريبًا مش فارقة.
- إضافات الـCritical CSS. في قالب معمول كويس المكسب صغير، وخطر إنها تكسر تصميم عربي من اليمين للشمال حقيقي.
- تغيير الاستضافة كأول خطوة. وقت رد السيرفر مهم، لكنه نادرًا ما يكون عنق الزجاجة في موقع الخيط الرئيسي فيه مقفول تانيتين بسبب سكريبتات.
لو عايز ده يتعمل صح مش إضافة بإضافة، ده جزء من شغلي في السيو التقني، ولما السرعة تقابل المبيعات، تحسين التحويل وصفحات الهبوط هو النص التاني من نفس المشكلة. ولو مشكلة الـLCP طلعت في الريندر أكتر من حجم الملفات، فالخطوة الجاية إنك تختبر جوجل بيعمل ريندر للجافاسكريبت بتاعك ولا لأ.
أسئلة شائعة
إضافة الكاش بتصلّح Core Web Vitals؟
بتساعد في وقت أول بايت، وبالتالي LCP شوية. ومش بتعمل أي حاجة لـINP، لأنها مشكلة في الخيط الرئيسي، وإضافات الكاش نفسها كتير بتضيف جافاسكريبت.
بيانات الواقع بتبيّن التصليح بعد قد إيه؟
Chrome UX Report بيستخدم فترة 28 يوم متحركة، فاتوقع حركة جزئية بعد أسبوع والصورة كاملة بعد شهر. ما تحكمش على تصليح بعد تلات أيام.
السرعة عامل ترتيب كبير؟
تأثيرها المباشر على الترتيب صغير، لكن تأثيرها على التحويل كبير. حسّنها علشان التحويل، والترتيب هييجي معاها ببلاش.
أسيب أداة بناء الصفحات؟
لو الموقع متبني خلاص، نادرًا ما يستاهل. لو بتعيد البناء أصلًا، قالب بلوكات أو قالب متكتب بإيد بيوفّر عليك من الأول كام مية كيلوبايت.
و AMP؟
مش مستاهل تبدأ فيه دلوقتي. مزاياه القديمة في الزيارات راحت، وبيضيف نسخة تانية من كل صفحة لازم تحافظ عليها.
عايز تعرف موقعك محتاج أنهي تصليح من الست قبل ما تصرف أسبوع على الغلط؟ ابعتلي موقعك.
استشاري سيو وتسويق رقمي من 2015، بيشتغل مع شركات في مصر والسعودية والإمارات.
عن الكاتب ومعايير الكتابة
