AMP یا «صفحات موبایل سریع» پروژه‌ای است که توسط شرکت گوگل و باهدف بالا بردن سرعت وب‌گردی از طریق موبایل پایه‌گذاری گردیده است. آنچه در ادامه مطالعه خواهید کرد، دلایل سرعت‌بالای اجرای صفحات AMP هستند.

اجازه اجرا تنها به اسکریپت‌های asynchronous (غیر هم‌زمان)

جاوا اسکریپت قدرتمند است و توانایی ویرایش تقریباً هر چیزی در صفحه را دارد.

اما همچنین می‌تواند ساختار DOM را مسدود کرده و رندرینگ صفحه را با تأخیر مواجه سازد. برای جلوگیری از این مشکل، گوگل AMP فقط به asynchronous JavaScript اجازه اجرا می‌دهد.

صفحات AMP نمی‌توانند هیچ جاوا اسکریپت دست‌نوشته‌ای را شامل شوند. بجای استفاده از جاوا اسکریپت، ویژگی‌های تعاملی صفحه توسط اجزای مخصوص AMP مدیریت می‌شوند.

اجزای مخصوص AMP شاید در پشت‌صحنه از جاوا اسکریپت هم استفاده کنند، اما با دقت بالا و طوری طراحی‌شده‌اند که هیچ ضعفی در عملکرد از خود نشان ندهند.

بااینکه جاوا اسکریپت‌های third-party در iframe ها قابل‌استفاده هستند، اجازه مسدودسازی در رندرینگ را ندارند.

به‌عنوان‌مثال، اگر جاوا اسکریپت ثالثی اقدام به استفاده از API بسیار بد بکند، عملیات رندر شدن صفحه‌ی اصلی را مختل نخواهد کرد.

مشخص بودن اندازه‌ی همه منابع مورداستفاده در AMP

منابع خارجی همچون تصاویر، تبلیغات یا آی فریم‌ها باید اندازه‌ی خود را در HTML اعلام کنند تا AMP بتواند در مورد سایز و موقعیت هر جزء از صفحه، قبل از بارگیری آن، تصمیم‌گیری کند.

AMP ساختار کلی صفحه را بدون معطل شدن برای بارگیری همه اجزای آن اجرا می‌کند.

AMP ساختار صفحات را از ساختار منابع مورداستفاده جدا می‌کند. فقط یک درخواست HTTP برای اجرای ساختار کل صفحه نیاز است.

ازآنجاکه AMP برای جلوگیری از محاسبات مجدد و هزینه‌برِ استایل‌ها و ساختارها در مرورگر، بهینه‌سازی شده است، هیچ اجرای مجدد ساختاری درزمانی که منابع بارگیری می‌شوند نخواهیم داشت.

جلوگیری از مسدود کردن رندرینگ توسط افزونه‌ها

AMP به افزونه‌ها اجازه‌ی جلوگیری از رندر شدن صفحه را نمی‌دهد. AMP از افزونه‌هایی همچون لایت باکس‌ها، پست‌های اینستاگرام و توییت‌ها و … پشتیبانی می‌کند. بااینکه این‌ها نیازمند درخواست‌های HTTP اضافی هستند، این درخواست‌ها روند اجرای ساختار و صفحه را مسدود نمی‌کنند.

هر صفحه‌ای که از یک اسکریپت دست‌نوشته استفاده می‌کند، باید به سیستم AMP اعلام نماید که درنهایت یک برچسب مخصوص خواهد داشت. مثلاً amp-iframe به سیستم می‌گوید که قرار است یک برچسب amp-iframe وجود داشته باشد و AMP جعبه‌ی آی فریم را قبل از اینکه حتی بداند قرار است چه چیزی را شامل شود، ایجاد می‌کند:

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

خارج کردن جاوا اسکریپت‌های ثالث از مسیرهای حیاتی

جاوا اسکریپت ثالث دوست دارد از اجرای هم‌زمان یا synchronous استفاده کند. آن‌ها همچنین علاقه‌مند به document.write کردن اسکریپت‌های همگام‌سازی هستند. به‌عنوان‌مثال، اگر شما ۵ تبلیغ روی صفحه دارید و هرکدام از آن‌ها سه اجرای هم‌زمان داشته باشد، هر یک با ۱ ثانیه تأخیر در اتصال، درنهایت ۱۸ ثانیه برای اجرای جاوا اسکریپت تأخیر خواهید داشت.
صفحات AMP به جاوا اسکریپت‌های ثالث مجوز می‌دهند، اما فقط در آی فریم‌ها. با محدود کردن آن‌ها به iframe ها، دیگر قادر به مسدودسازی اجرای صفحه اصلی نخواهند بود. حتی اگر چندین محاسبه مجدد مربوط به استایل را فراخوانی کنند، آی فریم‌های کوچکشان DOM بسیار کمی خواهند داشت.
مقدار زمانی که محاسبات مجدد استایل و ساختارها نیاز دارند، توسط سایز DOM محدود می‌گردد، درنتیجه این محاسبات در مقایسه با محاسباتی که در صفحه اصلی انجام می‌گیرد بسیار سریع خواهند بود.

تمام css‌ها باید محدود به‌اندازه و درون‌خطی باشند

