اعتبارات أداء 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 مؤقتًا في مثل هذه الحالات.

يُرجى الانتباه إلى طريقة تخزين محتوى 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 وتحليلها لمعرفة ما إذا كان المستخدمون يواجهون التأخير. في مقتطف الرمز السابق، يتضمّن عنوان الاستجابة توقيتَين:

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

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

الضغط

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

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

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

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

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

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

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

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

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