بخش های اصلی

آموزش AMP

آموزش AMP - AMP چگونه کار می کند؟

 ترکیب های بهینه سازی زیر دلیل سریع بودن بارگزاری صفحه هایِ AMP هستن:

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

جاوا اسکریپت بسیار قدرتمندِه و تقریباً توانایی تغییر همه ی جنبه های صفحه را داره، ولی ممکنِه ساختارِ DOM را بلاک کنه و  رندِر صفحه را به تأخیر بندازه (برای اطلاعات بیش تر قسمت اضافه کردن قابلیت تعاملی با جاوا اسکریپت را هم بخوانید). AMP برای این که از به تأخیر افتادن رِندِر صفحه ها توسط جاوا اسکریپت جلوگیری کنه، فقط به جاوا اسکریپتِ ناهمگام مجوز میده.

صفحه های AMP، جاوا اسکریپتی که توسط نویسنده (author-written) نوشته شده باشه را ندارن. ویژگی های تعاملی صفحه به جای این که توسط جاوا اسکریپت هَندِل بشن، توسط عناصر سفارشیِ AMP هَندِل میشن. عناصر سفارشیِ AMP ممکنه حاوی جاوا اسکریپت تحتِ hood باشن، با این وجود طوری با دقت طراحی شدن که کارایی را کاهش ندن.

با این که third-party JS قابلیت استفاده در iframeها را داره، ولی قابلیت بلاک کردن عملیات رِندِرینگ را نداره. برای مثال، اگه third-party JS از document.write API با کارایی بسیار پایین استفاده کنه، عملیات رِندِرینگِ صفحه ی اصلی را بلاک نمی کنه.

تعیین سایزِ همه ی منابع آماری

منابع خارجی مثل عکس ها، تبلیغات ها یا iframeها باید سایزشان را با فرمت HTML مشخص کنن؛ AMP سایز و مکان هر یک از عناصر را قبل از دانلود شدن منابع، مشخص می کنه. AMP بدون این که منتظر دانلود منابع بماند، پیش نمایش صفحات را بارگذاری می کنه.

AMP پیش نمایش سند را از پیش نمایش منبع جدا می کنه. برای پیش نمایش کل صفحه فقط نیاز به یک درخواستِ HTTP هست (+فونت ها). از آن جایی که AMP جهت پیشگیری از محاسبات سنگین استایل ها و پیش نمایش ها در مرورگر،  بهینه سازی شده، بعد از بارگذاری منابع هرگز پیش نمایشِ مجددی وجود نخواهد داشت.

به مکانیزم های اسکتنشن (extention) ، اجازه ی بلاک کردن عملیات رِندِرینگ داده نمیشه

AMP به مکانیزم های اسکتنشن (extention) اجازه ی بلاک کردن رِندِرِ صفحه ها را نمیده. AMP از اکستشن ها برای چیزهایی مثلِ lightboxes instagram embeds, tweets, و ... پشتیبانی میکنه؛ وقتی این ها نیاز به درخواست های اضافیِ HTTP داشته باشن، درخواست ها، پیش نمایش صفحات و عمیات رِندِر را بلاک نمی کنن.

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

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

تمامِ third-party JavaScript را خارج از مسیر بحرانی نگه میداره

third-party JS تمایل به استفاده از بارگزاری همگامِ JS داره. همچنین تمایل به استفاده از اسکریپت های همگام تری مثلِ document.write هم داره. برای مثال، اگه در صفحه چهار عدد تبلیغات داشته باشین، و هر یک از این تبلیغات ها سه بارگذاری همگام ایجاد کنن که هر کدام یک ثانیه تأخیر در اتصال داشته باشن، باید فقط برای بارگذاری JS، 15 ثانیه صبر کنین.

صفحه های AMP فقط در iframeهایِ sendboxed مجوز استفاده از third-party JavaScript را میدن. با محدود کردن third-party JavaScript به جاوا اسکریپت دیگه اجرای صفحه ها بلاک نمیشن. حتی اگه محاسبات مجدد استایل هم اجرا بشه، iframeهای کوچک، DOM بسیار کوچکی خواهند داشت.

زمان انجام محاسبات مجدد استایل ها و پیش نمایش ها بر اساس سایزِ DOM محدود میشه، بنابراین محاسبات مجددِ iframe در مقایسه با محاسبات مجدد استایل ها و پیش نمایش های صفحه، بسیار سریع تر انجام میشه.

همه ی CSSها باید درون خطی باشن و سایزِ محدودی داشته باشن

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

