آلية عمل AMP
التحسينات التالية مجتمعة هي سبب سرعة تحميل صفحات AMP الكبيرة كما لو كانت فورية. هناك 7 أسباب إجمالاً - ولكن إذا كانت الأسباب كثيرة للغاية ليتم الاطّلاع عليها، فما عليك سوى مشاهدة الفيديو التوضيحي:
تنفيذ جميع تعليمات AMP JavaScript البرمجية على نحو غير متزامن
تتميز لُغة JavaScript بفعاليتها، حيث يمكنها إجراء تعديل لكل جانب من جوانب الصفحة تقريبًا، ولكن يمكنها أيضًا حظر إنشاء DOM (نموذج العناصر في المستند) وتأخير عرض الصفحة (راجع أيضًا إضافة التفاعلية مع JavaScript). لمنع JavaScript من تأخير عرض الصفحة، لا يسمح AMP إلا بلُغة JavaScript غير المتزامنة.
قد تتضمن مكونات AMP تعليمات JavaScript البرمجية في تركيبها الأساسي، ولكنها مصممة بعناية لضمان عدم تسببها في انخفاض الأداء.
بينما يُسمح بلُغة JS المخصصة في amp-script، ويُسمح بلُغة JS التابعة لطرف ثالث في أُطُر iframe، إلا أنه لا يمكنها حظر العرض. فعلى سبيل المثال، إذا استخدمت لُغة JS التابعة لطرف ثالث واجهة برمجة التطبيقات super-bad-for-performance document.write API، فإنها لن تحظر عرض الصفحة الرئيسية.
تحجيم جميع الموارد بشكل ثابت
يجب أن تعلن الموارد الخارجية مثل الصور والإعلانات وأُطُر 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-iframe-0.1.js"></script>
إبعاد لُغة JavaScript التابعة لطرف ثالث بالكامل عن المسار الحرج
تفضّل لُغة JS التابعة لطرف ثالث استخدام تحميل JS المتزامن. كما أنها تفضّل استخدام التعليمة البرمجية document.write لمزيد من نصوص المزامنة. على سبيل المثال، إذا كانت لديك خمسة إعلانات على صفحتك، وينتج عن كل منها ثلاث عمليات تحميل متزامنة، يستغرق كل منها ثانية واحدة كزمن استجابة للاتصال، فإن وقت التحميل يستغرق 15 ثانية لتحميل JS فقط.
تسمح صفحات AMP بلُغة JavaScript التابعة لطرف ثالث ولكنها تسمح بها فقط في أُطُر iframe المزوّدة بوضع الحماية. وبحصر هذه الصفحات على أُطُر iframe، فلا يمكنها حظر تنفيذ الصفحة الرئيسية. وحتى لو شغَّلَت عمليات إعادة حساب أنماط متعددة، فإن أُطُر iframe الصغيرة فيها تتضمن نموذج العناصر في المستند (DOM) الصغير جدًا.
يُحدَّد الوقت المستغرق في عمليات إعادة حساب الأنماط والتخطيطات بحجم DOM (نموذج العناصر في المستند)، لذا تكون عمليات إعادة حساب أُطُر iframe سريعة جدًا مقارنةً بإعادة حساب أنماط الصفحة وتخطيطها.
يجب أن تكون جميع نظم CSS مضمنة ومرتبطة بالحجم
تحظر لغة CSS عملية العرض بالكامل، وتحظر تحميل الصفحة، وتميل لأن تكون متكدّسة. في صفحات AMP HTML، يُسمح فقط بالأنماط المضمَّنة. وهذا يعمل على إزالة طلب واحد أو أكثر غالبًا من طلبات HTTP من مسار العرض الحرج مقارنةً بأغلب صفحات الويب.
علاوةً على ذلك، يبلغ أقصى حجم لورقة الأنماط المضمَّنة 50 كيلوبايت. وبينما يعدّ هذا الحجم كبيرًا بما يكفي للصفحات المتطورة للغاية، إلا أنه ما يزال يتطلب من مؤلف الصفحة ممارسة القواعد الجيدة لسلامة لغة CSS.
يجب أن يكون تشغيل الخطوط فعالاً
تكون خطوط الويب كبيرة جدًا، لذا يعتبر تحسين خطوط الويب عاملاً حاسمًا في جودة الأداء. على صفحة عادية بها القليل من نصوص المزامنة والقليل من أوراق الأنماط الخارجية، ينتظر المتصفح طويلاً قبل بدء تنزيل هذه الخطوط الضخمة حتى الانتهاء من كل ذلك.
لا يعلن نظام AMP عن أي طلبات HTTP حتى يبدأ تنزيل الخطوط. وهذا ممكن فقط لأن لغة JS بالكامل في AMP لها سمة عدم التزامن ولا يُسمح إلا بأوراق الأنماط المضمّنة فقط، ولا توجد أي طلبات HTTP تحظر تنزيل المتصفح للخطوط.
تقليل عمليات إعادة حساب الأنماط لأدنى حد
في كل مرة تقيس فيها شيئًا ما، فإنه يشغّل عمليات إعادة حساب أنماط مكلّفة لأنه يتعيّن على المتصفح العمل على تخطيط الصفحة بأكملها. في صفحات AMP، تحدث جميع عمليات قراءة DOM (نموذج العناصر في المستند) أولاً قبل عمليات الكتابة. وهذا يضمن تنفيذ الحد الأقصى لعملية إعادة حساب الأنماط الواحدة لكل إطار.
تعرّف على مزيد من المعلومات عن تأثير عمليات إعادة حساب الأنماط والتخطيطات على أداء العرض.
تشغيل الرسوم المتحركة المسرَّعة من خلال وحدة معالجة الرسومات (GPU) فقط
تعتبر الطريقة الوحيدة للحصول على تحسينات سريعة هي تشغيلها عبر وحدة معالجة الرسومات (GPU). حيث تعرف وحدة GPU كل ما يتعلق بالطبقات، وتعرف كيفية أداء بعض الأمور على هذه الطبقات، فيمكنها تحريكها، ويمكنها إخفاتها، ولكن لا يمكنها تحديث تخطيط الصفحة، بل توكِل تلك المهمة للمتصفح، وهذا ليس جيدًا.
تضمن قواعد لُغة CSS المرتبطة بالرسوم المتحركة تسريع الرسوم المتحركة من خلال وحدة معالجة الرسومات (GPU). وعلى وجه التحديد، يسمح AMP فقط بتحريك الرسوم والانتقال في التحويل والتعتيم لذا يصبح تخطيط تلك الصفحة غير مطلوب. تعرّف على مزيد من المعلومات عن استخدام التحويل والتعتيم لتغييرات الرسوم المتحركة.
وضع تحميل الموارد على رأس الأولويات
يتحكم AMP في جميع عمليات تنزيل الموارد: ويضع تحميل الموارد على رأس الأولويات، وذلك بتحميل ما هو مطلوب فقط، وينفّذ الجلب المسبق للموارد بطيئة التحميل.
عندما يبدأ AMP في تنزيل الموارد، فإنه يحسِّن عمليات التنزيل حتى يتم تنزيل الموارد الأكثر أهمية حاليًا أولًا. فلا يتم تنزيل الصور والإعلانات إلا إذا كان من المرجّح أن يشاهدها المستخدم، أو إذا كانت في الجزء المرئي من الصفحة، أو إذا كان من المرجّح أن يمرّر المستخدم الصفحة للوصول إليها بسرعة.
ينفّذ AMP أيضًا عملية الجلب المسبق للموارد بطيئة التحميل. إذ يجري تحميل الموارد على نحو متأخر قدر الإمكان، ولكن يتم جلبها مسبقًا بأسرع ما يمكن. وبتلك الكيفية، يتم تحميل الأشياء بسرعة كبيرة ولكن يتم استخدام وحدة المعالجة المركزية (CPU) فقط عند عرض الموارد فعليًا للمستخدمين.
تحميل الصفحات في لحظة
يجري استخدام واجهة برمجة تطبيقات الاتصال المسبق الجديدة بكثرة لضمان تنفيذ طلبات HTTP بأسرع ما يمكن عند تقديمها. وباستخدامها، يمكن عرض صفحة ما قبل أن يعلن المستخدم صراحةً أنه يود الانتقال إليها، وقد تكون الصفحة متاحة بالفعل في وقت اختيار المستخدم لها فعليًا، وهو ما يؤدي إلى التحميل الفوري.
بينما يمكن تطبيق العرض المسبق على كل محتوى الويب، إلا أنه يمكنه أيضًا استخدام الكثير من النطاق الترددي وCPU. وقد تم تحسين AMP لتقليل أثر كل من هذين العاملين. فالعرض المسبق يعمل فقط على تنزيل الموارد في الجزء المرئي من الصفحة ولا يعمل العرض المسبق على عرض الأشياء التي قد تكون مكلفة من ناحية استهلاك CPU.
عند العرض المسبق لمستندات AMP للتحميل الفوري، يتم فعليًا تنزيل الموارد في الجزء المرئي من الصفحة فقط. وعند إجراء العرض المسبق لمستندات AMP للتحميل الفوري، لا يتم تنزيل الموارد التي قد تستخدم الكثير من سعة CPU (مثل أُطُر iframe التابعة لطرف ثالث).
تعرّف على مزيد من المعلومات عن سبب عدم استغلال AMP HTML لفاحص التحميل المسبق.