برنامه نویسی

عملکرد بار اولیه برای توسعه دهندگان React: غواصی عمیق تحقیق

شرح تصویر

فهرست مطالب

  1. معرفی معیارهای عملکرد اولیه بار

  2. نمای کلی از Devtools Performance

    1. راه اندازی پروژه

    2. کاوش در مورد devtools لازم

  3. کاوش در شرایط مختلف شبکه

    1. سرور بسیار کند

    2. از پهنای باند و تأخیر مختلف تقلید می کند

    3. اهمیت CDN

  4. عملکرد بازدید را تکرار کنید

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

    2. Cache-Montrol و Bundlers مدرن

    3. آیا واقعاً باید همه اینها را برای مورد استفاده ساده خود بدانم؟

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

بنابراین ، بیایید امروز روی ساخت برنامه ها تمرکز کنیم. و برای انجام این کار ، ما باید برای مدتی در خارج از واکنش قرار بگیریم. از آنجا که قبل از ساختن سریع ، ابتدا باید بدانیم که “سریع” چیست ، چگونه می توان آن را اندازه گیری کرد و چه چیزی می تواند بر این “استحکام” تأثیر بگذارد.

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

چه اتفاقی می افتد که مرورگر خود را باز می کنم و سعی می کنم به وب سایت مورد علاقه خود حرکت کنم؟ من “http://www.my-website.com” را در نوار آدرس تایپ می کنم ، مرورگر درخواست دریافت را به سرور ارسال می کند و در عوض یک صفحه HTML دریافت می کند.

شرح تصویر

زمان لازم برای انجام این کار به عنوان “زمان به اولین بایت” (TTFB) شناخته می شود: زمان بین زمان ارسال درخواست و زمان رسیدن نتیجه. پس از دریافت HTML ، مرورگر اکنون مجبور است این HTML را در اسرع وقت به یک وب سایت قابل استفاده تبدیل کند.

این کار با ارائه روی صفحه نمایش شروع می شود که به عنوان “مسیر بحرانی” شناخته می شود: حداقل و مهمترین محتوایی که می تواند برای کاربر نشان داده شود.

شرح تصویر

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

سازش به این شکل است. مرورگر فرض می کند که برای ساختن “مسیر بحرانی” ، حداقل به آن نوع منابع نیاز دارد:

  • HTML اولیه که از سرور دریافت می کند – برای ساخت عناصر DOM واقعی که از آن تجربه ساخته شده است.
  • پرونده های مهم CSS که سبک آن عناصر اولیه – در غیر این صورت ، اگر بدون انتظار برای آنها پیش برود ، کاربر در همان ابتدا “فلاش” عجیب و غریب از محتوای بی نظیر را مشاهده می کند.
  • پرونده های JavaScript بحرانی که به طور همزمان طرح را تغییر می دهند.

اولین مورد (HTML) مرورگر در درخواست اولیه از سرور دریافت می کند. این کار را تجزیه می کند ، و در حالی که این کار را انجام می دهد پیوندهایی را به پرونده های CSS و JS برای تکمیل “مسیر بحرانی” نیاز دارد. سپس درخواست ها را برای دریافت آنها از سرور ارسال می کند ، منتظر می ماند تا بارگیری شود ، آنها را پردازش می کند ، همه این موارد را با هم ترکیب می کند و در پایان در پایان ، پیکسل های “مسیر بحرانی” را روی صفحه نقاشی می کند.

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

  • بیشتر CSS ، چه درون خطی و چه از طریق برچسب.
  • منابع جاوا اسکریپت در tag that are not async یا deferredبشر

روند کلی ارائه “مسیر بحرانی” چیزی شبیه به این (تقریباً) است:

  • مرورگر تجزیه HTML اولیه را شروع می کند
  • در حین انجام این کار ، پیوندهایی را به منابع CSS و JS از tag.
  • Then, it kicks off the downloading process and waits for blocking resources to finish the download.
  • While waiting, it continues with processing HTML if possible.
  • After all the critical resources are received, they are processed as well.
  • And finally, it finishes whatever needs to be done and paints the actual pixels of the interface.

This point in time is what we know as First Paint (FP). It’s the very first time the user has an opportunity to see something on the screen. Whether it will happen or not depends on the HTML the server sent. If there is something meaningful there, like a text or an image, then this point will also be when the First Contentful Paint (FCP) happened. If the HTML is just an empty div, then the FCP will happen later.

شرح تصویر

First Contentful Paint (FCP) is one of the most important performance metrics since it measures perceived initial load. Basically, it is the user’s first impression of how fast your website is.

Until this moment, the users are just biting their nails while staring at the blank screen. According to Google, a good FCP number is below 1.8 seconds. After that, the users will start losing interest in what your website can offer and might start leaving.

However, FCP is not perfect. If the website starts its load with a spinner or some loading screen, the FCP metric will represent that. But it’s highly unlikely that the user navigated to the website just to check out the fancy loading screen. Most of the time, they want to access the content.

For this, the browser needs to finish the work it started. It waits for the rest of the non-blocking JavaScript, executes it, applies changes that originated from it to the DOM on the screen, downloads images, and otherwise polishes the user experience.

Somewhere during this process is when the Largest Contentful Paint (LCP) time happens. Instead of the very first element, like FCP, it represents the main content area on the page – the largest text, image, or video visible in the viewport. According to Google, this number ideally should be below 2.5 seconds. More than that, and the users will think the website is slow.

