PageSpeed Insights یک صفحه را تجزیه و تحلیل می‌کند تا ببیند آیا از توصیه‌های ما برای رندر کردن صفحه در کمتر از یک ثانیه در شبکه تلفن همراه پیروی می‌کند یا خیر. تحقیقات نشان داده است که تاخیر بیش از یک ثانیه باعث می شود کاربر جریان فکر خود را قطع کند و تجربه ضعیفی ایجاد کند. هدف ما این است که کاربر را با صفحه درگیر نگه داریم و تجربه بهینه را بدون توجه به دستگاه یا نوع شبکه ارائه دهیم.
برآورده کردن بودجه بار دوم آسان نیست. خوشبختانه برای ما، کل صفحه مجبور نیست با این بودجه رندر شود، در عوض ، ما باید محتوای بالا (ATF) را در کمتر از یک ثانیه تحویل و رندر کنیم، که به کاربر اجازه می‌دهد تا در اسرع وقت با صفحه ارتباط برقرار کند. ممکن . سپس، در حالی که کاربر در حال تفسیر صفحه اول محتوا است، بقیه صفحه می تواند به تدریج در پس زمینه ارائه شود.
سازگاری با شبکه های تلفن همراه با تاخیر بالا
رعایت معیارهای ATF یک ثانیه ای در دستگاه های تلفن همراه چالش های منحصر به فردی را ایجاد می کند که در شبکه های دیگر وجود ندارد. کاربران ممکن است از طریق انواع شبکه های مختلف 2G، 3G و 4G به سایت شما دسترسی داشته باشند. تأخیر شبکه به طور قابل توجهی بیشتر از اتصال سیمی است و بخش قابل توجهی از بودجه 1000 میلی‌ثانیه ما را برای ارائه محتوای ATF مصرف می‌کند.
4G نوع شبکه غالب در سراسر جهان است، باید انتظار داشته باشید که اکثر کاربران به صفحه شما در شبکه 4G دسترسی داشته باشند. به همین دلیل، باید فرض کنیم که هر درخواست شبکه به طور متوسط 100 میلی ثانیه طول می کشد.
با در نظر گرفتن این موضوع، اکنون به عقب کار می کنیم. اگر به یک توالی ارتباط معمولی بین یک مرورگر و یک سرور نگاه کنیم، 300 میلی‌ثانیه از آن زمان قبلاً توسط سربار شبکه مصرف شده است: جستجوی DNS برای حل نام میزبان (به عنوان مثال google.com) به یک آدرس IP، یک شبکه رفت و برگشت برای انجام دست دادن TCP و یک اتصال TLS اختیاری. این برای ما 700 میلی ثانیه باقی می گذارد.
ارائه تجربه رندر زیر یک ثانیه
پس از کم کردن تأخیر شبکه، تنها 700 میلی ثانیه در بودجه ما باقی می‌ماند، و هنوز کار زیادی برای انجام دادن وجود دارد: سرور باید پاسخ را ارائه کند، کد برنامه سمت کلاینت باید اجرا شود، و مرورگر باید طرح‌بندی و ارائه را ارائه کند. محتوا. با در نظر گرفتن این موضوع، معیارهای زیر باید به ما کمک کنند تا در بودجه باقی بمانیم:
- (1) سرور باید پاسخ را ارائه دهد (< 200 ms)
- زمان پاسخگویی سرور، زمانی است که سرور برای برگرداندن HTML اولیه، با فاکتورگیری زمان انتقال شبکه، طول می کشد. از آنجایی که ما زمان بسیار کمی داریم، این زمان باید به حداقل برسد - در حالت ایده آل در 200 میلی ثانیه، و ترجیحاً حتی کمتر!
- (2) تعداد تغییر مسیرها باید به حداقل برسد
- تغییر مسیرهای HTTP اضافی می تواند یک یا دو رفت و برگشت اضافی به شبکه اضافه کند (دو بار در صورت نیاز به جستجوی DNS اضافی)، که صدها میلی ثانیه تاخیر اضافی را در شبکه های 4G متحمل می شود. به همین دلیل، ما قویاً مدیران وب‌سایت‌ها را تشویق می‌کنیم که تعداد را به حداقل برسانند، و در حالت ایده‌آل، تغییر مسیرها را به طور کامل حذف کنند - این به ویژه برای سند HTML مهم است (در صورت امکان از تغییر مسیرهای «m dot» اجتناب کنید).
- (3) تعداد رفت و برگشت تا اولین رندر باید به حداقل برسد
با توجه به اینکه TCP چگونه ظرفیت یک اتصال را تخمین می زند (یعنی شروع آهسته TCP )، یک اتصال TCP جدید نمی تواند بلافاصله از پهنای باند کامل موجود بین مشتری و سرور استفاده کند. به همین دلیل، سرور می تواند تا 10 بسته TCP را در یک اتصال جدید (~ 14 کیلوبایت) در اولین رفت و برگشت ارسال کند، و سپس باید منتظر بماند تا مشتری این داده ها را تأیید کند تا بتواند پنجره تراکم خود را افزایش دهد و به تحویل داده های بیشتر ادامه دهد.
همچنین، مهم است که توجه داشته باشید که محدودیت 10 بسته ( IW10 ) به‌روزرسانی اخیر استاندارد TCP است: باید اطمینان حاصل کنید که سرور شما به آخرین نسخه ارتقا یافته است تا از این تغییر استفاده کنید. در غیر این صورت، محدودیت به احتمال زیاد 3-4 بسته خواهد بود!
با توجه به این رفتار TCP، بهینه سازی محتوای خود برای به حداقل رساندن تعداد رفت و برگشت های مورد نیاز برای ارائه داده های لازم برای انجام اولین رندر صفحه بسیار مهم است. در حالت ایده‌آل، محتوای ATF باید کمتر از 98 کیلوبایت باشد - این به مرورگر اجازه می‌دهد تا صفحه را تنها پس از سه بار رفت و برگشت نقاشی کند تا بودجه زمانی زیادی برای تأخیر پاسخ سرور و رندر مشتری داشته باشد.
- (4) از مسدود کردن خارجی جاوا اسکریپت و CSS در محتوای بالای صفحه خودداری کنید
قبل از اینکه مرورگر بتواند یک صفحه را به کاربر ارائه دهد، باید صفحه را تجزیه کند. اگر در حین تجزیه با یک اسکریپت خارجی غیرهمگام یا مسدود کننده مواجه شد، باید آن منبع را متوقف و دانلود کند. هر بار که این کار را انجام می دهد، یک رفت و برگشت شبکه اضافه می کند که زمان اولین رندر صفحه را به تاخیر می اندازد.
در نتیجه، جاوا اسکریپت و CSS مورد نیاز برای رندر کردن قسمت بالا در ناحیه فولد باید به صورت خطی باشند، و جاوا اسکریپت یا CSS مورد نیاز برای افزودن عملکرد اضافی به صفحه باید پس از تحویل محتوای ATF بارگذاری شود.
- (5) زمان رزرو برای طرح بندی مرورگر و رندر (200 میلی ثانیه)
- فرآیند تجزیه HTML، CSS و اجرای جاوا اسکریپت به زمان و منابع مشتری نیاز دارد! بسته به سرعت دستگاه تلفن همراه و پیچیدگی صفحه، این فرآیند می تواند صدها میلی ثانیه طول بکشد. توصیه ما این است که 200 میلی ثانیه برای سربار مرورگر رزرو کنید.
- (6) بهینه سازی زمان اجرا و رندر جاوا اسکریپت
- اجرای اسکریپت های پیچیده و کد ناکارآمد می تواند ده ها و صدها میلی ثانیه طول بکشد - از ابزارهای توسعه دهنده داخلی در مرورگر برای نمایه و بهینه سازی کد خود استفاده کنید. برای یک مقدمه عالی، نگاهی به دوره تعاملی ما برای ابزارهای برنامه‌نویس Chrome بیندازید.
سوالات متداول
- من از یک کتابخانه جاوا اسکریپت مانند JQuery استفاده می کنم، توصیه ای دارید؟
- بسیاری از کتابخانه‌های جاوا اسکریپت، مانند JQuery، برای بهبود صفحه برای افزودن تعامل، انیمیشن‌ها و جلوه‌های دیگر استفاده می‌شوند. با این حال، بسیاری از این رفتارها را می توان پس از ارائه محتوای ATF با خیال راحت اضافه کرد. انتقال اجرا و بارگذاری چنین جاوا اسکریپتی را تا زمانی که صفحه بارگذاری شود بررسی کنید.
- من از یک چارچوب جاوا اسکریپت برای ساخت صفحه استفاده می کنم، آیا توصیه ای دارید؟
- اگر محتوای صفحه توسط جاوا اسکریپت سمت سرویس گیرنده ساخته شده است، باید در داخل ماژول های جاوا اسکریپت مربوطه را بررسی کنید تا از رفت و برگشت اضافی شبکه جلوگیری کنید. به طور مشابه، استفاده از رندر سمت سرور می تواند به طور قابل توجهی عملکرد بارگذاری صفحه اول را بهبود بخشد: قالب های JS را در سرور رندر کنید، نتایج را در HTML قرار دهید، و سپس از قالب سمت سرویس گیرنده پس از بارگیری برنامه استفاده کنید.
- چگونه می توانم CSS حیاتی را در صفحه خود شناسایی کنم؟
- در Chrome Developer Tools، پانل حسابرسی را باز کنید، و یک گزارش عملکرد صفحه وب را اجرا کنید، در گزارش ایجاد شده، به دنبال حذف قوانین CSS استفاده نشده بگردید. یا از هر ابزار شخص ثالث یا اسکریپت دیگری برای شناسایی انتخابگرهای CSS در هر صفحه استفاده کنید.
- آیا می توان این بهترین شیوه ها را خودکار کرد؟
- کاملا. بسیاری از محصولات تجاری و منبع باز بهینه سازی عملکرد وب (WPO) وجود دارد که می تواند به شما کمک کند برخی یا همه معیارهای بالا را برآورده کنید. برای راه حل های منبع باز، نگاهی به ابزارهای بهینه سازی PageSpeed بیندازید.
- چگونه سرور خود را تنظیم کنم تا این معیارها را برآورده کند؟
- ابتدا مطمئن شوید که سرور شما یک نسخه به روز سیستم عامل را اجرا می کند. برای بهره مندی از افزایش اندازه پنجره تراکم اولیه TCP (IW10)، به هسته لینوکس 2.6.39+ نیاز دارید. برای سایر سیستم عامل ها، به مستندات مراجعه کنید.
برای بهینه سازی زمان پاسخ سرور، کد خود را تنظیم کنید، یا از یک راه حل نظارت بر برنامه برای شناسایی تنگنا خود استفاده کنید - به عنوان مثال، زمان اجرا اسکریپت، تماس های پایگاه داده، درخواست های RPC، رندر، و غیره. هدف این است که پاسخ HTML را در عرض 200 میلی ثانیه ارائه دهید. - در مورد خط مشی امنیت محتوا چطور؟
- اگر از CSP استفاده می کنید، ممکن است لازم باشد خط مشی پیش فرض خود را به روز کنید.
اول، از ویژگی های CSS درون خطی در عناصر HTML (به عنوان مثال،< p style=...>) باید تا حد امکان اجتناب شود، زیرا اغلب منجر به تکرار کدهای غیرضروری می شوند و به طور پیش فرض با CSP مسدود می شوند (غیرفعال شده از طریق "inline ناامن" در "style-src"). اگر CSP فعال باشد، به طور پیش‌فرض همه تگ‌های اسکریپت درون خطی را مسدود می‌کند. اگر جاوا اسکریپت درون خطی دارید، باید خط مشی CSP را به‌روزرسانی کنید تا از هش‌ها یا nonces اسکریپت استفاده کنید یا از "unsafe-inline" برای فعال کردن همه اسکریپت‌های درون خطی برای اجرا کردن استفاده کنید. اگر سبک‌های درون‌خطی دارید، باید خط‌مشی CSP را به‌روزرسانی کنید تا از هش‌های سبک یا nonces استفاده کنید یا از "unsafe-inline" برای فعال کردن تمام بلوک‌های سبک درون خطی برای پردازش استفاده کنید.
سوالات بیشتری دارید؟ لطفاً در گروه بحث ما در pagespeed-insights-discuss بپرسید و بازخورد خود را ارائه دهید.
بازخورد
این صفحه به شما کمک کرد؟