همجنین، حداکثر سایزِ style sheetهای داخلی 50 کیلوبایتِه. با این که این سایز برای هر نوع صفحه ی پیچیده ای کافی به نظر میرسه هنوز هم برای مرتب نگه داشتن CSSها به نویسنده ی صفحه نیاز هست.

اجرای فونت ها باید مؤثر باشه

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

سیستمِ AMP، تا زمانی که دانلود فونت ها شروع بشه، درخواست هایِ zero HTTP را اعلان می کنه. این امر تنها به این خاطر امکان پذیره که همه ی JSها در AMP خصیصه ی (attribute) همگام دارن و فقط style sheetهای داخلی اجازه دارن که استفاده بشن؛ هیچ درخواستِ HTTPای عملیات دانلود فونت ها توسط مرورگر را بلاک نمیکنه.

به حداقل رساندن محاسبات مجدد استایل

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

برای کسب اطلاعات بیش تر راجع به محاسبات مجدد استایل و پیش نمایش به عملکرد و کارایی عملیات رندر مراجعه کنین.

فقط انیمیشن های پرشتابِ-GPU اجرا میشن

تنها راه سریع شدن بهینه سازی ها، اجرای آن ها در GPU است. GPU لایه ها را می شناسد، نحوه ی اجرای چیزها را روی لایه ها میداند، می تواند حرکت شان بده و محوشان (fade) کنه ولی نمی تواند پیش نمایش صفحه را به روز رسانی کنه؛ GPU وظایف را به مرورگر تحویل میده که این کار اصلاً خوب نیست.

قوانین انیمیشنی مرتبط با CSS تضمین می کنن که انیمیشن ها GPU-شتاب باشن. AMP فقط به حالت هایِ transform و opacity اجازه ی متحرک شدن میدن بنابراین نیازی به پیش نمایش صفحه نیست. برای کسب اطلاعات بیش تر به قسمت استفاده از transform و opacity برای تغییرات انیمیشنی مراجعه کنین.

اولویت بندی بارگذاری منابع

AMP تمام منابع دانلودها را کنترل می کنه: بارگذاری منابع را اولویت بندی می کنه، فقط چیزهایی که مورد نیاز هستن را بارگذاری می کنه و منابعی که بارگذاری آن ها طول کشیده را دوباره واکشی می کنه.

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

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

بارگذاری فوری صفحه ها

API از پیش متصل شده ی (preconnected) جدید، برای تضمین ایجاد درخواست های HTTP با سریع ترین سرعت ممکن، به شدت به کار میره. در این صورت صفحه قبل از این که مستقیماً بگه که میخواد به اون صفحه بره، رِندِر میشه؛ وقتی کاربر صفحه را انتخاب می کنه، صفحه از قبل موجود باشه، این امر باعث بارگذاری فوری صفحه میشه.

با این که پیش رِندِر روی تمام محتوای وب قابل اعمالِه، ممکنِه پهنای باند و CPU زیادی استفاده کنه. AMP برای کاهش میزان استفاده از این دو فاکتور، بهینه سازی شده. پیش رِندِر فقط منابع بالایِ fold را دانلود می کنه و چیزهایی که ممکنه برای CPU سنگین باشن را دانلود نمی کنه.

وقتی سندهایِ AMP به منظور بارگذاری فوری، پیش رِندِر می شن، فقط منابع بالایِ fold دانلود میشن. وقتی سندهایِ AMP به منظور بارگذاری فوری، پیش رِندِر می شن، منابعی که احتمال داره میزان استفاده شان از CPU زیاد باشه (مثلِ third-party iframeها) دانلود نمی شن.

سریع تر کردنِ AMP

برای کسب اطلاعات بیش تر به قمست چرا AMP HTML تمام مزایایِ پویشگر پیش بارگذاری را نداره، مراجعه کنین.

در صورتی که سوال و یا نظری دارید، از بخش نظرات با ما در میان بگذارید.

خبـرنــامه

Newsletters

در خبــرنـامه سافت اسکیل عضو شویــد تا جدیدترین هـای سایت را بلافاصله در ایمیل خـود دریافت کنیـد

شما چه نظر و یا سوالی درباره این نوشته دارید؟

مبحث آموزشی

آموزش AMP

Learn Accelerated Mobile Pages

پرســیدن سؤال جدید

سؤال های تخصصی خود را از ما بپرسید

تبلیغات

دنبال کردن تلگرام کانال سافت اسکیل

https://telegram.me/softskill_ir

عملیات کاربران

خبـرنــامه

Newsletters

در خبــرنـامه سافت اسکیل عضو شویــد تا جدیدترین هـای سایت را بلافاصله در ایمیل خـود دریافت کنیـد