تحلل أداة PageSpeed Insights إحدى الصفحات لمعرفة ما إذا كانت تتبع توصياتنا لجعل الصفحة يتم عرضها في أقل من ثانية على شبكة الجوّال. فقد أظهرت الأبحاث أن أي تأخير عن ثانية واحدة سيتسبب في مقاطعة تدفق أفكار المستخدم، مما يؤدي إلى تجربة سيئة. إن هدفنا هو الإبقاء على تفاعل المستخدم مع الصفحة وتقديم التجربة الأمثل، بغض النظر عن الجهاز أو نوع الشبكة.
ليس من السهل استيفاء المهلة الزمنية البالغة ثانية واحدة. ولحسن حظنا، لا يجب أن يتم عرض الصفحة بأكملها في حدود هذه الميزانية، بدلاً من ذلك، يجب علينا تقديم محتوى الجزء المرئي من الصفحة (ATF) وعرضه في أقل من ثانية واحدة، مما يسمح للمستخدم ببدء التفاعل مع الصفحة في أقرب وقت ممكن. وبينما يعمل المستخدم على فهم الصفحة الأولى من المحتوى، يمكن أن يتم تقديم باقي الصفحة تدريجيًا في الخلفية.
التكيّف مع شبكات الجوّال التي تستغرق وقتًا طويلاً للاستجابة
إن استيفاء معيار ATF الذي يبلغ ثانية واحدة على أجهزة الجوّال يفرض تحديات فريدة لا توجد على الشبكات الأخرى. يمكن للمستخدمين الدخول إلى موقعك عبر مجموعة مختلفة من شبكات الجيل الثاني والثالث والرابع. وتكون أوقات استجابة الشبكة أعلى بكثير من الاتصال السلكي، وتستهلك جزءًا كبيرًا من الميزانية التي تبلغ 1000 ملي ثانية لعرض محتوى ATF.
الجيل الرابع هو نوع الشبكة السائد حول العالم، لذا يجب أن تتوقع أن معظم المستخدمين سيدخلون إلى صفحتك على شبكة الجيل الرابع. ولهذا السبب، علينا أن نفترض أن كل طلب من الشبكة سيستغرق في المتوسط 100 مللي ثانية.
مع وضع كل ذلك في الاعتبار، علينا تطبيق ذلك على ما سبق. إذا نظرنا إلى تسلسل نموذجي من الاتصال بين متصفح وخادم، تكون قد استنفدت 300 مللي ثانية من ذلك الوقت من خلال حمل الشبكة: بحث نظام أسماء النطاقات لحل اسم المضيف (على سبيل المثال، google.com) إلى عنوان IP، وجولة ذهاب وعودة إلى الشبكة لإجراء تأكيد اتصال TCP، واتصال اختياري عبر بروتوكول أمان طبقة النقل (TLS). ويتركنا ذلك 700 مللي ثانية.
تقديم تجربة العرض في أقل من ثانية واحدة
بعد طرح وقت استجابة الشبكة، يبقى لدينا 700 مللي ثانية فقط في الميزانية، ولا يزال هناك الكثير من العمل الذي يتعين القيام به: يجب على الخادم عرض الاستجابة، ويجب تنفيذ رمز التطبيق من جهة العميل، ويجب على المتصفح تخطيط المحتوى وعرضه. ومع وضع ذلك في الاعتبار، فإن المعايير التالية يجب أن تساعدنا في البقاء ضمن المهلة:
- (1) يجب أن يعرض الخادم الاستجابة (في أقل من 200 مللي ثانية)
- وقت استجابة الخادم هو الوقت الذي يستغرقه الخادم لعرض محتوى HTML الأولي، ما يؤدي إلى احتساب وقت نقل الشبكة. ونظرًا لأن لدينا وقتًا قليلاً جدًا - فإنه من المثالي أن يتم إجراء ذلك خلال 200 مللي ثانية ويفضل أن يتم في أقل من ذلك!
- (2) يجب أن يتم تقليل عدد عمليات إعادة التوجيه إلى الحد الأدنى
- يمكن أن تؤدي عمليات إعادة توجيه HTTP الإضافية إلى إضافة رحلة ذهاب وعودة إضافية إلى الشبكة (جولتان أو جولتان عند الحاجة إلى بحث نظام أسماء النطاقات)، ما ينتج عنه مئات المللي ثانية من وقت الاستجابة الإضافي على شبكات الجيل الرابع. ولهذا السبب، فإننا ننصح بشدة مشرفي المواقع بتقليل عدد عمليات إعادة التوجيه إلى الحد الأدنى، والتخلص منها بشكلٍ مثالي تمامًا - يكون ذلك مهمًا حقًا بالنسبة إلى مستندات HTML (تجنب عمليات إعادة التوجيه "m dot" قدر المستطاع).
- (3) يجب أن يتم تقليل عدد جولات الذهاب والإياب حتى يتم العرض الأول إلى الحد الأدنى
-
نظرًا لكيفية تقدير TCP لسعة الاتصال (أي بطء بدء TCP)، فإن اتصال TCP الجديد لا يمكن أن يبدأ على الفور في استخدام المعدل الكامل المتاح لنقل البيانات بين العميل والخادم. ونظرًا لذلك، فإن الخادم يمكنه إرسال ما يصل إلى 10 حزم TCP في الاتصال الجديد (14 كيلوبايت تقريبًا) في جولة الذهاب والإياب الأولى، ثم يجب عليه انتظار قبول العميل لهذه البيانات حتى يمكنه زيادة نافذة ازدحام الشبكة والمتابعة لتقديم المزيد من البيانات.
ومن المهم أيضًا ملاحظة أن حد الحزم البالغ عددها 10 حزم (IW10) تم تحديثه مؤخرًا ليتوافق مع معيار TCP: يجب عليك التأكد من ترقية الخادم إلى أحدث إصدار للاستفادة من هذا التغيير. وإلا فإن الحد سيتراوح من 3 إلى 4 حزم على الأرجح!
وبسبب سلوك TCP هذا، فإنه من المهم تخصيص المحتوى التابع لك لتقليل عدد جولات الذهاب والإياب إلى الحد الأدنى المطلوب لعرض البيانات المطلوبة لإجراء العرض الأول للصفحة. من المفترض أن يتلاءم محتوى ATF مع أقل من 98 كيلوبايت بشكل مثالي، وهذا يسمح للمتصفح بعرض الصفحة بعد ثلاث جولات ذهاب وعودة فقط للحصول على ميزانية وقت كافية لوقت استجابة استجابة الخادم وعرض العميل.
- (4) تجنب الحظر الخارجي لعناصر جافا سكريبت وCSS في محتوى الجزء المرئي
-
حتى يتمكن المتصفح من عرض إحدى الصفحات للمستخدم، يجب أن يحلل الصفحة. وإذا واجه المتصفح نصًا برمجيًا خارجيًا للتزامن أو الحظر أثناء التحليل، يجب أن يتوقف وينزِّل هذا المورد. وفي كل مرة ينفذ ذلك، فإنه يضيف جولة ذهاب وإياب، مما يتسبب في تأخير العرض الأول للصفحة.
ونتيجة لذلك، فإن عناصر جافا سكريبت وCSS المطلوبة لعرض المنطقة المرئية وعناصر جافا سكريبت وCSS المطلوبة لإضافة وظائف إضافية إلى الصفحة يجب أن يتم تحميلها بعد تقديم محتوى ATF.
- (5) احتفظ بوقت لإجراء المتصفح التنسيق والعرض (200 مللي ثانية)
- تستغرق عملية تحليل ترميز HTML وCSS وتنفيذ JavaScript وقتًا ويستغرِق الأمر موارد العميل. وبناءً على سرعة جهاز الجوّال ومدى تعقيد الصفحة، فإن هذه العملية يمكن أن تستغرق المئات من المللي ثوانٍ. وإننا نوصي بالاحتفاظ بمدة تبلغ 200 مللي ثانية لحمل المتصفح.
- (6) تحسين وقت تنفيذ جافا سكريبت والعرض
- قد يستغرق تنفيذ النصوص البرمجية المعقّدة والرموز غير الفعّالة عشرات ومئات المللي ثانية، لذا استخدِم أدوات المطوّرين المضمَّنة في المتصفّح لتحليل الرمز البرمجي وتحسينه. للحصول على مقدمة رائعة، ألقِ نظرة على دورة تدريبية تفاعلية على أدوات مطوّري برامج Chrome.
الأسئلة الشائعة
- أستخدم مكتبة جافا سكريبت، مثل JQuery، فهل هناك أية نصائح؟
- يتم استخدام العديد من مكتبات JavaScript، مثل JQuery، لتحسين الصفحة وإضافة عناصر تفاعلية وصور متحركة وغير ذلك من التأثيرات. ومع ذلك، فإن العديد من هذه السلوكيات يمكن أن تتم إضافته بشكلٍ آمن بعد أن يتم عرض محتوى ATF. يمكنك فحص حركة التنفيذ وتحميل محتوى جافا سكريبت هذا حتى بعد أن يتم تحميل الصفحة.
- أستخدم إطار عمل جافا سكريبت لتكوين الصفحة، فهل هناك أية نصائح؟
- إذا تم إنشاء محتوى الصفحة باستخدام لغة JavaScript من جهة العميل، يجب التحقق من عملية تضمين وحدات JavaScript ذات الصلة لتجنّب المزيد من جولات الشبكة ذهابًا وإيابًا. وبالمثل، يمكن أن يؤدي تحسين العرض على الجهاز الخادم إلى تحسن كبير في أداء تحميل الصفحة للمرة الأولى: لعرض نماذج جافا سكريبت على الخادم، وتضمين النتائج في HTML واستخدام النمذجة من طرف العميل بمجرد تحميل التطبيق.
- كيف يمكنني تحديد عناصر CSS الحرجة على صفحتي؟
- في "أدوات مطوّري برامج Chrome"، افتح لوحة "التدقيقات" وشغِّل تقرير "أداء صفحة الويب" في التقرير الذي تم إنشاؤه، وابحث عن "إزالة قواعد CSS غير المستخدمة". أو استخدم أية أداة أو نص برمجي تابع لجهة خارجية لتحديد محددات CSS التي تم تطبيقها على كل صفحة.
- هل يمكن تنفيذ أفضل الممارسات هذه تلقائيًا؟
- بكل تأكيد. هناك العديد من المنتجات التجارية ومنتجات تحسين أداء الويب مفتوحة المصدر (WPO) التي يمكن أن تساعدك في استيفاء بعض أو جميع المعايير الواردة أعلاه. للتعرف على الحلول مفتوحة المصدر، ألقِ نظرة على أدوات تحسين PageSpeed.
- كيف يمكنني ضبط الخادم لاستيفاء هذه المعايير؟
-
عليك أولاً التأكّد من أنّ الخادم يعمل بأحدث إصدار من نظام التشغيل. للاستفادة من حجم نافذة ازدحام TCP الأولي المتزايد (IW10)، ستحتاج إلى الإصدار 2.6.39 من Linux kernel والإصدارات الأحدث. بالنسبة إلى أنظمة التشغيل الأخرى، يمكنك الرجوع إلى الوثائق.
لتحسين وقت استجابة الخادم، يمكنك قياس أداء الرمز البرمجي أو استخدام أحد حلول مراقبة التطبيق لتحديد المؤثِّر السلبي، على سبيل المثال، وقت تشغيل البرمجة النصية، واستدعاءات قاعدة البيانات، وطلبات RPC، والعرض، وما إلى ذلك. والهدف من ذلك هو عرض استجابة HTML في غضون 200 مللي ثانية. - ماذا بشأن سياسة أمان المحتوى؟
- إذا كنت تستخدم سياسة أمان المحتوى، قد تحتاج إلى تعديل السياسة التلقائية.
أولاً، تضمين سمات CSS في عناصر HTML(على سبيل المثال،< p style=...>) كلما أمكن ذلك، لأنّها غالبًا ما تؤدي إلى تكرار رموز غير ضروري، ويتم حظرها تلقائيًا من خلال سياسة أمان المحتوى (CSP) (يتم إيقافها من خلال "تضمين غير آمن" في "style-src"). وفي حال تفعيل سياسة CSP، سيتم حظر جميع علامات النصوص البرمجية المضمّنة تلقائيًا. إذا كنت تستخدم لغة JavaScript مضمَّنة، عليك تعديل سياسة CSP إما لاستخدام تجزئات النصوص البرمجية أو النصوص البرمجية غير البرمجية أو استخدام "تضمين غير آمن" لتفعيل جميع النصوص البرمجية المضمّنة. إذا كانت لديك أنماط مضمّنة، ستحتاج إلى تحديث سياسة CSP إما لاستخدام تجزئات الأنماط أو النصوص البرمجية الاعتباطية أو استخدام "تضمين غير آمن" لتفعيل جميع عمليات حظر الأنماط المضمَّنة.
هل لديك المزيد من الأسئلة؟ يرجى عدم التردد في طرح أسئلتك وتقديم ملاحظاتك في مجموعة المناقشة على العنوان pagespeed-insights-discuss.
إضافة ملاحظات
هل كان المحتوى في هذه الصفحة مفيدًا؟