Lighthouse: بهینه سازی سرعت وب سایت

Kayce Basques

Sofia Emelianova

هدف آموزش

این آموزش به شما می آموزد که چگونه از Chrome DevTools برای یافتن راه هایی برای سریعتر بارگذاری وب سایت خود استفاده کنید.

نسخه ویدیویی این آموزش را بخوانید یا تماشا کنید:

این ویدیو با Chrome 68 ساخته شده است. بیشتر مواردی که در جزئیات ذکر شده هنوز درست است، اما برخی از ویژگی ها به روز شده اند. به عنوان مثال، پنل حسابرسی اکنون Lighthouse نامیده می شود و ظاهر متفاوتی دارد، اما همه گزینه های مشابه هنوز در دسترس هستند.

پیش نیازها

شما باید تجربه اولیه توسعه وب داشته باشید، مشابه آنچه در این کلاس مقدمه توسعه وب آموزش داده شده است.

نیازی نیست در مورد عملکرد بار چیزی بدانید.

معرفی

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

تونی گربه

مرحله 1: حسابرسی سایت

هر زمان که قصد بهبود عملکرد بارگذاری سایت را دارید، همیشه با ممیزی شروع کنید. حسابرسی دو وظیفه مهم دارد:

• این یک خط پایه برای شما ایجاد می کند تا تغییرات بعدی را با آن اندازه گیری کنید.
• این به شما نکات عملی در مورد اینکه چه تغییراتی بیشترین تأثیر را خواهند داشت به شما می دهد.

برپایی

ابتدا باید یک محیط کاری جدید برای وب سایت تونی راه اندازی کنید تا بتوانید بعداً تغییراتی در آن ایجاد کنید:

1. پروژه وب سایت را در Glitch دوباره میکس کنید . پروژه جدید شما در یک برگه باز می شود. این برگه به ​​عنوان تب ویرایشگر نامیده می شود.

   

   نام پروژه از تونی به نامی که به صورت تصادفی تولید می شود تغییر می کند. اکنون نسخه قابل ویرایش کد خود را دارید. بعداً، تغییراتی در این کد ایجاد خواهید کرد.

2. در پایین برگه ویرایشگر، روی Preview > Preview in a new window کلیک کنید. نسخه ی نمایشی در یک تب جدید باز می شود. این برگه به ​​عنوان تب دمو نامیده می شود. ممکن است مدتی طول بکشد تا سایت بارگیری شود.

   

3. DevTools را در کنار نسخه نمایشی باز کنید .

   

نکته کلیدی: برای بقیه اسکرین شات های این آموزش، DevTools در یک پنجره جداگانه نشان داده شده است.

یک خط پایه ایجاد کنید

خط مبنا سابقه عملکرد سایت قبل از اینکه شما هر گونه بهبود عملکرد را انجام دهید، است.

1. پانل Lighthouse را باز کنید. ممکن است در پشت پانل های بیشتر پنهان شده باشد.

   توجه: این پنل با همنام خود - Lighthouse ، یک ابزار خودکار برای بهبود کیفیت برنامه‌های وب شما کار می‌کند.

   

2. تنظیمات پیکربندی گزارش فانوس دریایی خود را با تنظیمات موجود در اسکرین شات مطابقت دهید. در اینجا توضیحی در مورد گزینه های مختلف آورده شده است:

   • check_box پاک کردن فضای ذخیره‌سازی . فعال کردن این چک باکس تمام فضای ذخیره‌سازی مرتبط با صفحه را قبل از هر بازرسی پاک می‌کند. اگر می‌خواهید نحوه تجربه بازدیدکنندگانی که برای اولین بار از سایت شما بازدید می‌کنند، بررسی کنید، این تنظیم را روشن بگذارید. هنگامی که می خواهید تجربه بازدید مجدد را داشته باشید، این تنظیم را غیرفعال کنید.
   • check_box نمونه برداری JS را فعال کنید . این گزینه به صورت پیش فرض خاموش است. وقتی روشن است، پشته‌های تماس دقیق جاوا اسکریپت را به ردیابی عملکرد اضافه می‌کند اما ممکن است تولید گزارش را کند کند. ردیابی در منوی more_vert Tools > View Unthrottled Trace پس از تولید گزارش Lighthouse در دسترس است.
   • throttling شبیه سازی شده (پیش فرض) . این گزینه شرایط معمول مرور در یک دستگاه تلفن همراه را شبیه سازی می کند. "شبیه‌سازی شده" نامیده می‌شود زیرا Lighthouse در طول فرآیند ممیزی در واقع گاز نمی‌گیرد. درعوض، فقط برون‌یابی می‌کند که چقدر طول می‌کشد تا صفحه تحت شرایط موبایل بارگذاری شود. از طرف دیگر، تنظیمات DevTools throttling (پیشرفته) ، در واقع CPU و شبکه شما را با یک فرآیند ممیزی طولانی تر کاهش می دهد.
   • Mode > Navigation (پیش‌فرض) . این حالت بارگذاری یک صفحه را تجزیه و تحلیل می کند و این چیزی است که در این آموزش به آن نیاز داریم. برای اطلاعات بیشتر، به سه حالت مراجعه کنید.
   • دستگاه > Mobile . گزینه موبایل رشته عامل کاربر را تغییر می دهد و یک نمای موبایل را شبیه سازی می کند. گزینه دسکتاپ تقریباً فقط تغییرات موبایل را غیرفعال می کند.
   • دسته ها > check_box عملکرد . یک دسته فعال واحد باعث می شود که Lighthouse فقط با مجموعه ممیزی های مربوطه گزارش تولید کند. اگر می‌خواهید انواع توصیه‌هایی را که ارائه می‌کنند ببینید، می‌توانید دسته‌های دیگر را فعال بگذارید. غیرفعال کردن دسته های نامربوط اندکی روند حسابرسی را سرعت می بخشد.

3. روی تجزیه و تحلیل بارگذاری صفحه کلیک کنید. بعد از 10 تا 30 ثانیه، پنل Lighthouse گزارشی از عملکرد سایت را به شما نشان می دهد.

   

رسیدگی به خطاهای گزارش

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

گزارش خود را درک کنید

عدد بالای گزارش شما امتیاز کلی عملکرد سایت است. بعداً با ایجاد تغییرات در کد، باید شاهد افزایش این عدد باشید. نمره بالاتر به معنای عملکرد بهتر است.

