تحسين
الأداء

نجمع البيانات الميدانية، أي قيم Core Web Vitals كما يعيشها الزوار فعلاً، ونصنّفها حسب نوع الصفحة وفئة الجهاز والدولة ونوع الاتصال، ثم نطابقها مع التحليلات و Search Console. هذه الخطوة هي الأكثر تخطّياً، وتخطّيها هو سبب إنفاق فرق كاملة أسابيع في تحسين صفحة كانت أصلاً سريعة لدى الجمهور المهم.

بعد تحديد الصفحات المتضررة نعيد إنتاج المشكلة تحت تقييد للمعالج والشبكة يشبه هاتف Android متوسط الفئة لا حاسب مطوّر. يكشف تحليل مخطط التحميل، وتتبّع المهام الطويلة، وتوقيت الخادم كم من التأخير سببه الشبكة، وكم سببه العمل على الخيط الرئيسي، وكم منه وقع قبل إرسال أول بايت أصلاً.

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

ثم نعالج ما يضطر المتصفح لتنزيله وتنفيذه: شيفرة JavaScript تُرسل ولا تُستخدم، وhydration تعطّل التفاعل، وخطوط تؤخّر ظهور النص، وصور أكبر بكثير من المساحة التي ستظهر فيها. يجب أن يكون محتوى أعلى الصفحة مرئياً من استجابة الخادم نفسها، لا أن يظهر بعد اكتمال حزمة العميل — وهو خلل واجهناه في الإنتاج وأصلحناه.

نحدد ما يمكن تخزينه على حافة الـ CDN، وما مكانه ذاكرة الخادم أو التطبيق، وما يمكن توليده ثابتاً وتحديثه دورياً، ثم الجزء الذي يُهمَل غالباً: كيف تُبطَل كل طبقة بدقة عند تغيّر المحتوى. التخزين المؤقت بلا خطة إبطال ينتج ثاني أسوأ نتيجة في هندسة الويب: صفحات سريعة تعرض بيانات خاطئة.

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