كل ما تحتاج لمعرفته حول صفحات الجوال المعجلة من Google

في مايو 2015 ، كشف موقع Facebook عن منصته الجديدة للنشر داخل التطبيق ، مقالات فورية. بعد شهر ، أعلنت شركة Apple أن تجربة الصحف والمجلات القديمة (في الأساس عبارة عن مجلد فاخر مليء بتطبيقات الأخبار) سيتم استبدالها في نظام التشغيل iOS 9 بمنصة جديدة لتجميع الأخبار واكتشافها تسمى Apple News.

مزيد من القراءة عن التحطيم:

• أداء متوقع
• التحميل المسبق: ما فائدة ذلك؟
• الاستعداد لـ HTTP / 2
• تحسين تدريجي
• مضخمات ويب تقدمية

بعد أربعة أشهر ، جاء دور Google للإعلان عن خطتها الخاصة ، المتأخرة نوعًا ما ولكن ليس أقل طموحًا ، لإحداث ثورة في استهلاك أخبار الجوال من خلال حل مفتوح المصدر قائم على الويب يسمى Accelerated Mobile Pages أو AMP. في غضون بضعة أشهر فقط ، رأينا الهدوء النسبي للنشر الرقمي عبر الهاتف المحمول ينفجر في حرب أخرى واسعة النطاق مثل Facebook و Apple والآن Google تتنافس على ولاء الناشرين واهتمام القراء.

في حين أن Facebook و Apple لهما انطلاقة كبيرة على Google ، هناك كل الأسباب للاعتقاد بأن AMP ستلحق بالركب بسرعة (ويمكن حتى أن تتفوق على أحد منافسيها أو كليهما). إذا كنت مطورًا أو ناشرًا وتحتاج إلى معرفة سبب وكيفية استخدام Accelerated Mobile Pages من Google بأسرع ما يمكن وبكفاءة ، فأنت في المكان الصحيح.

لكن ما هي المشكلة؟

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

• تدخل طرف ثالث . لا تضيف الإعلانات وتقنيات التتبع ذات الصلة طلبات مجمعة وإضافية فقط إلى جهاز مقيَّد بالنطاق الترددي ووحدة المعالجة المركزية (CPU) ، ولكن غالبًا ما تتصرف الصفحات كما لو أنها تمتلكها لأنها تتقلب حول استدعاءات document.write() متعددة. أجرت New York Times مؤخرًا اختبارًا أظهر انخفاضًا كبيرًا في أحجام الصفحات وزيادة في عمر البطارية بعد تثبيت أداة حظر محتوى iOS.
• الأضرار الجانبية من التصميم سريع الاستجابة . في حين أن معظم مواقع الويب المصممة استجابة تبدو جيدة على الشاشات من جميع الأحجام ، فإنها غالبًا ما تحتوي على الكثير من أمتعة مواقع سطح المكتب عند عرضها على الهاتف المحمول. عندما أجرى Paul Irish تدقيقًا لأداء Reddit ، اكتشف أنه يمكن إرجاع قدر كبير من النفقات العامة إلى أصل يسمى SnooIcon ، وهو تعويذة Reddit تم تقديمها في SVG بحيث يمكن تحريكها (بواسطة مكتبة تابعة لجهة خارجية ، وهذا يعني المزيد من النفقات العامة) عند تمرير الماوس - ليس الموقف الذي تجد فيه الأصول نفسها بشكل متكرر على الأجهزة المحمولة.

أدخل مقالات Facebook الفورية وأخبار Apple وصفحات الجوال السريعة - منقذونا من عالم حيث ، وفقًا لـ Facebook (PDF ، 3.4 ميجا بايت) ، متوسط ​​وقت تحميل مقال على الأجهزة المحمولة هو 8 ثوانٍ. بينما من الواضح أن استدعاء 8 ثوانٍ إلى الأبد هو مبالغة ، نظرًا لأنه من الممكن أن تكون جيدًا في فيديو Vine الثاني الخاص بك في هذا الوقت من الوقت ، ربما يكون من العدل أن نقول إنه وفقًا لمعايير اليوم ، إنه على الأقل دهر.

عرض توضيحي قصير لمقالات Facebook الفورية وأخبار Apple وصفحات الجوال السريعة. لاحظ أن مقالات Facebook الفورية وأخبار Apple هي تجارب داخل التطبيق ، في حين أن AMP تعتمد بالكامل على المتصفح.

كيف تختلف AMP؟

بعض السياقات لكيفية اختلاف AMP عن مقالات Facebook الفورية و Apple News ستوضح بعض القرارات التي اتخذتها Google بشأن مبادرتها الجديدة للنشر الرقمي.

تشترك مقالات Facebook الفورية وأخبار Apple في العديد من الخصائص:

• الخبرات داخل التطبيق . يصل القراء إلى مقالات Facebook الفورية من خلال Facebook على الأجهزة المحمولة ، و Apple News هو تطبيق مستقل يأتي مع iOS 9. لا يسمح أي من النظامين للمستخدمين حاليًا بمشاهدة المقالات بتنسيقاتهم المحددة خارج التطبيق المعني. فكر في كليهما كتحديث خاص بالتطبيق لـ RSS.
• نقابية مدفوعة . بينما تستخدم مقالات Facebook الفورية وأخبار Apple تنسيقات مشاركة مختلفة جدًا (يعتمد تنسيق Apple News على JSON ، ويكون ترميز المقالة الفوري بتنسيق HTML ملفوفًا إلى حد ما في موجز RSS) ، إلا أنهما يعتمدان على مبادئ مماثلة: اقناع نظام إدارة المحتوى الخاص بك بإنشاء تنسيقات المشاركة الضرورية ، وسيقوم Facebook أو Apple News بإفسادها وتحليلها وجعلها جميلة وسريعة من خلال عارضين مخصصين ومحسنين.
• المنحى الخبرة . على الرغم من أن كلا من Facebook Instant Articles و Apple News يركزان على الأداء ، إلا أنهما مهتمان بنفس القدر بجعل المقالات تبدو عصرية. يحتوي كلا النظامين الأساسيين على مكونات تسمح بالتفاعلات السلسة والسلسة التي نربطها عادةً بتجارب القراءة المصممة يدويًا.

في المقابل ، فإن Accelerated Mobile Pages لها تركيز مميز:

• تجربة على شبكة الإنترنت . تم تصميم مستندات AMP ليتم عرضها إما في المتصفح أو في WebViews.
• الوثائق الذرية . على الرغم من التحقق من صحة مستندات AMP وتحليلها وعرضها جزئيًا بواسطة وقت تشغيل AMP (المزيد عن ذلك أدناه) ، إلا أنها مستندات كاملة ومستقلة تعيش على خادم الويب الخاص بك (واختيارياً ، في ذاكرة التخزين المؤقت لـ CDN) ، بدلاً من مجموعات من البيانات الوصفية التي سيتم تحويلها في مرحلة ما إلى مقالات وعرضها في التطبيقات.
• موجه للأداء . يهتم AMP بأداء مستندات AMP أكثر من اهتمامه بالجماليات أو أنماط التفاعل. هذا لا يعني أن مستندات AMP منزلية بطبيعتها (يمكن أن تكون جذابة تمامًا مثل مقالات Facebook الفورية أو مقالات Apple News مع التصميم الصحيح) ، ولكن وقت التشغيل يهتم بشكل أكبر بتقديم مقال بسرعة أكبر من توفير تأثيرات بصرية رائعة مثل أشياء صغيرة مجنونة jiggly.

ما هو AMP بالضبط؟

كفى فلسفة وتلويحا باليد على مستوى عال. دعنا ندخل في التفاصيل. بينما يعد التعرف على مقالات Facebook الفورية وأخبار Apple أمرًا سهلاً للغاية (إنهم في الأساس مجمعات أخبار رائعة مع أدوات عرض مخصصة مبنية على تنسيقات المشاركة المسجلة الملكية) ، فإن AMP هي الخارج. يصعب فهمه قليلاً لسببين:

• لا يوجد نموذج بسيط للمقارنة به. عندما كانت خدمة RSS جديدة ، تعجبنا جميعًا من قوتها ، وكتبنا عددًا لا يحصى من المقالات ومنشورات المدونات حول إمكاناتها التخريبية ، وأعلننا أن الصفحة الرئيسية قد ماتت (مرة أخرى) ، ثم شرعنا في نسيان كل شيء عنها. تعد مقالات Facebook الفورية وأخبار Apple في الأساس إعادة تشغيل RSS ، باستثناء أنها تستغني عن جميع مضايقات المعايير ، وكل منها يعمل في تطبيق واحد فقط.
• AMP ليس عميلاً. . بينما تحتوي مقالات Facebook الفورية و Apple News و AMP على العديد من العناصر المشتركة ، مثل تنسيقات المشاركة المملوكة وعارضين مخصصين ، فإن AMP هي الوحيدة التي لا تحتوي على عميل مخصص (بخلاف المتصفح). أكثر من إخوانه ، AMP عبارة عن مجموعة من المواصفات والاتفاقيات والتقنيات التي يمكن دمجها في حل ، بدلاً من أن تكون حلاً شاملاً (من الناشر إلى القارئ) في حد ذاته.

الآن بعد أن عرفنا التفكير في AMP كمجموعة من المكونات ، بدلاً من كعكة مخبوزة بالكامل ، دعنا ننظر إلى ماهية هذه المكونات الفردية:

• AMP HTML ،
• وقت تشغيل AMP ،
• ذاكرة التخزين المؤقت لصفحات AMP.

AMP HTML

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

نظرًا لأن AMP HTML مصمم لتحقيق الأداء الأمثل ، ولفهم قيمته وتقديرها ، نحتاج إلى فهم المشكلات التي يحلها. فيما يلي أهم ثلاثة أشياء تعيق تحميل صفحات الويب وعرضها على الأجهزة المحمولة:

• حجم الحمولة . لقد خدمنا تصميم الويب سريع الاستجابة جيدًا لأنه يسمح لنا بإنشاء موقع ويب واحد لكل جهاز وشاشة هناك. ولكن هذا يعني أيضًا في بعض الأحيان تقديم حمولات بحجم سطح المكتب (HTML و JavaScript و CSS والأصول) إلى الأجهزة المحمولة ذات النطاق الترددي الشديد والأجهزة المحمولة المقيدة بوحدة المعالجة المركزية. (أولئك الذين يفكرون في هواتفهم على أنها أجهزة كمبيوتر سطح مكتب صغيرة يمنحون أجهزة الهاتف المحمول الكثير من الائتمان. يحتوي جهاز iPhone 6s الخاص بك على 2 غيغابايت من ذاكرة الوصول العشوائي ، في حين أن الكمبيوتر المحمول الخاص بك يحتوي على 8 أو 16.)
• تحميل الموارد . لا يتم تحميل الموارد دائمًا بالترتيب الأمثل ، مما يعني أن النطاق الترددي ووحدة المعالجة المركزية وذاكرة الوصول العشوائي غالبًا ما تكون مخصصة للأصول التي قد لا يراها المستخدمون أبدًا. بالإضافة إلى ذلك ، لا تعلن الموارد في كثير من الأحيان عن عرضها وارتفاعاتها (خاصةً عند عرضها من خلال شبكات الإعلانات أو حقنها عبر استدعاءات document.write() ) ، والتي لا تؤدي فقط إلى تغيير حجم الصفحة لأن أبعاد الموارد يتم تحديدها بشكل بطيء ، بل تؤدي أيضًا إلى عدم ضرورة وعمليات إعادة حساب التخطيط باهظة الثمن. هذا ما يجعل صفحات الويب تقفز مثل القطط التي تبحث عن الليزر لأنها تظهر ببطء شديد.
• تنفيذ جافا سكريبت . لست على وشك التطرق إلى موضوع أداء JavaScript هنا ، ولكن غالبًا ما تتراكم مواقع الويب الحديثة بالميجابايت ، وبينما قد يتم تنفيذها دون أي زمن انتقال واضح على أجهزة كمبيوتر سطح المكتب ، لا يزال الهاتف المحمول بيئة مختلفة تمامًا ، حيث أعتقد يمكننا أن نتفق جميعًا ، من الأفضل الاحتفاظ بجافا سكريبت عند الحد الأدنى.