معیارهای

به قسمت Metrics بروید و روی Expand view کلیک کنید. برای خواندن اسناد در یک متریک، روی «بیشتر بدانید...» کلیک کنید.

این بخش اندازه گیری های کمی از عملکرد سایت را ارائه می دهد. هر معیار بینشی در مورد جنبه های مختلف عملکرد ارائه می دهد. به عنوان مثال، First Contentful Paint به شما می گوید چه زمانی محتوا برای اولین بار روی صفحه نمایش داده می شود، که نقطه عطف مهمی در درک کاربر از بارگذاری صفحه است، در حالی که Time To Interactive نقطه ای را مشخص می کند که در آن صفحه به اندازه کافی آماده به نظر می رسد تا تعاملات کاربر را مدیریت کند.

اسکرین شات ها

بعد مجموعه ای از اسکرین شات ها است که به شما نشان می دهد صفحه در هنگام بارگذاری چگونه به نظر می رسید.

فرصت ها

بعد، بخش فرصت ها است که نکات خاصی را در مورد چگونگی بهبود عملکرد بارگذاری این صفحه خاص ارائه می دهد.

روی یک فرصت کلیک کنید تا در مورد آن بیشتر بدانید.

برای مشاهده مستندات مربوط به چرایی اهمیت یک فرصت و توصیه‌های خاص در مورد چگونگی رفع آن، روی «بیشتر بدانید» کلیک کنید.

تشخیص

بخش Diagnostics اطلاعات بیشتری در مورد عواملی که در زمان بارگذاری صفحه نقش دارند ارائه می دهد.

ممیزی ها را پشت سر گذاشت

بخش Passed audits به شما نشان می دهد که سایت چه کاری را به درستی انجام می دهد. برای گسترش بخش کلیک کنید.

مرحله 2: آزمایش

بخش فرصت ها در گزارش Lighthouse شما نکاتی را در مورد چگونگی بهبود عملکرد صفحه به شما می دهد. در این بخش، تغییرات توصیه شده را در پایگاه کد پیاده سازی می کنید، پس از هر تغییر، سایت را ممیزی می کنید تا میزان تاثیر آن بر سرعت سایت را اندازه گیری کنید.

فشرده سازی متن را فعال کنید

گزارش شما می گوید که فعال کردن فشرده سازی متن یکی از بهترین فرصت ها برای بهبود عملکرد صفحه است.

فشرده سازی متن زمانی است که اندازه یک فایل متنی را قبل از ارسال آن از طریق شبکه کاهش می دهید یا فشرده می کنید. مثل اینکه چگونه می توانید یک پوشه را قبل از ارسال ایمیل برای کاهش اندازه آن زیپ کنید.

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

پانل شبکه را باز کنید و را بررسی کنید Settings > استفاده از ردیف‌های درخواست بزرگ .

نکته کلیدی: اگر ستون Size را در جدول درخواست‌های شبکه نمی‌بینید، روی سرصفحه جدول کلیک راست کرده و Size را انتخاب کنید.

هر سلول Size دو مقدار را نشان می دهد. مقدار بالا اندازه منبع دانلود شده است. مقدار پایین اندازه منبع فشرده نشده است. اگر این دو مقدار یکسان باشند، منبع در هنگام ارسال از طریق شبکه فشرده نمی شود. در این مثال، مقادیر بالا و پایین برای bundle.js هر دو 1.4 MB است.

همچنین می‌توانید با بررسی سرصفحه‌های HTTP یک منبع، فشرده‌سازی را بررسی کنید:

1. روی bundle.js کلیک کنید و تب Headers را باز کنید.

   

2. در بخش سرصفحه‌های پاسخ برای سرصفحه content-encoding جستجو کنید. شما نباید یکی را ببینید، به این معنی که bundle.js فشرده نشده است. هنگامی که یک منبع فشرده می شود ، این هدر معمولاً روی gzip ، deflate یا br تنظیم می شود. برای توضیح این مقادیر به دستورالعمل ها مراجعه کنید.

با توضیحات بس است. زمان ایجاد تغییراتی است! فشرده سازی متن را با اضافه کردن چند خط کد فعال کنید:

1. در تب ویرایشگر، server.js را باز کنید و دو خط (هایلایت شده) زیر را اضافه کنید:

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. مطمئن شوید که app.use(compression()) را قبل از app.use(express.static('build')) قرار دهید.

   

   توجه: معمولاً باید بسته compression را از طریق چیزی مانند npm i -S compression نصب کنید، اما این قبلاً برای شما انجام شده است.

3. منتظر بمانید تا Glitch بیلد جدید سایت را اجرا کند. یک ایموجی شاد در گوشه سمت چپ پایین نشان دهنده استقرار موفقیت آمیز است.

از گردش‌های کاری که قبلاً یاد گرفتید برای بررسی دستی اینکه فشرده‌سازی کار می‌کند استفاده کنید:

1. به تب دمو برگردید و صفحه را دوباره بارگیری کنید.

   اکنون ستون Size باید دو مقدار متفاوت را برای منابع متنی مانند bundle.js نشان دهد. مقدار بالای 269 KB برای bundle.js اندازه فایلی است که از طریق شبکه ارسال شده است و مقدار پایین 1.4 MB اندازه فایل فشرده نشده است.

   

2. بخش Response Headers برای bundle.js اکنون باید شامل یک content-encoding: gzip header.

   

برای اندازه‌گیری تأثیر فشرده‌سازی متن بر عملکرد بارگذاری صفحه، گزارش Lighthouse را دوباره روی صفحه اجرا کنید:

1. پنل Lighthouse را باز کرده و کلیک کنید ممیزی را روی نوار اقدام در بالا انجام دهید .

   

2. تنظیمات را مانند قبل رها کنید و روی Analyze page load کلیک کنید.

   

وووووو به نظر پیشرفت است. نمره عملکرد کلی شما باید افزایش یافته باشد، به این معنی که سایت سریعتر می شود.

فشرده سازی متن در دنیای واقعی

اکثر سرورها واقعاً راه حل های ساده ای مانند این را برای فعال کردن فشرده سازی دارند! فقط در مورد نحوه پیکربندی سروری که برای فشرده سازی متن استفاده می کنید جستجو کنید.

تغییر اندازه تصاویر

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