توضیحات تصویر

همه این معیارها بخشی از وب سایت های Google هستند – مجموعه ای از معیارهایی که نشان دهنده تجربه کاربر در یک صفحه است. LCP یکی از این سه است ویتای اصلی وب – سه معیار که بخش های مختلف تجربه کاربر را نشان می دهد. LCP مسئول عملکرد بارگیریبشر

این معیارها را می توان با استفاده از لایت هاوس اندازه گیری کرد. Lighthouse یک ابزار عملکرد Google است که در Chrome Devtools یکپارچه شده است و همچنین می تواند از طریق اسکریپت پوسته ، رابط وب یا ماژول گره اجرا شود. شما می توانید از آن به صورت ماژول گره استفاده کنید تا آن را در داخل ساخت خود اجرا کنید و رگرسیون را قبل از تولید آنها تشخیص دهید. از نسخه یکپارچه DevTools برای اشکال زدایی و آزمایش محلی استفاده کنید. و نسخه وب برای بررسی عملکرد رقبا.

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

برای این موضوع خاص ، من ساده ترین راه برای درک کامل مفاهیم ، شبیه سازی سناریوهای مختلف در یک صفحه نیمه واقعی و دیدن چگونگی تغییر نتیجه هستند. بنابراین بیایید قبل از انجام تئوری حتی بیشتر این کار را انجام دهیم (و چیزهای بیشتری وجود دارد!).

راه اندازی پروژه

در صورت تمایل می توانید تمام شبیه سازی های زیر را در پروژه خود انجام دهید – نتایج باید کم و بیش یکسان باشد. برای یک محیط کنترل شده تر و ساده تر ، با این حال ، توصیه می کنم از یک پروژه مطالعه ای که برای این مقاله آماده کرده ام استفاده کنید. می توانید به اینجا دسترسی پیدا کنید: https://github.com/developerway/initial-load-performance

با نصب همه وابستگی ها شروع کنید:

npm install
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

ساخت پروژه:

npm run build
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

و شروع سرور:

npm run start
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

شما باید یک صفحه داشبورد خوب را در “http: // localhost: 3000” مشاهده کنید.

کاوش در مورد devtools لازم

وب سایتی را که می خواهید در Chrome تجزیه و تحلیل کنید باز کنید و Devtools Chrome را باز کنید. پانل های “عملکرد” ​​و “فانوس دریایی” را در آنجا پیدا کنید و آنها را به هم نزدیک کنید. ما به هر دوی آنها احتیاج خواهیم داشت.

همچنین ، قبل از انجام هر کار دیگری در این مقاله ، حتماً کادر انتخاب “Disable Cache” را فعال کرده اید. این باید در صفحه شبکه در بالا باشد.

شرح تصویر

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

کاوش در صفحه فانوس دریایی

اکنون صفحه فانوس دریایی را باز کنید. شما باید چند تنظیمات را در آنجا مشاهده کنید و دکمه “تجزیه و تحلیل صفحه بار” را مشاهده کنید.

شرح تصویر

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

شرح تصویر

عملکرد محلی عالی است ، جای تعجب ندارد – همه چیز همیشه “روی دستگاه من کار می کند”.

معیارهایی مانند این نیز وجود خواهد داشت:

شرح تصویر

مقادیر FCP و LCP که برای این مقاله به آن نیاز داریم درست در بالا است.

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

شرح تصویر

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

با این حال ، Lighthouse فقط اطلاعات سطح سطح را به شما می دهد و به شما امکان نمی دهد سناریوهای مختلف مانند یک شبکه آهسته یا CPU کم را شبیه سازی کنید. این فقط یک نقطه ورود عالی و ابزاری عالی برای ردیابی تغییرات عملکرد در طول زمان است. برای حفر عمیق تر به آنچه اتفاق می افتد ، ما به “عملکرد” پانل.

کاوش در صفحه عملکرد

هنگامی که برای اولین بار بارگیری شد ، پانل عملکرد باید چیزی شبیه به این باشد:

شرح تصویر

این سه معیارهای اصلی وب ویتامان را نشان می دهد که یکی از آنها LCP ما است ، به شما امکان شبیه سازی شبکه آهسته و CPU و امکان ضبط جزئیات عملکرد در طول زمان را می دهد.

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

این گزارش چند بخش خواهد داشت.

در بالاترین سطح ژنرال “جدول زمانی نمای کلی “ بخش

شرح تصویر

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

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

شرح تصویر

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

  • در ابتدا ، بلوک آبی وجود دارد – درخواستی برای دریافت HTML برای وب سایت
  • پس از اتمام بارگیری ، پس از کمی مکث (برای تجزیه HTML) ، دو درخواست برای منابع بیشتر بیرون می روند.
  • یکی از آنها (زرد) برای JavaScript است – مسدود کردن.
  • یکی دیگر (بنفش) برای CSS است ، و این یکی مسدود شده است.

اگر کد پروژه مطالعه خود را اکنون باز کرده و به داخل نگاه کنید dist پوشه ، کد منبع با این رفتار مطابقت دارد:

  • وجود خواهد داشت index.html پرونده .css وت .js پرونده های داخل assets پوشه
  • در داخل index.html پرونده در section, there will be a برچسب آن را به پرونده CSS نشان دهید. همانطور که می دانیم ، منابع CSS در مسدود کننده هستند ، به طوری که بررسی می شود.
  • همچنین ، داخل وجود دارد

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا