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

Kayce Basques

Sofia Emelianova

نمای کلی

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

• عملکرد
• دسترسی
• بهترین شیوه ها
• سئو

... و بسیاری از معیارهای دیگر.

آموزش زیر به شما کمک می کند تا با Lighthouse در Chrome DevTools شروع کنید.

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

هدف آموزش

این آموزش به شما می آموزد که چگونه از 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. روی refresh Reload کلیک کنید. برگه 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. روی refresh Reload کلیک کنید. 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

نمای کلی

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

• عملکرد
• دسترسی
• بهترین شیوه ها
• سئو

... و بسیاری از معیارهای دیگر.

آموزش زیر به شما کمک می کند تا با Lighthouse در Chrome DevTools شروع کنید.

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

هدف آموزش

این آموزش به شما می آموزد که چگونه از 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. روی refresh Reload کلیک کنید. برگه 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. روی refresh Reload کلیک کنید. 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

نمای کلی

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

• عملکرد
• دسترسی
• بهترین شیوه ها
• سئو

... و بسیاری از معیارهای دیگر.

آموزش زیر به شما کمک می کند تا با Lighthouse در Chrome DevTools شروع کنید.

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

هدف آموزش

این آموزش به شما می آموزد که چگونه از 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. روی refresh Reload کلیک کنید. برگه 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. روی refresh Reload کلیک کنید. 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

نمای کلی

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

• عملکرد
• دسترسی
• بهترین شیوه ها
• سئو

... و بسیاری از معیارهای دیگر.

آموزش زیر به شما کمک می کند تا با Lighthouse در Chrome DevTools شروع کنید.

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

هدف آموزش

این آموزش به شما می آموزد که چگونه از 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. روی refresh Reload کلیک کنید. برگه 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. روی refresh Reload کلیک کنید. 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 توییت کنید.