بالنظر إلى هذه العوائق الثلاثة أمام تجارب الويب السلسة على أجهزة الجوّال ، فإن AMP HTML موجود أساسًا لثلاثة أغراض:

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

علامات AMP HTML

فيما يلي قائمة بالعلامات المحظورة تمامًا في AMP HTML:

• script من الواضح أن هذا أمر كبير. سأقدم مزيدًا من التفاصيل حول موضع AMP في JavaScript أدناه ؛ في الوقت الحالي ، افترض فقط أن علامات script الوحيدة المتوفرة في مستندات AMP الخاصة بك هي تلك التي تقوم بتحميل وقت تشغيل AMP ، واختياريًا ، علامة للبيانات المرتبطة المستندة إلى JSON.
• base يبدو أن العلامة base محظورة بدافع من الحذر الشديد ، وقد ينتهي بها الأمر في القائمة البيضاء إذا اشتكى المجتمع. (أظن أنه لا أحد يهتم حقًا بطريقة أو بأخرى).
• frame frameset بالضبط استخدامًا جيدًا للعقارات المتنقلة على أي حال ، لذا فهو بئس المصير.
• object ، param ، applet embed للأسف ، لن تحتوي مستندات AMP على أي تطبيقات فلاش أو جافا. (كان هذا سخرية ، في حال لم يكن واضحًا تمامًا).
• عناصر form input (باستثناء علامة button ) من المحتمل أن يتم تنفيذ دعم النموذج في النهاية كمكونات مغلفة لأنها محدودة الاستخدام بدون برمجة نصية.

الآن ، إليك قائمة بالعلامات التي تحل محل نظيراتها في HTML من أجل تحسين تحميل الموارد وفرض أفضل ممارسات الأمان:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) يستبدل علامة img ويحسن تحميل الموارد من خلال مراعاة عوامل مثل موضع منفذ العرض وموارد النظام والاتصال.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) يستبدل علامة video HTML5 ، بحيث يمكن تحميل محتوى الفيديو ببطء (مع مراعاة إطار العرض).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) يستبدل علامة audio HTML5 بحيث يمكن تحميل المحتوى الصوتي ببطء (مع الأخذ في الاعتبار إطار العرض).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) تفرض علامة amp-iframe أفضل ممارسات الأمان من خلال القيام بأشياء مثل وضع الحماية افتراضيًا ووضع قيود على حيث قد تظهر إطارات iframe للتأكد من أنها لا تهيمن على مستند AMP.