CSS باعث توقف رندر و اجرای صفحه می‌شود و معمولاً حجم زیادی نیز دارد. در صفحات اچ‌تی‌اِم‌اِل AMP فقط CSS های درون‌خطی مجاز هستند. این کار باعث حذف ۱ و اغلب بیش از ۱ درخواست HTTP از مسیر حیاتی رندر نسبت به اکثر صفحات وب می‌شود.
همچنین، کدهای درون‌خطی CSS حداکثر می‌تواند ۵۰ کیلوبایت باشد. اگرچه این سایز به‌اندازه کافی برای صفحات پیچیده، بزرگ است، اما همچنان سازنده صفحه را مجبور به نوشتن CSS بهینه می‌کند.

صفحات را در چشم برهم زدنی اجرا کنید

صفحات را در چشم برهم زدنی اجرا کنید

فراخوانی فونت‌ها باید کارآمد باشد

فونت‌های وب خیلی حجیم هستند و بهینه‌سازی فونت‌ها برای عملکرد بهتر ضروری است. در یک صفحه‌ی معمولی که تعداد اندکی اسکریپت و CSS های خارجی دارد، مرورگر مجبور است صبر کند تا این فونت‌های پرحجم دانلود شده و سپس باقی موارد اجرا گردند.

سیستم AMP تا زمان شروع بارگیری فونت‌ها، هیچ درخواست HTTP ندارد. این تنها به این خاطر ممکن شده است که تمام جاوا اسکریپت در AMP از حالت async استفاده کرده و فقط CSS های درون‌خطی مجاز هستند؛ پس هیچ درخواست HTTP برای توقف مرورگر از بارگیری فونت‌ها وجود ندارد.

کمینه سازی محاسبات مجدد استایل‌ها

هر بار که چیزی را اندازه می‌گیرید، محاسبه‌ی مجدد استایل را فراخوانی می‌کنید؛ که هزینه بر است. چراکه مرورگر مجبور است دوباره تمام صفحه را ساختاربندی کند. در صفحات AMP، تمام «خواندن» های DOM قبل از تمام «نوشتن» ها اتفاق می‌افتد. این باعث می‌گردد حداکثر یک‌بار محاسبه مجدد در هر فریم برای استایل داشته باشیم.

تنها تصاویری اجرا می‌شوند که برای پردازش گرافیکی بهینه‌شده‌اند

تنها راه برای داشتن بهینه‌سازی سریع، اجرای این تصاویر روی GPU است. GPU در مورد لایه‌ها اطلاع دارد و می‌داند چگونه بعضی چیزها را روی این لایه‌ها اجرا کند، جابجا کند یا محو کند، اما نمی‌تواند ساختار صفحه را به‌روزرسانی نماید؛ درنتیجه این به‌روزرسانی را به مرورگر می‌سپارد و این خوب نیست.

قواعد CSS مربوط به تصاویر متحرک اطمینان حاصل می‌کند که آیا تصاویر می‌توانند برای پردازش گرافیکی سریع بهینه باشند یا خیر. به‌صورت مخصوص، AMP فقط به تصاویر اجازه‌ی حرکت یا جابجایی یا تغییر در میزان نور را می‌دهد تا به ساختار صفحه نیازی نباشد.

اولویت‌بندی فراخوانی منابع

AMP بارگیری تمام منابع را کنترل می‌کند: اجرای این منابع اولویت‌بندی می‌شود، به این صورت که فقط چیزهایی که لازم هستند اجراشده و سپس موارد سنگین‌تر شروع به بارگیری در خفا می‌شوند.

AMP منابع را بهینه دانلود می‌نماید. درنتیجه مهم‌ترین منابع اول‌ازهمه دریافت می‌شوند. تصاویر و تبلیغات تنها در صورتی بارگیری می‌شوند که قرار باشد توسط کاربر دیده شوند، یا بخواهد سریعاً برای دیدن آن‌ها به بالا یا پایین صفحه اسکرول کند.

AMP همچنین منابع سنگین را در پشت‌صحنه دریافت می‌کند. این کار در آخرین مرحله اما با بهترین سرعت انجام می‌شود. از این طریق لودینگ بسیار سریع صورت می‌گیرد اما CPU تنها زمانی درگیر می‌شود که منابع به کاربر نمایش داده شوند.

 

صفحات را در چشم برهم زدنی اجرا کنید

یک API جدید بنام preconnect برای تضمین حداکثر سرعت درخواست‌های HTTP در زمان فراخوانی، استفاده می‌گردد.

با این ابزار، صفحه قبل از اینکه کاربر اعلام کند می‌خواهد آن را مرور کند، اجرا می‌شود؛ و قبل از اینکه کاربر صفحه را انتخاب کند، آن صفحه در دسترس است. این موضوع باعث می‌شود کاربر صفحه را در چشم برهم زدنی مشاهده کند.

همان‌طور که بارگیری قبل از اجرا می‌تواند برای تمام محتوای وب بکار گرفته شود، همچنین می‌تواند CPU و پهنای باند بسیاری نیز مصرف کند.

AMP برای کاهش این دو مورد بهینه‌سازی شده است و تنها منابعی را دانلود می‌کند که احتمال بیشتری برای دیده شدن توسط کاربر رادارند.