اعتبارات أداء HTML العامة

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

يمر هذا الطلب الأولي لـ HTML بعدة خطوات، وتستغرق كل منها بعض الوقت. من خلال تخفيض الوقت المستغرق في كل خطوة، يمكنك زيادة الوقت المستغرق في أول بايت (TTFB) بشكل أسرع. على الرغم من أنّ مقياس TTFB ليس المقياس الوحيد الذي يجب التركيز عليه عندما يتعلق الأمر بسرعة تحميل الصفحات، يجعل ارتفاع TTFB من الصعب الوصول إلى الحدود "الجيدة" المحددة لمقاييس مثل سرعة عرض أكبر محتوى مرئي (LCP) وسرعة عرض أكبر محتوى مرئي (FCP).

تصغير عمليات إعادة التوجيه

عند طلب مورد، قد يستجيب الخادم بإعادة توجيه إما من خلال إعادة توجيه نهائية (استجابة 301 Moved Permanently) أو بإعادة إعادة توجيه مؤقتة (استجابة 302 Found).

تؤدي عمليات إعادة التوجيه إلى إبطاء سرعة تحميل الصفحة لأنّها تتطلّب من المتصفّح إجراء طلب HTTP إضافي في المكان الجديد لاسترداد المورد. هناك نوعان من عمليات إعادة التوجيه:

1. عمليات إعادة التوجيه من المصدر نفسه التي تحدث بالكامل داخل المصدر وتكون هذه الأنواع من عمليات إعادة التوجيه خاضعة تمامًا لسيطرتك، لأنّ منطق إدارتها يكمن بالكامل في خادم الويب.
2. عمليات إعادة التوجيه متعددة المصادر التي بدأها مصدر آخر. عادةً ما تكون هذه الأنواع من عمليات إعادة التوجيه خارجة عن سيطرتك.

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

تخزين استجابات HTML في ذاكرة التخزين المؤقت

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

مع ذلك، يمكن أن تكون مدة التخزين المؤقت القصيرة، بدلاً من عدم التخزين المؤقت، مزايا مثل السماح بتخزين مورد مؤقتًا في شبكة توصيل المحتوى (CDN)، ما يقلّل من عدد الطلبات المعروضة من خادم المصدر وفي المتصفِّح، ما يسمح بإعادة التحقق من صحة الموارد بدلاً من تنزيلها مرة أخرى. يعمل هذا النهج بشكل أفضل مع المحتوى الثابت الذي لا يتغير في أي سياق، ويمكن تعيين الوقت المناسب لتخزين الموارد على عدد من الدقائق التي تراها مناسبة. تعد خمس دقائق لموارد HTML الثابتة بمثابة رهان آمن، وتضمن عدم تمر التحديثات الدورية بدون ملاحظتها.

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

قد يكون استخدام عنوان الاستجابة ETag أو Last-Modified نهجًا حذرًا لتخزين HTML في ذاكرة التخزين المؤقت. إنّ رأس ETag، والمعروف أيضًا باسم علامة الكيان، هو معرّف يمثّل المورد المطلوب بشكلٍ فريد، وغالبًا ما يتم ذلك باستخدام جزء من محتوى المورد:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

عند تغيير المورد، يجب إنشاء قيمة ETag جديدة. وفي الطلبات اللاحقة، يرسل المتصفِّح قيمة ETag من خلال عنوان طلب If-None-Match. في حال تطابق ETag على الخادم مع العنوان الذي يرسله المتصفّح، يستجيب الخادم بالاستجابة 304 Not Modified، ويستخدِم المتصفّح المورد من ذاكرة التخزين المؤقت. على الرغم من أنّ ذلك لا يزال ينطوي على وقت استجابة الشبكة، إلا أنّ استجابة 304 Not Modified أصغر بكثير من مورد HTML بالكامل.

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

قياس أوقات استجابة الخادم

وإذا لم يتم تخزين الاستجابة مؤقتًا، يعتمد وقت استجابة الخادم بشكل كبير على المستضيف وحزمة تطبيقات الخلفية. قد تحتوي صفحة الويب التي تقدِّم استجابة تم إنشاؤها ديناميكيًا، مثل جلب البيانات من قاعدة بيانات على سبيل المثال، على قيمة أعلى من مقياس "تحويل النص إلى كلام" (TFB) مقارنةً بصفحة الويب الثابتة التي يمكن عرضها على الفور بدون وقت طويل حسابي في الخلفية. يؤدي عرض مؤشر سريان عمل التحميل ثم استرجاع جميع البيانات من جهة العميل إلى نقل الجهد من بيئة أكثر قابلية للتوقّع من جهة الخادم إلى بيئة غير متوقَّعة من جهة العميل. عادةً ما يؤدي تقليل الجهد من جانب العميل إلى تحسين المقاييس التي تركز على المستخدم.

إذا كان المستخدمون يواجهون بطئًا في TTFB في الحقل، يمكنك عرض معلومات عن الوقت الذي قضيته على الخادم من خلال استخدام عنوان الاستجابة Server-Timing:

Server-Timing: auth;dur=55.5, db;dur=220

يمكن أن تتضمّن قيمة عنوان Server-Timing مقاييس متعدّدة، بالإضافة إلى مدة لكل مقياس. ويمكن بعد ذلك جمع هذه البيانات من المستخدمين في الحقل باستخدام واجهة برمجة تطبيقات Navigation Timing وتحليلها لمعرفة ما إذا كان المستخدمون يواجهون حالات تأخير. في مقتطف الرمز السابق، يتضمن عنوان الاستجابة وقتين:

• وقت مصادقة المستخدم (auth)، والذي استغرق 55.5 مللي ثانية.
• وقت الوصول إلى قاعدة البيانات (db)، الذي استغرق 220 مللي ثانية.

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

الضغط

يجب ضغط الاستجابات المستندة إلى النص، مثل صور HTML وJavaScript وCSS وSVG، لتقليل حجم نقلها عبر الشبكة حتى يتم تنزيلها بسرعة أكبر. خوارزميات الضغط الأكثر استخدامًا هي gzip وBotli. يؤدي استخدام Brotli إلى تحسُّن بنسبة تتراوح بين% 15 و% 20 مقارنةً ببرنامج gzip.

غالبًا ما يتم إعداد الضغط من قِبل معظم مستضيفي الويب تلقائيًا، ولكن هناك بعض الأمور المهمة التي يجب مراعاتها إذا كان بإمكانك ضبط إعدادات الضغط أو تعديلها بنفسك:

1. استخدِم Brotli حيثما أمكن ذلك. كما ذُكر سابقًا، توفر Brotli تحسينات ملحوظة إلى حد ما على برنامج gzip، وButli متوافقة مع جميع المتصفحات الرئيسية. استخدِم Brotli عندما يكون ذلك ممكنًا، ولكن إذا كان عدد كبير من المستخدمين يستخدم موقعك الإلكتروني على المتصفّحات القديمة، احرص على استخدام gzip كأداة احتياطية، لأنّ أي ضغط أفضل من عدم الضغط على الإطلاق.
2. حجم الملف مهم. إذا كان حجم الموارد الصغيرة جدًا، التي تقل عن 1 كيبيبايت، لا يتم ضغطها بشكل جيد للغاية، أو أحيانًا لا يتم ضغطها على الإطلاق. تعتمد فعالية أي نوع من ضغط البيانات على وجود كمية كبيرة من البيانات التي يمكن لخوارزمية الضغط العمل عليها للعثور على وحدات بت أكثر قابلية للضغط. كلما زاد حجم الملف، كان الضغط يعمل بشكل أفضل، ومع ذلك، لا تشحن موارد كبيرة جدًا لمجرّد ضغطها بفعالية أكبر. تستغرق الموارد الكبيرة، مثل JavaScript وCSS على سبيل المثال، وقتًا أطول بكثير لتحليلها وتقييمها بعد فك ضغط المتصفح، وقد تتغير بمعدّل أكبر حتى إذا تغيّرت بشكل طفيف، لأن أي تغييرات تؤدي إلى تجزئة ملف مختلفة.
3. التعرّف على الضغط الديناميكي مقابل الضغط الثابت: يختلف الضغط الديناميكي والثابت عن الحالات التي يجب فيها ضغط المورد. يضغط الضغط الديناميكي المورد عند طلبه، وأحيانًا في كل مرة يتم طلبه. ومن ناحية أخرى، يعمل الضغط الثابت على ضغط الملفات قبل الوقت، ما لا يتطلّب أي ضغط في وقت إرسال الطلب. يعمل الضغط الثابت على إزالة وقت الاستجابة الناتج عن الضغط نفسه، وهو ما قد يزيد من أوقات استجابة الخادم في حالة الضغط الديناميكي. يجب ضغط الموارد الثابتة، مثل صور JavaScript وCSS وSVG، بشكل ثابت، في حين يجب ضغط موارد HTML ديناميكيًا خاصة إذا تم إنشاؤها ديناميكيًا للمستخدمين الذين تمت مصادقتهم.

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

شبكات توصيل المحتوى (CDN)

شبكة توصيل المحتوى (CDN) هي شبكة موزَّعة من الخوادم التي تخزِّن الموارد في ذاكرة التخزين المؤقت من خادم المصدر، وتقدّمها بدورها من خوادم خارجية تكون أقرب من المستخدمين فعليًا. يقلّل التقارب الفعلي للمستخدمين من وقت إرسال الرسائل واستقبالها (RTT)، في حين أنّ التحسينات مثل HTTP/2 أو HTTP/3 والتخزين المؤقت والضغط تسمح لشبكة توصيل المحتوى بعرض المحتوى بسرعة أكبر مقارنةً بجلبه من خادم المصدر. يمكن أن يؤدي استخدام شبكة توصيل المحتوى (CDN) إلى تحسين كبير في عدد (TTFB) لموقعك الإلكتروني في بعض الحالات.

اختبِر معلوماتك

التالي: فهم المسار الحرج

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