أخيرًا ، إليك جميع العلامات التي يقدمها AMP HTML لإضافة وظائف أو تفاعل إلى مستنداتك ، دون مطالبتك بكتابة JavaScript:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) تسمح علامة amp-ad لوقت تشغيل AMP بإدارة تحميل الإعلانات تمامًا مثل جميع الموارد الأخرى المحملة خارجيًا (حاليًا ، يتم تحميل الإعلانات أخيرًا) ، وهو يضمن عدم إمكانية تنفيذ جافا سكريبت من شبكات الإعلانات داخل مستند AMP الأصلي أو تشغيل حسابات تخطيط غير ضرورية. (وداعا ، document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) يحزم إطار العمل المصغر هذا بيانات التحليلات ويرسلها إلى مزودي الطرف الثالث. اعتبارًا من اليوم ، يأتي دعم AMP من Adobe Analytics و Chartbeat و ClickTale و comScore و Google Analytics و Nielsen و Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) يستخدم هذا لتضمين إشارات الويب ، وهو يدعم الرموز المميزة لإرسال متغيرات العميل المتعددة إلى الخادم.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) يعرض هذا المكون المحسن الصور الفرعية في اتجاه أفقي تفاعلي.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) هذا يسمح للقراء بفتح الصور في عرض "lightbox" بملء الشاشة. وهو يدعم مواصفات كل من الصور المصغرة والحجم الكامل.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) يقوم هذا بتحميل صور GIF المتحركة ويوفر وظائف العنصر النائب التي تشتد الحاجة إليها.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) اضبط مهلة التحميل على الخطوط المخصصة ، وحدد الخطوط الاحتياطية في حالة عدم تحميل الخطوط المخصصة خلال الوقت المخصص .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) سيتم تلقائيًا تعيين حجم خط محسّن للنص داخل علامة amp-fit-text المساحة المتاحة. فكر في الأمر على أنه القليل من الاستجابة المعبأة مسبقًا.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) باستخدام علامة amp-list ، يمكنك تحميل بيانات JSON ديناميكية متكررة ثم عرضها باستخدام HTML قالب. (راجع علامة amp-mustache أدناه.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) يدعم هذا عرض نماذج Moustache HTML.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) إذا اخترت عدم استخدام ذاكرة التخزين المؤقت AMP (المزيد عن التخزين المؤقت أدناه) ، تقوم علامة amp-install-serviceworker بتحميل وتثبيت عامل خدمة للصفحة الحالية. عمال الخدمة بارعون ، لكن في رأيي من السابق لأوانه الاعتماد عليهم.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) كما هو متوقع ، هذا يدمج فيديو YouTube مع معرف الفيديو المحدد.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) تضمين التغريدات (بطاقات Twitter اختيارية).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) قم بتضمين صور Instagram.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) يقوم هذا المكون بتحميل وعرض مقاطع الفيديو (ومشغل الفيديو) من Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) قم بتضمين أداة Pinterest أو زر "Pin It" في مستند AMP الخاص بك.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) قم بتضمين فيديو Vine المحدد في مستند AMP الخاص بك.

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

تنسيق AMP HTML

يتم تصميم مستندات AMP باستخدام CSS القياسي ولا يختلف كثيرًا عن أسلوبك في تصميم المحتوى بالفعل. ومع ذلك ، ضع في اعتبارك عدة أشياء:

• يجب إجراء كافة الأنماط باستخدام ورقة أنماط مضمنة - لا توجد أوراق أنماط مرتبطة خارجيًا ولا توجد أنماط مضمنة على مستوى العنصر. (قد تتطلب ورقة الأنماط المرتبطة خارجيًا تنزيل مستند إضافي قبل حساب التخطيط ، وقد تؤدي أنماط مستوى العنصر المضمنة إلى زيادة حجم المستند.)
• الأنماط محدودة بـ 50 كيلوبايت. فلسفة Google هي أن 50 كيلوبايت كافية لمستند أو مقال جميل ولكنها ليست كافية لموقع ويب لطيف.
• يجب أن تحتوي ورقة الأنماط المضمنة على السمة amp-custom ( <style amp-custom> ).
• يُسمح بقواعد @ - @font-face (المزيد عن الخطوط أدناه) و @keyframes و @media .
• تحتوي بعض المحددات على قيود معروفة بأنها تتحدى الأداء ، مثل المحدد العام ( * ) والمحدد :not() .
• المؤهل !important تم حظره للتأكد من أن وقت تشغيل AMP له الكلمة الأخيرة في تحديد حجم العنصر.
• يتم تصميم مكونات AMP المخصصة مثل amp-carousel عن طريق تجاوز الفئات الافتراضية ، مثل .amp-carousel-button-prev ، أو باستخدام مجموعة محددة مسبقًا من خصائص CSS المخصصة ، مثل --arrow-color .
• يجب تحديد خصائص العرض والارتفاع والتخطيط لجميع الموارد التي يتم تحميلها خارجيًا (المزيد عن التخطيط أدناه) لتقليل عمليات إعادة حساب تخطيط DOM الباهظة الثمن.
• يُسمح بالانتقالات والرسوم المتحركة التي يمكن تسريعها باستخدام وحدة معالجة الرسومات (والتي لا تؤدي إلى عمليات إعادة الحساب). حاليًا ، opacity transform مدرجان في القائمة البيضاء.

