اعتبارات أداء 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 المخزّن مؤقتًا قد يصبح قديمًا بعد عملية نشر، لأنّه سيحتوي على مراجع إلى موارد فرعية قديمة.

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

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

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

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

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

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

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

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

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

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

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

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

الضغط

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

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

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

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

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

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

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

ما هو نوع عملية إعادة التوجيه التي يمكنك التحكّم فيها بالكامل؟

عملية إعادة توجيه من المصدر نفسه
عملية إعادة توجيه مشتركة النطاق

يمكن أن يحتوي العنوان Server-Timing على مقاييس متعددة.

صحيح
خطأ

ما هو نوع الخادم الذي من المرجّح أن يكون الأقرب جغرافيًا إلى المستخدمين النهائيين؟

خوادم الحافة في شبكة توصيل المحتوى (CDN)
خادم المصدر لموقعك الإلكتروني

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

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