تغییر اندازه تصاویر با کاهش اندازه فایل تصاویر به سرعت بارگذاری کمک می کند. اگر کاربر شما در حال مشاهده تصاویر شما بر روی صفحه نمایش دستگاه تلفن همراه با عرض 500 پیکسل است، ارسال یک تصویر با عرض 1500 پیکسل واقعاً فایده ای ندارد. در حالت ایده آل، حداکثر یک تصویر با عرض 500 پیکسل ارسال می کنید.

1. در گزارش خود، روی Properly size images کلیک کنید تا ببینید چه تصاویری باید تغییر اندازه داده شوند. به نظر می رسد هر 4 تصویر بزرگتر از حد لازم هستند.

   

2. در برگه ویرایشگر، src/model.js را باز کنید.

3. const dir = 'big' را با const dir = 'small' جایگزین کنید. این فهرست شامل کپی هایی از همان تصاویری است که اندازه آنها تغییر کرده است.

4. دوباره صفحه را بررسی کنید تا ببینید این تغییر چگونه بر عملکرد بارگذاری تأثیر می‌گذارد.

   

به نظر می‌رسد که این تغییر تنها تأثیر جزئی بر نمره عملکرد کلی دارد. با این حال، چیزی که امتیاز به وضوح نشان نمی دهد این است که چه مقدار از داده های شبکه را ذخیره می کنید. حجم کل عکس های قدیمی حدود 6.1 مگابایت بود، در حالی که اکنون فقط حدود 633 کیلوبایت است. می توانید این را در نوار وضعیت در پایین پانل شبکه بررسی کنید.

تغییر اندازه تصاویر در دنیای واقعی

برای یک برنامه کوچک، انجام یک تغییر اندازه مانند این ممکن است به اندازه کافی خوب باشد. اما برای یک برنامه بزرگ، این بدیهی است که مقیاس پذیر نیست. در اینجا چند استراتژی برای مدیریت تصاویر در برنامه های بزرگ آورده شده است:

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

منابع مسدودکننده رندر را حذف کنید

آخرین گزارش شما می گوید که حذف منابع مسدودکننده رندر اکنون بزرگترین فرصت است.

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

بنابراین، اولین کار، یافتن کدی است که نیازی به اجرا در بارگذاری صفحه نداشته باشد.

1. برای مشاهده منابعی که مسدود می‌شوند ، روی حذف منابع مسدودکننده رندر کلیک کنید: lodash.js و jquery.js .

   

2. بسته به سیستم عامل خود، برای باز کردن منوی فرمان، دکمه زیر را فشار دهید:

   • در مک، Command + Shift + P
   • در Windows، Linux، یا ChromeOS، Control + Shift + P

3. شروع به تایپ Coverage کنید و Show Coverage را انتخاب کنید.

   

   تب Coverage در کشو باز می شود.

   

4. کلیک بارگذاری مجدد برگه Coverage نمای کلی از اینکه چه مقدار از کد موجود در bundle.js ، jquery.js و lodash.js در حین بارگیری صفحه اجرا می شود، ارائه می دهد.

   

   این اسکرین شات می گوید که حدود 74 درصد و 30 درصد از فایل های jQuery و Lodash به ترتیب استفاده نمی شوند.

5. روی ردیف jquery.js کلیک کنید. DevTools فایل را در پنل Sources باز می کند. یک خط کد در صورتی اجرا می شود که یک نوار سبز در کنار آن داشته باشد. نوار قرمز در کنار یک خط کد به این معنی است که اجرا نشده است و قطعاً در بارگذاری صفحه مورد نیاز نیست.

   

6. کمی در کد jQuery حرکت کنید. برخی از خطوطی که "اجرا می شوند" در واقع فقط نظرات هستند. اجرای این کد از طریق مینی فایری که نظرات را حذف می کند، راه دیگری برای کاهش حجم این فایل است.

به طور خلاصه، هنگامی که با کد خود کار می کنید، تب Coverage می تواند به شما کمک کند تا کد خود را خط به خط تجزیه و تحلیل کنید و فقط کدی را که برای بارگذاری صفحه لازم است ارسال کنید.

آیا فایل های jquery.js و lodash.js حتی برای بارگذاری صفحه مورد نیاز هستند؟ تب Request Blocking می تواند به شما نشان دهد وقتی منابع در دسترس نیستند چه اتفاقی می افتد.

1. روی تب Network کلیک کنید و دوباره Command Menu را باز کنید .

2. شروع به تایپ blocking و سپس Show Request Blocking را انتخاب کنید. تب Request Blocking باز می شود.

   

