لماذا يُفتح الموقع ببطء؟

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

فتح الصفحة مرة ورؤيتها سريعة ليس تشخيصًا أيضًا. الصفحة نفسها قد تنتظر على نحو مختلف على الهاتف، وعلى اتصال ضعيف. سير العمل على الهاتف اختبار مستقل. ذلك الاختبار ينظر هل ينتهي العمل. هذه المقالة تنظر إلى الانتظار.

حين يفتح الزائر الصفحة ينتظر إطارًا. إن بقي ذلك الإطار بالحجم الذي خرج به من الكاميرا، فالانتظار زمن الملف لا زمن التصميم. صورة تبدو صغيرة على الشاشة تنزّل الملف الكبير إن كان الملف كبيرًا. تصغير الإطار لا يصغّر التنزيل.

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

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

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

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

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

قبل أن تُرسم الصفحة يُنتظَر جواب الخادم الأول. اسمه TTFB، الزمن حتى البايت الأول. لا يكتبه web.dev كقياس من Core Web Vitals. وكدليل تقريبي يقول إن على أكثر المواقع أن تهدف إلى TTFB من 0.8 ثانية أو أقل. القيمة التي تُعد جيدة 0.8 ثانية أو دونها، والتي تُعد ضعيفة فوق 1.8 ثانية. وتكتب الصفحة نفسها أن بلوغ العتبة الجيدة ليس لازمًا وحده. العتبة ليست قرارًا بمفردها ما دامت لا تطيل التجربة التي تليها.

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

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

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

البنود أدناه ليست وصفة إصلاح. هي الملاحظة التي تُكتب قبل أن تُسلَّم إلى مطوّر. بلا الملاحظة يكون الإصلاح تخمينًا. والتخمين قد ينتهي أيضًا بإضافة كود جديد إلى الصفحة.

في N2 Creative نرى من الصواب، في عمل الموقع والبرمجيات، أن نفتح جملة الموقع بطيء بهذه الملاحظة. الأسماء والعتبات تبقى في مقالة القياس. ما يبقى هنا هو الشيء الذي انتظره الزائر.