طريقة تسريع AMP للأداء

تمثل التحسينات التالية - مجتمعةً - السبب الذي يجعل صفحات AMP سريعة لدرجة تجعل تحميلها يبدو وكأنه يتم في التو واللحظة:

إذا كنت ممن يفضلون الاستماع على القراءة، فإن الفيديو التالي من تقديم Malte Ubl، رئيس فريق هندسة AMP، يمنحك نظرة عامة مماثلة للفقرات التالية.

السماح بالنصوص البرمجية غير المتزامنة فقط

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

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

وفي حين يتم السماح بـ JS من الجهات الخارجية في إطارات iframe، لكن لا يمكنها إعاقة العرض. على سبيل المثال، إذا كانت JS التابعة لجهات خارجية تستخدم واجهة برمجة تطبيقات document.write ذات التأثير السيء للغاية على الأداء، فهي لا تعيق عرض الصفحة الرئيسية.

تحديد حجم كل الموارد بشكل ثابت

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

تفصل AMP تنسيق المستند عن تنسيق المورد. ليست هناك حاجة سوى لطلب HTTP واحد لتنسيق المستند كاملاً، (+الخطوط). ونظرًا لأن AMP محسّنة لتجنب عمليات إعادة حساب النمط والتنسيقات كثيفة الاستهلاك في المتصفح، لن تكون هناك أي إعادة للتنسيق عند تحميل الموارد.

عدم السماح لآليات الإضافة بإعاقة العرض

لا تسمح AMP لآليات الإضافة بإعاقة عرض الصفحة. تدعم AMP الإضافات لأشياء، مثل العروض المبسطة، وتضمينات instagram، والتغريدات، وغير ذلك. وفي حين تستلزم هذه الأشياء طلبات HTTP إضافية، لا تعيق هذه الطلبات تنسيق الصفحة وعرضها.

يجب أن تخبر أي صفحة تستخدم نصًا برمجيًا مخصصًا نظامَ AMP أنها سوف ستتضمن في النهاية علامة مخصصة. على سبيل المثال، يخبر النص البرمجي amp-iframe النظام بأنه ستكون هناك علامة amp-iframe. تنشئ AMP مربع iframe قبل أن تعرف حتى ما الذي سيتضمنه:

<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>

إبقاء كل جافا سكريبت التابعة لجهة خارجية بعيدًا عن المسار الحرج

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

تسمح صفحات AMP بجافا سكريبت من الجهات الخارجية، ولكن فقط في إطارات iframe في وضع الحماية. عبر حظرها في إطارات iframe، لا يمكنها إعاقة تنفيذ الصفحة الرئيسية. وحتى إذا قامت بتشغيل العديد من عمليات إعادة حساب النمط، فإن إطارات iframe بالغة الصغر تتضمن DOM صغيرة للغاية.

عمليات إعادة حساب النمط والتنسيقات نموذجية بالنسبة لحجم DOM، ولذلك تكون عمليات إعادة حساب إطار iframe سريعة للغاية مقارنةً بإعادة حساب الأنماط والتنسيق للصفحة.

يجب أن تكون كل CSS مضمّنة ومقيدة بالحجم المحدد

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

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

يجب أن يكون تشغيل الخطوط فعالاً

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

يعلن نظام AMP أن قيمة طلبات HTTP تساوي صفرًا إلى أن يبدأ تنزيل الخطوط. ولا يكون هذا ممكنًا إلا لأن كل JS في AMP يتميز بالسمة غير المتزامنة وغير مسموح إلا بورقات الأنماط المضمّنة؛ فلا توجد طلبات HTTP تحول دون تنزيل المتصفح للخطوط.

تقليل عمليات حساب الأنماط لأدنى حد

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

تعرّف على المزيد بشأن تأثير عمليات إعادة حساب الأنماط والتنسيقات على أداء العرض.

الاقتصار على تشغيل العناصر المتحركة المسرّعة بواسطة وحدة معالجة رسومات

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

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

وضع تحميل الموارد كأولوية

تتحكم AMP في كل تنزيلات الموارد: فهي تضع تحميل الموارد كأولوية، وبذلك لا يتم تحميل سوى الضروري فقط، وتجلب الموارد بطيئة التحميل مسبقًا.

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

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

تحميل الصفحات على الفور

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

وبالرغم من أن العرض المسبق يمكن تطبيقه على كل محتوى الويب، لكنه قادر أيضًا على استنفاد مقدار كبير من معدل نقل البيانات ووحدة المعالجة المركزية (CPU). يتم تحسين AMP لتقليل كلٍّ من هذين العاملين. لا يقوم العرض المسبق إلا بتنزيل الموارد في الجزء المرئي من الصفحة ولا يعرض العرض المسبق الأشياء التي قد تستنزف وحدة المعالجة المركزية (CPU).

عند إخضاع مستندات AMP للعرض المسبق للحصول على التحميل الفوري، لا يتم فعليًا تنزيل سوى الموارد التي تكون في الجزء المرئي من الصفحة. عند خضوع مستندات AMP للعرض المسبق للحصول على التحميل الفوري، لا يتم تنزيل الموارد التي قد تستهلك الكثير من موارد وحدة المعالجة المركزية (CPU) (مثل إطارات iframe من جهة خارجية).

تعرّف على المزيد بشأن أسباب عدم استفادة AMP HTML استفادة كاملة من فاحص التحميل المسبق.

ساعد في إضفاء سرعة أكبر على AMP

تمثل AMP جهدًا مفتوح المصدر. نحتاج إلى مساعدتك في إضفاء المزيد من السرعة على AMP. تعرّف على كيفية المساهمة.

See what AMP can do for you