للحصول على تفاصيل إضافية حول مستندات الأنماط ، راجع مواصفات AMP HTML.

الخطوط

يدعم AMP الخطوط المخصصة بسعادة ، مع بعض المؤهلات:

• يجب تحميل الخطوط بعلامة ارتباط أو قاعدة CSS @font-face . بمعنى آخر ، لا يمكنك تحميل الخطوط باستخدام JavaScript.
• يجب تقديم جميع الخطوط عبر HTTPS.
• يجب وضع موفري الخطوط في القائمة البيضاء. حاليًا ، الموفرون الوحيدون المدرجون في القائمة البيضاء هم fonts.googleapis.com و fast.fonts.net . ولكن ، نظرًا لمدى سرعة قيام الناشرين والمعلنين ومقدمي خدمات التحليلات بإضافة دعم لصفحات AMP ، أعتقد أن المزيد سيتبع ذلك قريبًا.
  

تخطيط

تم تصور نهج AMP في التخطيط حول هدفين رئيسيين:

• يجب أن يكون وقت التشغيل قادرًا على استنتاج حجم جميع الموارد التي تم تحميلها خارجيًا قبل تحميلها فعليًا ، بحيث يمكن حساب التخطيط النهائي في أسرع وقت ممكن. بمجرد حساب التخطيط ، يمكن عرض المقالة ويمكن للقراء البدء في التفاعل معها ، حتى إذا لم يكتمل تحميل الإعلانات والصور والصوت والفيديو. (ومع تحميل هذه الموارد ، سيتم عرضها بسلاسة ، دون تعطيل تجربة القراءة عن طريق تحديث تخطيط المستند.)
• يجب أن تكون مقالات AMP سريعة الاستجابة. كما يوحي الاسم "Accelerated Mobile Pages" ، فإن مستندات AMP مخصصة خصيصًا لأجهزة الجوال ؛ لذلك ، في هذا السياق ، لا تتضمن كلمة "مستجيبة" قرارات سطح المكتب. بدلاً من ذلك ، يجب أن تبدو مستندات AMP جيدة على جميع الأجهزة المحمولة ، بدءًا من آثار iPhone 4 القديمة الصغيرة التي لا يزال الناس يستخدمونها حتى أجهزة iPad Pro الضخمة نسبيًا.

يتم تحقيق الهدف السابق بشكل أساسي من خلال اشتراط أن تحتوي جميع الموارد المحملة خارجيًا على سمات width height (ويتم فرضها بشكل أكبر عن طريق الحد من البرامج النصية ، مما يضمن عدم إمكانية استخدام الموارد الجديدة). يتم تحقيق هذا الأخير من خلال استعلامات الوسائط القياسية ، وسمة media ، sizes ، وسمة layout الخاصة بـ AMP.

فيما يلي نظرة عامة على التنسيقات التي تدعمها AMP حاليًا:

• nodisplay لا يتم عرض العنصر في البداية ، ولكن يمكن تشغيل العرض من خلال إجراء المستخدم. (يستخدم هذا مع مكونات مثل amp-lightbox .)
• fixed يحتوي العنصر على عرض وارتفاع ثابتين ، مما يعني أن وقت التشغيل لا يمكنه تطبيق أي سلوك متجاوب.
• responsive في رأيي ، هذا هو الأكثر فائدة وسحرًا من خيارات تخطيط AMP. يستخدم العنصر أي مساحة مخصصة مع الحفاظ على نسبة العرض إلى الارتفاع الخاصة به. (في الأساس ، "اجعل هذا الشيء يبدو جيدًا في أي قرار ، من فضلك وشكرًا.")
• fixed-height يستخدم العنصر المساحة المخصصة ولكنه يحافظ على ارتفاع ثابت (القياس أفقيًا).
• fill العنصر يملأ الحاوية دون النظر إلى نسبة العرض إلى الارتفاع. (فكر في width: 100% height: 100% .)
• container العنصر عبارة عن حاوية ، وبالتالي ، يتيح لأبنائه (على عكس العنصر الرئيسي) تحديد حجمه ، تمامًا مثل عنصر div القياسي.

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

ماذا عن SVG؟

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

فلسفة AMP في JavaScript

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

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

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