3. کلیک Pattern را اضافه کنید ، /libs/* را در کادر متنی تایپ کنید و برای تایید Enter را فشار دهید.

   

4. صفحه را دوباره بارگیری کنید. درخواست‌های jQuery و Lodash قرمز هستند، یعنی مسدود شده‌اند. صفحه همچنان بار می شود و تعاملی است، بنابراین به نظر می رسد که این منابع به هیچ وجه مورد نیاز نیستند!

   

5. کلیک برای حذف الگوی مسدودکننده /libs/* همه الگوها را حذف کنید .

به طور کلی، تب Request Blocking برای شبیه سازی نحوه رفتار صفحه شما در زمانی که هیچ منبعی در دسترس نیست مفید است.

اکنون ارجاعات به این فایل ها را از کد حذف کنید و دوباره صفحه را بررسی کنید:

1. در برگه ویرایشگر، template.html باز کنید.

2. برچسب های <script> مربوطه را حذف کنید:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. منتظر بمانید تا سایت دوباره بسازد و دوباره راه اندازی شود.

4. دوباره صفحه را از پنل Lighthouse بررسی کنید. نمره کلی شما باید دوباره بهبود می یافت.

   

بهینه سازی مسیر رندر بحرانی در دنیای واقعی

Critical Rendering Path به کدی اشاره دارد که برای بارگذاری یک صفحه به آن نیاز دارید. به طور کلی، می‌توانید سرعت بارگذاری صفحه را تنها با ارسال کدهای مهم در حین بارگذاری صفحه، و سپس بارگذاری تنبلی هر چیز دیگری افزایش دهید.

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

کمتر کار با نخ اصلی انجام دهید

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

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

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

هدف استفاده از پنل Performance برای تجزیه و تحلیل کاری است که موضوع اصلی در حین بارگیری صفحه انجام می دهد و راه هایی برای به تعویق انداختن یا حذف کارهای غیر ضروری پیدا کنید.

1. عملکرد > را باز کنید از تنظیمات عکس بگیرید و شبکه را روی Slow 3G و CPU را روی کندی 6 برابری تنظیم کنید.

   

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

2. کلیک بارگذاری مجدد DevTools صفحه را مجدداً بارگیری می کند و سپس تصویری از تمام کارهایی که برای بارگذاری صفحه باید انجام می داد را ایجاد می کند. این تجسم به عنوان ردیابی نامیده می شود.

   

ردیابی فعالیت را به ترتیب زمانی، از چپ به راست نشان می دهد. نمودارهای FPS، CPU و NET در بالا به شما یک نمای کلی از فریم در ثانیه، فعالیت CPU و فعالیت شبکه می دهد.

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

ردیابی را برای یافتن راه هایی برای انجام کارهای کمتر جاوا اسکریپت بررسی کنید:

1. برای بزرگ شدن قسمت Times کلیک کنید.

   

   مجموعه ای از معیارهای زمان بندی کاربر از React وجود دارد، به نظر می رسد برنامه تونی از حالت توسعه React استفاده می کند. تغییر به حالت تولید React احتمالاً برخی از عملکردهای آسان را به همراه خواهد داشت.

2. دوباره روی Timeings کلیک کنید تا آن بخش کوچک شود.

3. بخش اصلی را مرور کنید. این بخش گزارش زمانی فعالیت نخ اصلی را از چپ به راست نشان می دهد. محور y (بالا به پایین) نشان می دهد که چرا رویدادها رخ داده اند.

   

   در این مثال، رویداد Evaluate Script باعث اجرای تابع (anonymous) شد، که باعث شد __webpack__require__ اجرا شود، که باعث شد ./src/index.jsx و غیره اجرا شود.

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

   

   در این برنامه به نظر می رسد که تابعی به نام App باعث تماس های زیادی با یک تابع mineBitcoin می شود. به نظر می رسد که تونی ممکن است از دستگاه های طرفداران خود برای استخراج ارز دیجیتال استفاده کند ...

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

5. تب Bottom-Up را در پایین باز کنید. این برگه فعالیت‌هایی را که بیشترین زمان را صرف کرده‌اند، مشخص می‌کند. اگر چیزی در بخش پایین به بالا نمی بینید، روی برچسب بخش اصلی کلیک کنید.

   

   بخش پایین به بالا فقط اطلاعات مربوط به هر فعالیت یا گروهی از فعالیت را که در حال حاضر انتخاب کرده اید نشان می دهد. به عنوان مثال، اگر روی یکی از فعالیت‌های mineBitcoin کلیک کرده باشید، بخش Bottom-Up فقط اطلاعات مربوط به آن یک فعالیت را نشان می‌دهد.

   ستون Self Time به شما نشان می دهد که چه مقدار زمان به طور مستقیم در هر فعالیت صرف شده است. در این مورد، حدود 82 درصد از زمان نخ اصلی صرف تابع mineBitcoin شده است.

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

1. در برگه ویرایشگر، webpack.config.js باز کنید.
2. "mode":"development" را به "mode":"production" تغییر دهید.
3. منتظر بمانید تا بیلد جدید اجرا شود.

4. دوباره صفحه را ممیزی کنید.

   

با حذف تماس با mineBitcoin ، فعالیت جاوا اسکریپت را کاهش دهید:

1. در برگه ویرایشگر، src/App.jsx را باز کنید.
2. تماس با this.mineBitcoin(1500) در constructor نظر دهید.
3. منتظر بمانید تا بیلد جدید اجرا شود.
4. دوباره صفحه را ممیزی کنید.

مثل همیشه، هنوز کارهایی برای انجام دادن وجود دارد، به عنوان مثال، معیارهای Largest Contentful Paint و Cumulative Layout Shift را کاهش دهید.

موفقیت: اما به نظر می رسد آخرین تغییر باعث جهش گسترده در عملکرد شد!

انجام کمتر کار با موضوع اصلی در دنیای واقعی

به طور کلی، پنل عملکرد رایج ترین راه برای درک فعالیت هایی است که سایت شما هنگام بارگذاری انجام می دهد و راه هایی برای حذف فعالیت های غیر ضروری پیدا می کند.

اگر رویکردی را ترجیح می‌دهید که بیشتر شبیه به console.log() باشد، User Timing API به شما این امکان را می‌دهد تا مراحل خاصی از چرخه عمر برنامه‌تان را به‌طور دلخواه علامت‌گذاری کنید تا مدت زمان هر یک از آن مراحل را پیگیری کنید.

خلاصه

• هر زمان که قصد بهینه سازی عملکرد بارگذاری سایت را دارید، همیشه با یک ممیزی شروع کنید. ممیزی یک خط پایه ایجاد می کند و نکاتی را در مورد چگونگی بهبود به شما می دهد.
• هر بار یک تغییر ایجاد کنید و بعد از هر تغییر صفحه را بررسی کنید تا ببینید که این تغییر جدا شده چگونه بر عملکرد تأثیر می گذارد.

مراحل بعدی

ممیزی را در سایت خود اجرا کنید! اگر برای تفسیر گزارش خود یا یافتن راه‌هایی برای بهبود عملکرد بارگذاری خود به کمک نیاز دارید، همه راه‌های دریافت کمک از انجمن DevTools را بررسی کنید:

• اشکالات این سند را در مخزن developer.chrome.com ثبت کنید.
• گزارش‌های اشکال در DevTools در Chromium Bugs .
• در مورد ویژگی ها و تغییرات در لیست پستی بحث کنید. لطفاً از لیست پستی برای سؤالات پشتیبانی استفاده نکنید. در عوض از Stack Overflow استفاده کنید.
• در مورد نحوه استفاده از DevTools در Stack Overflow راهنمایی کلی دریافت کنید. برای ثبت درخواست‌های اشکال، همیشه از Chromium Bugs استفاده کنید.
• ما را در @ChromeDevTools توییت کنید.

،

Kayce Basques

Sofia Emelianova

هدف آموزش

این آموزش به شما می آموزد که چگونه از Chrome DevTools برای یافتن راه هایی برای سریعتر بارگذاری وب سایت خود استفاده کنید.

نسخه ویدیویی این آموزش را بخوانید یا تماشا کنید:

این ویدیو با Chrome 68 ساخته شده است. بیشتر مواردی که در جزئیات ذکر شده هنوز درست است، اما برخی از ویژگی ها به روز شده اند. به عنوان مثال، پنل حسابرسی اکنون Lighthouse نامیده می شود و ظاهر متفاوتی دارد، اما همه گزینه های مشابه هنوز در دسترس هستند.

پیش نیازها

شما باید تجربه اولیه توسعه وب داشته باشید، مشابه آنچه در این کلاس مقدمه توسعه وب آموزش داده شده است.

نیازی نیست در مورد عملکرد بار چیزی بدانید.

معرفی

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

تونی گربه

مرحله 1: حسابرسی سایت

هر زمان که قصد بهبود عملکرد بارگذاری سایت را دارید، همیشه با ممیزی شروع کنید. حسابرسی دو وظیفه مهم دارد:

• این یک خط پایه برای شما ایجاد می کند تا تغییرات بعدی را با آن اندازه گیری کنید.
• این به شما نکات عملی در مورد اینکه چه تغییراتی بیشترین تأثیر را خواهند داشت به شما می دهد.

برپایی

ابتدا باید یک محیط کاری جدید برای وب سایت تونی راه اندازی کنید تا بتوانید بعداً تغییراتی در آن ایجاد کنید:

1. پروژه وب سایت را در Glitch دوباره میکس کنید . پروژه جدید شما در یک برگه باز می شود. این برگه به ​​عنوان تب ویرایشگر نامیده می شود.

   

   نام پروژه از تونی به نامی که به صورت تصادفی تولید می شود تغییر می کند. اکنون نسخه قابل ویرایش کد خود را دارید. بعداً، تغییراتی در این کد ایجاد خواهید کرد.

2. در پایین برگه ویرایشگر، روی Preview > Preview in a new window کلیک کنید. نسخه ی نمایشی در یک تب جدید باز می شود. این برگه به ​​عنوان تب دمو نامیده می شود. ممکن است مدتی طول بکشد تا سایت بارگیری شود.

   

3. DevTools را در کنار نسخه نمایشی باز کنید .

   

نکته کلیدی: برای بقیه اسکرین شات های این آموزش، DevTools در یک پنجره جداگانه نشان داده شده است.

یک خط پایه ایجاد کنید

خط مبنا سابقه عملکرد سایت قبل از اینکه شما هر گونه بهبود عملکرد را انجام دهید، است.

1. پانل Lighthouse را باز کنید. ممکن است در پشت پانل های بیشتر پنهان شده باشد.

   توجه: این پنل با همنام خود - Lighthouse ، یک ابزار خودکار برای بهبود کیفیت برنامه‌های وب شما کار می‌کند.

   

2. تنظیمات پیکربندی گزارش فانوس دریایی خود را با تنظیمات موجود در اسکرین شات مطابقت دهید. در اینجا توضیحی در مورد گزینه های مختلف آورده شده است:

   • check_box پاک کردن فضای ذخیره‌سازی . فعال کردن این چک باکس تمام فضای ذخیره‌سازی مرتبط با صفحه را قبل از هر بازرسی پاک می‌کند. اگر می‌خواهید نحوه تجربه بازدیدکنندگانی که برای اولین بار از سایت شما بازدید می‌کنند، بررسی کنید، این تنظیم را روشن بگذارید. هنگامی که می خواهید تجربه بازدید مجدد را داشته باشید، این تنظیم را غیرفعال کنید.
   • check_box نمونه برداری JS را فعال کنید . این گزینه به صورت پیش فرض خاموش است. وقتی روشن است، پشته‌های تماس دقیق جاوا اسکریپت را به ردیابی عملکرد اضافه می‌کند اما ممکن است تولید گزارش را کند کند. ردیابی در منوی more_vert Tools > View Unthrottled Trace پس از تولید گزارش Lighthouse در دسترس است.
   • throttling شبیه سازی شده (پیش فرض) . این گزینه شرایط معمول مرور در یک دستگاه تلفن همراه را شبیه سازی می کند. "شبیه‌سازی شده" نامیده می‌شود زیرا Lighthouse در طول فرآیند ممیزی در واقع گاز نمی‌گیرد. درعوض، فقط برون‌یابی می‌کند که چقدر طول می‌کشد تا صفحه تحت شرایط موبایل بارگذاری شود. از طرف دیگر، تنظیمات DevTools throttling (پیشرفته) ، در واقع CPU و شبکه شما را با یک فرآیند ممیزی طولانی تر کاهش می دهد.
   • Mode > Navigation (پیش‌فرض) . این حالت بارگذاری یک صفحه را تجزیه و تحلیل می کند و این چیزی است که در این آموزش به آن نیاز داریم. برای اطلاعات بیشتر، به سه حالت مراجعه کنید.
   • دستگاه > Mobile . گزینه موبایل رشته عامل کاربر را تغییر می دهد و یک نمای موبایل را شبیه سازی می کند. گزینه دسکتاپ تقریباً فقط تغییرات موبایل را غیرفعال می کند.
   • دسته ها > check_box عملکرد . یک دسته فعال واحد باعث می شود که Lighthouse فقط با مجموعه ممیزی های مربوطه گزارش تولید کند. اگر می‌خواهید انواع توصیه‌هایی را که ارائه می‌کنند ببینید، می‌توانید دسته‌های دیگر را فعال بگذارید. غیرفعال کردن دسته های نامربوط اندکی روند حسابرسی را سرعت می بخشد.

3. روی تجزیه و تحلیل بارگذاری صفحه کلیک کنید. بعد از 10 تا 30 ثانیه، پنل Lighthouse گزارشی از عملکرد سایت را به شما نشان می دهد.

   

رسیدگی به خطاهای گزارش

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

گزارش خود را درک کنید

عدد بالای گزارش شما امتیاز کلی عملکرد سایت است. بعداً با ایجاد تغییرات در کد، باید شاهد افزایش این عدد باشید. نمره بالاتر به معنای عملکرد بهتر است.

معیارهای

به قسمت Metrics بروید و روی Expand view کلیک کنید. برای خواندن اسناد در یک متریک، روی «بیشتر بدانید...» کلیک کنید.

این بخش اندازه گیری های کمی از عملکرد سایت را ارائه می دهد. هر معیار بینشی در مورد جنبه های مختلف عملکرد ارائه می دهد. به عنوان مثال، First Contentful Paint به شما می گوید چه زمانی محتوا برای اولین بار روی صفحه نمایش داده می شود، که نقطه عطف مهمی در درک کاربر از بارگذاری صفحه است، در حالی که Time To Interactive نقطه ای را مشخص می کند که در آن صفحه به اندازه کافی آماده به نظر می رسد تا تعاملات کاربر را مدیریت کند.

اسکرین شات ها

بعد مجموعه ای از اسکرین شات ها است که به شما نشان می دهد صفحه در هنگام بارگذاری چگونه به نظر می رسید.

فرصت ها

بعد، بخش فرصت ها است که نکات خاصی را در مورد چگونگی بهبود عملکرد بارگذاری این صفحه خاص ارائه می دهد.

روی یک فرصت کلیک کنید تا در مورد آن بیشتر بدانید.

برای مشاهده مستندات مربوط به چرایی اهمیت یک فرصت و توصیه‌های خاص در مورد چگونگی رفع آن، روی «بیشتر بدانید» کلیک کنید.

تشخیص

بخش Diagnostics اطلاعات بیشتری در مورد عواملی که در زمان بارگذاری صفحه نقش دارند ارائه می دهد.

ممیزی ها را پشت سر گذاشت

بخش Passed audits به شما نشان می دهد که سایت چه کاری را به درستی انجام می دهد. برای گسترش بخش کلیک کنید.

مرحله 2: آزمایش

بخش فرصت ها در گزارش Lighthouse شما نکاتی را در مورد چگونگی بهبود عملکرد صفحه به شما می دهد. در این بخش، تغییرات توصیه شده را در پایگاه کد پیاده سازی می کنید، پس از هر تغییر، سایت را ممیزی می کنید تا میزان تاثیر آن بر سرعت سایت را اندازه گیری کنید.

فشرده سازی متن را فعال کنید

گزارش شما می گوید که فعال کردن فشرده سازی متن یکی از بهترین فرصت ها برای بهبود عملکرد صفحه است.

فشرده سازی متن زمانی است که اندازه یک فایل متنی را قبل از ارسال آن از طریق شبکه کاهش می دهید یا فشرده می کنید. مثل اینکه چگونه می توانید یک پوشه را قبل از ارسال ایمیل برای کاهش اندازه آن زیپ کنید.

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

پانل شبکه را باز کنید و را بررسی کنید Settings > استفاده از ردیف‌های درخواست بزرگ .

نکته کلیدی: اگر ستون Size را در جدول درخواست‌های شبکه نمی‌بینید، روی سرصفحه جدول کلیک راست کرده و Size را انتخاب کنید.

هر سلول Size دو مقدار را نشان می دهد. مقدار بالا اندازه منبع دانلود شده است. مقدار پایین اندازه منبع فشرده نشده است. اگر این دو مقدار یکسان باشند، منبع در هنگام ارسال از طریق شبکه فشرده نمی شود. در این مثال، مقادیر بالا و پایین برای bundle.js هر دو 1.4 MB است.

همچنین می‌توانید با بررسی سرصفحه‌های HTTP یک منبع، فشرده‌سازی را بررسی کنید:

1. روی bundle.js کلیک کنید و تب Headers را باز کنید.

   

2. در بخش سرصفحه‌های پاسخ برای سرصفحه content-encoding جستجو کنید. شما نباید یکی را ببینید، به این معنی که bundle.js فشرده نشده است. هنگامی که یک منبع فشرده می شود ، این هدر معمولاً روی gzip ، deflate یا br تنظیم می شود. برای توضیح این مقادیر به دستورالعمل ها مراجعه کنید.

با توضیحات بس است. زمان ایجاد تغییراتی است! فشرده سازی متن را با اضافه کردن چند خط کد فعال کنید:

1. در تب ویرایشگر، server.js را باز کنید و دو خط (هایلایت شده) زیر را اضافه کنید:

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. مطمئن شوید که app.use(compression()) را قبل از app.use(express.static('build')) قرار دهید.

   

   توجه: معمولاً باید بسته compression را از طریق چیزی مانند npm i -S compression نصب کنید، اما این قبلاً برای شما انجام شده است.

3. منتظر بمانید تا Glitch بیلد جدید سایت را اجرا کند. یک ایموجی شاد در گوشه سمت چپ پایین نشان دهنده استقرار موفقیت آمیز است.

از گردش‌های کاری که قبلاً یاد گرفتید برای بررسی دستی اینکه فشرده‌سازی کار می‌کند استفاده کنید:

1. به تب دمو برگردید و صفحه را دوباره بارگیری کنید.

   اکنون ستون Size باید دو مقدار متفاوت را برای منابع متنی مانند bundle.js نشان دهد. مقدار بالای 269 KB برای bundle.js اندازه فایلی است که از طریق شبکه ارسال شده است و مقدار پایین 1.4 MB اندازه فایل فشرده نشده است.

   

2. بخش Response Headers برای bundle.js اکنون باید شامل یک content-encoding: gzip header.

   

گزارش فانوس دریایی را دوباره در صفحه اجرا کنید تا تأثیر فشرده سازی متن در عملکرد بار صفحه را اندازه گیری کنید:

1. پنل فانوس دریایی را باز کنید و کلیک کنید یک حسابرسی را انجام دهید ... در نوار عمل در بالا.

   

2. تنظیمات را مانند گذشته بگذارید و روی تجزیه و تحلیل بار کلیک کنید.

   

وووووو به نظر می رسد پیشرفت است. نمره کلی عملکرد شما باید افزایش یافته باشد ، به این معنی که سایت سریعتر می شود.

فشرده سازی متن در دنیای واقعی

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

تغییر اندازه تصاویر

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

تغییر اندازه تصاویر با کاهش اندازه پرونده تصاویر به سرعت بار کمک می کند. اگر کاربر شما در حال مشاهده تصاویر شما در صفحه دستگاه تلفن همراه که 500 پیکسل در آن است ، واقعاً هیچ نکته ای برای ارسال یک تصویر 1500 پیکسل وجود ندارد. در حالت ایده آل ، حداکثر یک تصویر 500 پیکسل را ارسال می کنید.

1. در گزارش خود ، بر روی تصاویر به درستی کلیک کنید تا ببینید چه تصاویر باید تغییر مکان دهند. به نظر می رسد که هر 4 تصویر بزرگتر از حد لازم هستند.

   

2. برگشت در برگه ویرایشگر ، src/model.js باز کنید.

3. const dir = 'big' را با const dir = 'small' جایگزین کنید. این فهرست شامل نسخه هایی از همان تصاویر است که تغییر اندازه داده شده است.

4. دوباره صفحه را حسابرسی کنید تا ببینید که چگونه این تغییر بر عملکرد بار تأثیر می گذارد.

   

به نظر می رسد که این تغییر فقط تأثیر جزئی در نمره کلی عملکرد دارد. با این حال ، یک مورد که نمره به وضوح نشان نمی دهد این است که داده های شبکه شما در حال ذخیره کاربران خود هستند. اندازه کل عکسهای قدیمی حدود 6.1 مگابایت بود ، در حالی که اکنون فقط حدود 633 کیلوبایت است. می توانید این کار را در نوار وضعیت در پایین پنل شبکه بررسی کنید.

تغییر اندازه تصاویر در دنیای واقعی

برای یک برنامه کوچک ، انجام یک تغییر اندازه یک طرفه مانند این ممکن است به اندازه کافی خوب باشد. اما برای یک برنامه بزرگ ، این بدیهی است که مقیاس پذیر نیست. در اینجا برخی از استراتژی ها برای مدیریت تصاویر در برنامه های بزرگ آورده شده است:

• در طی مراحل ساخت خود تصاویر را تغییر دهید.
• در طی فرآیند ساخت چندین اندازه از هر تصویر ایجاد کنید و سپس از srcset در کد خود استفاده کنید. در زمان اجرا ، مرورگر مراقبت می کند تا انتخاب کند که چه اندازه برای دستگاهی که روی آن کار می کند بهترین است. به تصاویر با اندازه نسبی مراجعه کنید.
• از یک CDN تصویری استفاده کنید که به شما امکان می دهد هنگام درخواست آن ، یک تصویر را به صورت پویا تغییر اندازه دهید.
• حداقل ، هر تصویر را بهینه کنید. این اغلب می تواند پس انداز بزرگی ایجاد کند. بهینه سازی زمانی است که شما یک تصویر را از طریق یک برنامه خاص اجرا می کنید که اندازه فایل تصویر را کاهش می دهد. برای نکات بیشتر به بهینه سازی تصویر ضروری مراجعه کنید.

منابع مسدود کننده رندر را از بین ببرید

آخرین گزارش شما می گوید که از بین بردن منابع مسدود کننده رندر اکنون بزرگترین فرصت است.

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

اولین کار ، یافتن کدی است که نیازی به اجرای آن در بار صفحه نیست.

1. برای دیدن منابعی که مسدود می شود ، روی حذف منابع مسدود کننده رندر کلیک کنید: lodash.js و jquery.js .

   

2. بسته به سیستم عامل خود ، موارد زیر را فشار دهید تا منوی فرمان باز شود :

   • در Mac ، Command + Shift + P
   • در ویندوز ، لینوکس یا Chromeos ، Control + Shift + P

3. شروع به تایپ کردن Coverage و انتخاب پوشش را انتخاب کنید.

   

   برگه پوشش در کشو باز می شود.

   

4. کلیک بارگیری مجدد برگه Coverage مروری بر میزان کد موجود در bundle.js ، jquery.js و lodash.js در هنگام بارگیری صفحه ارائه می دهد.

   

   این تصویر می گوید که به ترتیب حدود 74 ٪ و 30 ٪ از پرونده های jQuery و Lodash استفاده نمی شود.

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

   

6. کمی از طریق کد jQuery حرکت کنید. برخی از خطوطی که "اعدام می شوند" در واقع فقط نظرات هستند. اجرای این کد از طریق یک مینیوتر که نظرات خود را از بین می برد ، روش دیگری برای کاهش اندازه این پرونده است.

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

آیا پرونده های jquery.js و lodash.js حتی برای بارگیری صفحه مورد نیاز هستند؟ برگه مسدود کردن درخواست می تواند به شما نشان دهد که وقتی منابع در دسترس نیستند چه اتفاقی می افتد.

1. روی برگه شبکه کلیک کنید و دوباره منوی Command را باز کنید .

2. شروع به تایپ کردن blocking و سپس SHOW AVEANT CLOCESING را انتخاب کنید. برگه مسدود کردن درخواست باز می شود.

   

3. کلیک الگوی ، نوع /libs/* را در جعبه متن اضافه کنید و برای تأیید ENTER را فشار دهید.

   

4. صفحه را دوباره بارگیری کنید. درخواست های jQuery و Lodash قرمز است ، به این معنی که مسدود شده اند. این صفحه هنوز بارگذاری می شود و تعاملی است ، بنابراین به نظر می رسد که این منابع به هر چیزی احتیاج ندارند!

   

5. کلیک تمام الگوهای را حذف کنید تا الگوی مسدود کردن /libs/* را حذف کنید.

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

اکنون ، منابع این پرونده ها را از کد حذف کرده و دوباره صفحه را حسابرسی کنید:

1. بازگشت در برگه ویرایشگر ، Open template.html .

2. برچسب های مربوط به <script> مربوطه را حذف کنید:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. صبر کنید تا سایت دوباره بسازد و دوباره مستقر شود.

4. صفحه را دوباره از صفحه Lighthouse حسابرسی کنید. نمره کلی شما باید دوباره بهبود یابد.

   

بهینه سازی مسیر ارائه بحرانی در دنیای واقعی

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

• بعید است که اسکریپت هایی را پیدا کنید که بتوانید به طور کامل حذف کنید ، اما اغلب متوجه خواهید شد که بسیاری از اسکریپت ها نیازی به درخواست در طول بار صفحه ندارند و در عوض می توانند به صورت ناهمزمان درخواست شوند. استفاده از async یا defer را ببینید.
• اگر از یک چارچوب استفاده می کنید ، بررسی کنید که آیا حالت تولید دارد یا خیر. این حالت ممکن است از ویژگی هایی مانند لرزش درخت به منظور از بین بردن کد غیر ضروری که مانع از ارائه بحرانی است ، استفاده کند.

کمتر کار موضوع اصلی را انجام دهید

آخرین گزارش شما برخی از پس اندازهای بالقوه جزئی را در بخش فرصت ها نشان می دهد ، اما اگر به بخش Diagnostics بروید ، به نظر می رسد بزرگترین تنگنا فعالیت موضوع اصلی بیش از حد است.

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

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

هدف استفاده از پانل عملکرد برای تجزیه و تحلیل آنچه موضوع اصلی انجام می دهد در حالی که صفحه بارگیری می شود ، و یافتن راه هایی برای تعویق یا حذف کار غیر ضروری است.

1. عملکرد باز> تنظیمات را ضبط کرده و شبکه را تنظیم کنید تا 3G و CPU را به کندی 6 برابر کند.

   

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

2. کلیک بارگیری مجدد DevTools صفحه را بارگیری می کند و سپس تجسم آنچه را که باید انجام دهد برای بارگیری صفحه تولید می کند. این تجسم به عنوان اثری گفته می شود.

   

ردیابی فعالیت را به صورت زمانی ، از چپ به راست نشان می دهد. نمودارهای FPS ، CPU و NET در بالا ، نمای کلی از فریم در ثانیه ، فعالیت CPU و فعالیت شبکه را به شما می دهد.

دیوار زرد که در بخش نمای کلی مشاهده می کنید به این معنی است که CPU کاملاً مشغول فعالیت برنامه نویسی بود. این سرنخی است که ممکن است با انجام کارهای کمتری JavaScript بتوانید بار صفحه را سرعت بخشید.

اثری را برای یافتن راه هایی برای انجام کار کمتری JavaScript بررسی کنید:

1. برای گسترش آن ، روی بخش Timings کلیک کنید.

   

   یک دسته از اقدامات زمان بندی کاربر از React وجود دارد ، به نظر می رسد برنامه تونی از حالت توسعه React استفاده می کند. جابجایی به حالت تولید React احتمالاً برنده عملکرد آسان خواهد بود.

2. برای فروپاشی آن بخش ، دوباره روی زمان بندی کلیک کنید.

3. بخش اصلی را مرور کنید. در این بخش یک گزارش زمانی از فعالیت نخ اصلی ، از چپ به راست نشان داده شده است. محور y (از بالا به پایین) نشان می دهد که چرا وقایع رخ داده است.

   

   در این مثال ، رویداد Evaluate Script باعث شده است که عملکرد (anonymous) اجرا شود ، که باعث شد __webpack__require__ اجرا شود ، که باعث اجرای آن شد ./src/index.jsx و غیره.

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

   

   در این برنامه ، به نظر می رسد تابعی به نام App باعث ایجاد تماس های زیادی به عملکرد mineBitcoin می شود. به نظر می رسد که تونی ممکن است از دستگاه های طرفدارانش برای رمزنگاری من استفاده کند ...

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

5. برگه پایین به بالا را در پایین باز کنید. این برگه تجزیه و تحلیل می کند که چه فعالیتهایی بیشترین زمان را به خود اختصاص داده است. اگر در بخش پایین به بالا چیزی نمی بینید ، روی Label for Main Care کلیک کنید.

   

   بخش پایین به بالا فقط اطلاعات مربوط به هر فعالیت یا گروهی از فعالیت را نشان می دهد ، شما در حال حاضر انتخاب کرده اید. به عنوان مثال ، اگر روی یکی از فعالیت های mineBitcoin کلیک کرده اید ، بخش از پایین به بالا فقط می خواهد اطلاعاتی را برای آن یک فعالیت نشان دهد.

   ستون زمان خود به شما نشان می دهد که چقدر زمان به طور مستقیم در هر فعالیت می گذرد. در این حالت ، حدود 82 ٪ از زمان اصلی نخ برای عملکرد mineBitcoin صرف شده است.

زمان برای دیدن اینکه آیا استفاده از حالت تولید و کاهش فعالیت JavaScript باعث افزایش بار صفحه می شود. با حالت تولید شروع کنید:

1. در برگه ویرایشگر ، webpack.config.js باز کنید.
2. تغییر "mode":"development" به "mode":"production" .
3. منتظر بمانید تا ساخت جدید مستقر شود.

4. دوباره صفحه را حسابرسی کنید.

   

با حذف تماس با mineBitcoin ، فعالیت JavaScript را کاهش دهید:

1. در برگه ویرایشگر ، src/App.jsx را باز کنید.
2. تماس با this.mineBitcoin(1500) در constructor نظر دهید.
3. منتظر بمانید تا ساخت جدید مستقر شود.
4. دوباره صفحه را حسابرسی کنید.

مثل همیشه ، هنوز هم کارهایی وجود دارد که باید انجام شود ، به عنوان مثال ، بزرگترین رنگ محتوا و معیارهای تغییر چیدمان تجمعی را کاهش می دهد.

موفقیت: اما به نظر می رسد آخرین تغییر باعث پرش گسترده عملکرد شد!

انجام کار بیشتر موضوع اصلی در دنیای واقعی

به طور کلی ، پانل عملکرد متداول ترین روش برای درک فعالیت سایت شما در هنگام بارگیری است و راه هایی برای حذف فعالیت های غیر ضروری پیدا می کند.

اگر رویکردی را ترجیح می دهید که بیشتر شبیه console.log() باشد ، API زمانبندی کاربر به شما امکان می دهد تا به طور خودسرانه مراحل خاصی از چرخه برنامه خود را علامت گذاری کنید تا بتوانید هر یک از این مراحل را چه مدت طول بکشد.

خلاصه

• هر زمان که برای بهینه سازی عملکرد بار یک سایت تصمیم گرفتید ، همیشه با یک حسابرسی شروع کنید. حسابرسی یک پایه را تعیین می کند و نکاتی در مورد چگونگی بهبود به شما ارائه می دهد.
• یک بار یک تغییر ایجاد کنید و بعد از هر تغییر ، صفحه را ممیزی کنید تا ببینید که چگونه این تغییر منزوی بر عملکرد تأثیر می گذارد.

مراحل بعدی

ممیزی ها را در سایت خود اجرا کنید! اگر به تفسیر گزارش خود یا یافتن راه هایی برای بهبود عملکرد بار خود نیاز دارید ، تمام راه های دریافت کمک از جامعه DevTools را بررسی کنید:

• اشکالات مربوط به این Doc را در مخزن Developer.Chrome.com .
• گزارش اشکال در مورد DevTools در Chromium Bugs .
• در مورد ویژگی ها و تغییرات در لیست پستی بحث کنید. لطفاً برای سوالات پشتیبانی از لیست پستی استفاده نکنید. در عوض از Overflow Stack استفاده کنید.
• در مورد نحوه استفاده از DevTools در پشته سرریز کمک کلی کنید. برای ثبت درخواست اشکال ، همیشه از اشکالات کروم استفاده کنید.
• توییت ما را در chromedevtools .