مقدمة لأداء الويب ومسار العرض الحرج

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

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

إخلاء المسؤولية : كل ​​المعلومات التي أشاركها في هذا المنشور هي ما تعلمته من خلال الدورات المجانية المذكورة في الأسفل والموجزة هنا لأي شخص مهتم.

مسار العرض الحرج

بادئ ذي بدء ، سيكون من المفيد فهم الخطوات التي يمر بها المتصفح بالفعل. يبدأ بملفات HTML و CSS وجافا سكريبت العادية ويمر عبر عرض الصفحة ورسمها ، ويصل في النهاية ليصبح ما يراه المستخدم.

يشار إلى هذه الخطوات من ملفات HTML و CSS و JS المختلفة إلى صفحة مرسومة عادةً باسم مسار العرض الحرج (أو CRP للاختصار).

يتكون مسار العرض الحرج من خمس خطوات مختلفة ، وأفضل شرح لها في الرسم البياني.

بناء DOM و CSSOM

تتكون معظم صفحات الويب من HTML و CSS و JavaScript ، والتي تشكل جميعها جزءًا مهمًا في CRP. من أجل قراءة HTML ومعالجته ، سيقوم المستعرض بإنشاء نموذج كائن المستند (DOM). يبحث المتصفح في علامات HTML (

و

و

و

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

لا تدع هذه المصطلحات تخيفك. تخيل DOM كشجرة كبيرة ذات فروع تمثل العقد الأصلية ، والتي بدورها تحتوي على أوراق ، العقد الفرعية. ستمثل هذه الشجرة تبعيات العقد في HTML الخاص بنا وتبدو مشابهة إلى حد ما لهذا:

في الصورة أعلاه ، يمكننا أن نرى عنصر الجذر الذي يشمل جميع أبنائه وهم بدورهم آباء يحتويون على أطفال أيضًا. ضع ذلك رأسًا على عقب وستبدو مثل الشجرة تقريبًا!

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

بعد إنشاء DOM ، سيقوم المستعرض الخاص بك بمعالجة CSS وبناء نموذج كائن CSS (CSSOM). هذه العملية تشبه إلى حد بعيد بناء DOM. ولكن في هذه العملية ، على عكس ما سبق ، ترث العقد الفرعية قواعد تصميم العقد الأصلية - ومن هنا جاء اسم Cascading Style Sheets (CSS).

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

ستحتوي شجرة DOM وشجرة CSSOM على جميع العقد والتبعيات الموجودة في صفحتنا.

تجميع كل المحتوى المرئي - The Render Tree

يحتاج المستعرض إلى معرفة العقد التي سيتم تمثيلها بشكل مرئي بالفعل على الصفحة. تحقق Render Tree ذلك بالضبط ، وهي تمثل المحتوى المرئي لـ DOM و CSSOM.

نبدأ في إنشاء Render Tree عن طريق تحديد عقدة الجذر ثم نسخ جميع المعلومات المرئية من DOM و CSSOM. لهذا نتحقق أيضًا من أننا نبحث عن العلامات التي لها نفس المحدد. لا يتم نسخ البيانات الوصفية والروابط وما إلى ذلك في شجرة العرض. الأمر نفسه ينطبق على CSS التي تحتوي على "display: none" لأنه أيضًا عنصر غير مرئي.

بمجرد أن نكمل هذه العملية ، نحصل على شيء مشابه لما يلي (لاحظ كيف لا يتم نسخ "أداء الويب").

يعتبر Render Tree وصفًا دقيقًا جدًا لما يتم عرضه لك بالفعل على الشاشة ، حيث يلتقط المحتوى والأنماط المرتبطة به. بالطبع ، قد يبدو هذا أكثر تعقيدًا في أمثلة الحياة الواقعية.

جعله مناسبًا - تخطيط

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

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

ارسم البكسل

تتضمن هذه الخطوة بالفعل رسم وحدات البكسل على الشاشة ، محددة بواسطة ماذا (Render Tree) وكيف (Layout). تتضمن خطوة الطلاء اللوحة الفعلية لوحدات البكسل (على سبيل المثال ، عند تغيير حجم الصورة) بدلاً من مجرد وضعها. هذا ما تراه في النهاية على شاشتك بعد ذلك.

دعونا نلخص

الآن دعنا نجمع كل هذه المعلومات معًا مرة أخرى حتى نتمكن من رؤية أننا أدركنا جميع الخطوات التي يجب أن نمر بها في مسار العرض الحرج (CRP)

  1. يبدأ المتصفح بإنشاء DOM عن طريق تحليل كل HTML ذي الصلة.
  2. ثم ينتقل بعد ذلك إلى إلقاء نظرة على موارد CSS و JavaScript ويطلبها ، وهو ما يحدث عادةً في الرأس حيث نضع روابطنا الخارجية عادةً.
  3. يقوم المتصفح بعد ذلك بتحليل CSS وإنشاء CSSOM متبوعًا بتشغيل JavaScript.
  4. ثم يتم دمج DOM و CSSOM معًا في Render Tree.
  5. نقوم بعد ذلك بتشغيل خطوة Layout and Painting لتقديم الصفحة إلى المستخدم.

حسنًا ، من الجيد معرفة ذلك - ولكن لماذا يهم ذلك؟

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

نعم فعلنا!

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

هذا صحيح بشكل خاص إذا طلبت صفحة من منطقة ريفية حيث لا يكون النطاق العريض السريع هو الأفضل بالضرورة.

لكن لحسن الحظ ، هناك عدة طرق للتغلب على هذا الأمر ويمكننا جعل صفحاتنا أسرع!

تحسين الأداء

هناك عدد من الاستراتيجيات التي يمكننا الاستفادة منها لجعل صفحاتنا أسرع وأفضل للاستخدام لمستخدمينا. هذا مهم بشكل خاص للمستخدمين الذين قد يكونون في مواقع بعيدة حيث لا يكون الإنترنت الأسرع هو القاعدة أو حيث يتم الوصول إلى الصفحات بشكل شائع عبر الإنترنت عبر الهاتف المحمول.

عندما نتحدث عن استراتيجيات التحسين ، لدينا تقريبًا ثلاث تقنيات تحت تصرفنا.

التصغير والضغط والتخزين المؤقت

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

تقليل استخدام موارد حظر العرض (CSS)

تقوم CSS نفسها بحظر العرض كما ناقشنا أعلاه ، مما يعني أن المتصفح سيتوقف عن عرض الصفحة حتى يتم تحميل CSS بالكامل ومعالجته.

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

تقليل استخدام موارد حظر المحلل اللغوي (محلل مستندات JS)

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

بشكل عام ، هذا يترك لنا 3 أنماط تحسين:

  1. قلل عدد البايت الذي ترسله
  2. تقليل عدد الموارد الهامة في مسار العرض الحرج (قد لا يلزم تحميل التحليلات في البداية عند إنشاء الصفحة)
  3. تقصير طول مسار العرض الحرج (بمعنى تقليل عدد جولات الذهاب والإياب بين متصفحك والخادم الذي نحتاجه لعرض الصفحة)

جربها بنفسك

إذا كنت حريصًا على تجربة هذا والبدء في التحسين ، فيمكنك قياس أداء موقع الويب الخاص بك أو غيره باستخدام عدد من الأدوات. الأسهل على الأرجح هو منتجات Google مثل PageSpeedInsights أو Google Lighthouse ، وهو ملحق صغير مفيد من Google Chrome يمكنك تثبيته بسهولة من خلال متجر تطبيقات Chrome.

ما عليك سوى النقر فوق الامتداد ثم إنشاء تقرير وستحصل على تقرير يتضمن ما يلي:

يمكنك بعد ذلك مقارنة أدائك بعدد من المقاييس ، مثل First Pixel Painted to the Screen ، و First Interactive ، و Visual Compliteness لموقعك ، والعديد من المقاييس الأخرى.

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

استنتاج

نأمل أن يكون هذا قد ألقى بعض الضوء على الأعمال الداخلية لكيفية عرض متصفحك لصفحة ما والعمل الشاق الذي يحتاجه لإكماله في الخلفية للتأكد من تحويل HTML و CSS وجافا سكريبت بشكل صحيح.

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

مصادر

اكتسبت معظم معرفتي التي شاركتها هنا من خلال ما يلي:

  1. تحسين أداء موقع الويب على Udacity
  2. لماذا يهم الأداء على Google Developers
  3. شبكة متصفح عالية الأداء بواسطة Ilya Grigorik (//hpbn.co/)
  4. مواقع الويب عالية الأداء: المعرفة الأساسية لمهندسي الواجهة الأمامية لستيف سودرس