• لا يتم دعم أو السماح باستخدام JavaScript مكتوب من قبل المستخدم في الوقت الحالي. قد يكون لديك نوعان فقط من علامات النص البرمجي في مستندات AMP: علامات البيانات المرتبطة (نوع application/ld+json ) وعلامات لتضمين كل من وقت تشغيل AMP ومكونات AMP الموسعة.
• توقع مؤلفو مشروع AMP معظم احتياجات JavaScript في سياق استهلاك مقالة الجوال ، ولذا فإن AMP إما يدعم البدائل ( amp-pixel ، بما في ذلك الخطوط المخصصة بعلامات الارتباط أو @font-face rules ، إلخ) أو يوفر تطبيقات متوافقة مع وقت تشغيل AMP وبالتالي يضمن الأمان والأداء ( amp-ad و amp-analytics و amp-carousel وما إلى ذلك).
• إذا كان عليك حقًا استخدام JavaScript لشيء مثل ميزة تفاعلية ، فيمكنك إنشاء الميزة بشكل مستقل ثم تضمينها مع [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . يُسمح للمحتوى المضمن في amp-iframe بالاتصال المحدود بالمستند الأصلي لأشياء مثل طلبات تغيير الحجم.
• مكونات AMP مفتوحة المصدر (Apache 2) ومفتوحة للمساهمات ، لذلك ستظهر مكونات جديدة بمرور الوقت (في الواقع ، ظهرت العديد من المكونات الجديدة على مدار كتابة هذه المقالة وتحريرها ، لذلك قمت بالفعل بالتحديث عدة مرات). بينما سيعطي فريق AMP الأولوية للمكونات المعممة على الوظائف الخاصة بالخدمة (عنصر واجهة مستخدم مخصص لبدء التشغيل الاجتماعي ، على سبيل المثال) ، فإنه ملتزم أيضًا بتوفير تنوع كافٍ لاستيعاب أكبر نطاق ممكن من المحتوى.
• أخيرًا ، كل هذه السياسات عرضة للتغيير. نظرًا لأن ميزات المستعرض مثل العاملين على الويب والعناصر المخصصة و shadow DOM أصبحت مدعومة على نطاق واسع ، فإن خيارات دعم JavaScript المكتوبة من قبل المستخدم والمكونات المخصصة - مع استمرار ضمان الأمان والأداء - ستتوسع بشكل كبير.

لمزيد من المعلومات حول مستقبل مكونات AMP ، راجع قسم "المكونات الموسعة" لمواصفات "مكونات AMP HTML".

تشريح مستند AMP

الآن بعد أن أصبح لديك فهم قوي لـ AMP HTML ، دعنا نقسم النموذج المعياري.

بالطبع ، ستبدأ مستندات doctype بإقرار نوع المستند:

 <!doctype html>

بعد ذلك ، عيّن مستند HTML الخاص بك على أنه AMP HTML ، والذي ، صدق أو لا تصدق ، أنت تستخدم الرموز التعبيرية عالية الجهد كسمة في علامة html :

 <html >

أو ، إذا كنت متشددًا من الطراز القديم وتشعر بالخشونة في فكرة تزيين شفرتك برموز تعبيرية رائعة ، فيمكنك استخدام سمة amp الأكثر تحفظًا ، بدلاً من ذلك:

 <html amp> <!-- A good sign that you're boring! -->

في علامة head ، لا تنس تعليمات تشفير الأحرف utf-8 :

 <meta charset="utf-8">

واربطه بإصدار غير AMP من المستند (تم تمييزه على أنه canonical ، بحيث لا يظهر كمحتوى مكرر):

 <link rel="canonical" href="my-non-amp-index.html">

على العكس من ذلك ، يجب أن يحتوي الإصدار الذي تستخدمه بخلاف AMP على مرجع إلى مستند AMPlified:

 <link rel="amphtml" href="my-amp-index.html">

نظرًا لأن صفحات AMP مخصصة للأجهزة المحمولة (وتريد أيضًا تحويل GPU إلى نقطية) ، تأكد من تضمين علامة meta viewport :

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

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

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

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

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

الشيء التالي الذي يجب فعله هو تضمين وقت تشغيل جافا سكريبت AMP:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

وقم بتضمين تطبيقات JavaScript لأي مكونات موسعة تحتاجها:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(لاحظ استخدام السمة غير async . هذا ليس اختياريًا - فكلما قل الحظر ، كان ذلك أفضل.)

اختياريًا ، يمكنك رش القليل من البيانات المرتبطة ، مثل هذا:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

دعنا الآن نضيف بعض الخطوط ، إما باستخدام علامات link أو قواعد @font-face في CSS الخاص بك:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

وبعد ذلك سنقوم ببعض الأنماط (لا تزيد قيمتها عن 50 كيلوبايت) ، مع سمة amp-custom المطلوبة:

 <style amp-custom>

أنت الآن جاهز لإنشاء مستند HTML قياسي إلى حد ما باستخدام كل ما تعلمته للتو عن AMP HTML.

وقت تشغيل AMP

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

يتم تنفيذ وقت تشغيل AMP بالكامل في JavaScript ويتم بدؤه من خلال تضمينه في مستند AMP ، كما تفعل مع أي ملف JavaScript خارجي:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

من هناك ، يقوم وقت تشغيل AMP في الأساس بثلاثة أشياء:

• يدير تحميل الموارد وتحديد الأولويات ،
• تنفذ مكونات AMP ،
• اختياريًا ، يتضمن أداة التحقق من وقت التشغيل لـ AMP HTML.

المدقق أمر بالغ الأهمية لتأليف المستندات المتوافقة مع AMP. يمكن تشغيله ببساطة عن طريق إلحاق #development=1 بعنوان URL الخاص بالمستند. بعد ذلك ، كل ما عليك فعله هو فتح وحدة التحكم الخاصة بك لرؤية بطاقة التقرير الخاصة بك.

تبدو الأخطاء كما يلي:

يبدو مستند AMP اللطيف والنظيف والمتوافق كما يلي:

ذاكرة التخزين المؤقت لصفحات AMP (الاختيارية)

يمكن تقديم مستندات AMP من خادم ويب مثل أي مستند HTML آخر ، ولكن يمكن أيضًا عرضها من ذاكرة تخزين مؤقت لصفحات AMP خاصة. تستخدم ذاكرة التخزين المؤقت الاختيارية عدة تقنيات لتحسين مستند AMP بشكل أكبر:

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

يمكن لأي شخص تشغيل ذاكرة التخزين المؤقت AMP الخاصة به على CDN الخاص به ، أو يمكن للناشرين استخدام Google مجانًا. نظرًا لأن Google يبدو أنها تعرف شيئًا أو شيئين عن قابلية التوسع ، فأنا أعتقد أن معظم مستخدمي AMP سيكونون سعداء بقبول هذا العرض. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

مصادر إضافية

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11