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

فهرست مطالب
-
معرفی معیارهای عملکرد اولیه بار
-
نمای کلی از Devtools Performance
-
راه اندازی پروژه
-
کاوش در مورد devtools لازم
-
-
کاوش در شرایط مختلف شبکه
-
سرور بسیار کند
-
از پهنای باند و تأخیر مختلف تقلید می کند
-
اهمیت CDN
-
-
عملکرد بازدید را تکرار کنید
-
کنترل حافظه نهان مرورگر با هدرهای کنترل حافظه نهان
-
Cache-Montrol و Bundlers مدرن
-
آیا واقعاً باید همه اینها را برای مورد استفاده ساده خود بدانم؟
-
این روزها ، با رونق تولید کد 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 در
مسدود کننده هستند ، به طوری که بررسی می شود.
- همچنین ، داخل
وجود دارد
tag that points to the JavaScript file inside the
asset
folder. It’s neither deferred nor async, but it hastype="module"
. Those are deferred automatically, so this also checks out – the JavaScript file in the panel is non-blocking.
Additional Exercise
If you have a project you’re working on, record the initial load performance for it and look into the Network panel. You’ll likely see many more resources downloaded.
- How many render-blocking resources do you have? Are all of them necessary?
- Do you know where the “entry” point for your project is and how blocking resources appear in the
section? Try building the project with your variation of
npm build
and search for them. Hint:- If you have a pure webpack-based project, look for
webpack.config.js
file. Paths to the HTML entry points should be inside. - if you’re on Vite, look into
dist
folder – same as with the study project - if you’re on the Next.js App router – take a peek into
.next/server/app
- If you have a pure webpack-based project, look for
Under the Network section, you can find the Frames and Timing sections.
Those are very cool. In the Timing section, you can see all the metrics we discussed before (FP, FCP, LCP), plus a few more we haven’t yet. When hovering over the metrics, you can see the exact time it took. Clicking on them will update the “summary” tab at the very bottom, where you’ll find information on what this metric is and a link to learn more. DevTools are all about educating people these days.
And finally, the Main section. This is what is happening in the main thread during the timeline recorded.
ما می توانیم چیزهایی مانند “پارس HTML” یا “چیدمان” را ببینیم و چه مدت طول کشید. چیزهای زرد مربوط به جاوا اسکریپت است و از آنجا که ما از ساخت تولید با JavaScript فشرده استفاده می کنیم کمی بی فایده هستند. اما حتی در این حالت ، این ایده خشن را به ما می دهد که چه مدت اجرای JavaScript در مقایسه با HTML تجزیه و به عنوان مثال ترسیم می کند.
این به ویژه برای تجزیه و تحلیل عملکرد در هر دو مفید است شبکه وت اصلی باز و زوم شده اند تا تمام صفحه را بگیرند.
از اینجا می توانم ببینم که یک سرور فوق العاده سریع و بسته های سریع و کوچک دارم. هیچ یک از وظایف شبکه یک تنگنا نیست. آنها زمان قابل توجهی را نمی گذارند و بین آنها ، مرورگر فقط سرد است و کارهای خاص خود را انجام می دهد. بنابراین ، اگر می خواستم بار اولیه را در اینجا سرعت دهم ، باید بررسی کنم که چرا پارس HTML بسیار کند است – این طولانی ترین کار در نمودار است.
یا اگر به اعداد مطلق نگاه کنیم – من نباید در اینجا کاری انجام دهم ، از نظر عملکرد. کل بار اولیه کمتر از 200 میلی متر طول می کشد و از آستانه توصیه شده Google استفاده می شود 🙂 اما این اتفاق می افتد زیرا من این تست را بصورت محلی اجرا می کنم (بنابراین هیچ هزینه واقعی شبکه ندارد) ، بر روی یک لپ تاپ بسیار سریع و با یک سرور بسیار اساسی.
زمان شبیه سازی زندگی واقعی.
سرور بسیار کند
اول از همه ، بیایید سرور را واقع بینانه تر کنیم. در حال حاضر ، اولین مرحله “آبی” در حدود 50ms طول می کشد ، 40ms که فقط در انتظار آن است.
در زندگی واقعی ، سرور کارها را انجام می دهد ، مجوزها را بررسی می کند ، مواد تولید می کند ، دو بار مجوزها را بررسی می کند (زیرا کد میراث زیادی دارد و بررسی سه گانه گم شده است) ، و در غیر این صورت شلوغ خواهد بود.
حرکت به backend/index.ts
پرونده در پروژه مطالعه خود (https://github.com/developerway/initial-load-performance). نظر داده شده را پیدا کنید // await sleep(500)
، و آن را از بین نبرید. این امر قبل از بازگشت HTML به سرور 500ms می دهد – به نظر می رسد برای یک سرور قدیمی و پیچیده به اندازه کافی منطقی است.
دوباره ساخت پروژه (npm run build
) ، دوباره شروع کنید (npm run start
) و ضبط مجدد عملکرد را دوباره اجرا کنید.
هیچ چیز در جدول زمانی به جز خط آبی اولیه تغییر نکرده است – اکنون در مقایسه با بقیه مواد بسیار طولانی است.
این وضعیت اهمیت نگاه به کل تصویر و شناسایی تنگناها را قبل از انجام هرگونه بهینه سازی عملکرد برجسته می کند. مقدار LCP 650 میلیون پوند است که از این تعداد 560 میلیون پوند در انتظار HTML اولیه صرف می شود. بخش React از آن در حدود 50ms است. حتی اگر من به نوعی بتوانم آن را نصف کنم و آن را به 25 متر کاهش دهم ، در تصویر کلی ، فقط 4 ٪ خواهد بود. و کاهش آن به نصف نیاز دارد خیلی تلاش در اینجا یک استراتژی بسیار مؤثرتر ممکن است تمرکز روی سرور و فهمیدن چرا اینقدر کند باشد.
از پهنای باند و تأخیر مختلف تقلید می کند
همه در دنیای یک ارتباط 1 گیگابیت زندگی نمی کنند. به عنوان مثال ، در استرالیا ، 50 مگابیت در ثانیه یکی از اتصالات اینترنتی با سرعت بالا است و برای شما حدود 90 دلار استرالیا در ماه هزینه خواهد کرد. البته این 3G نیست که بسیاری از مردم در سراسر جهان با آنها گیر کرده اند. اما با این وجود ، من هر بار که می شنوم مردم در اروپا می شنوم که در مورد برنامه های 1 گیگابیت/دوم یا اینترنتی برای 10 یورو لاف می زنند.
به هر حال بیایید این اینترنت نه چندان عالی استرالیا را تقلید کنیم و ببینیم با معیارهای عملکرد چه اتفاقی خواهد افتاد. برای این کار ، ضبط موجود را در برگه عملکرد پاک کنید (دکمه نزدیک بارگیری مجدد و ضبط). پانل با تنظیمات شبکه باید نشان داده شود:
اگر در نسخه Chrome شما وجود ندارد ، همان تنظیمات باید در برگه شبکه در دسترس باشد.
با شماره های زیر یک پروفایل جدید در کشویی “شبکه” اضافه کنید:
- نام پروفایل: “پهنای باند متوسط اینترنت”
- بارگیری: 50000 (50 مگابیت در ثانیه)
- بارگذاری: 15000 (15 مگابیت در ثانیه)
- تأخیر: 40 (تقریباً متوسط برای اتصال عمومی اینترنت)
اکنون آن نمایه را در کشویی انتخاب کرده و دوباره ضبط عملکرد را دوباره اجرا کنید.
چه می بینی؟ برای من ، به نظر می رسد اینگونه است.
LCP مقدار به سختی تغییر کرده است – افزایش جزئی از 640ms به 700ms. هیچ چیز در قسمت اولیه “سرور” آبی تغییر نکرده است ، که قابل توضیح است: این فقط حداقل HTML لخت را ارسال می کند ، بنابراین برای بارگیری آن طول نمی کشد.
اما رابطه بین منابع قابل بارگیری و موضوع اصلی به طرز چشمگیری تغییر کرد.
من به وضوح می توانم تأثیر آن را ببینم CSS مسدود کننده اکنون پرونده در تجزیه HTML کار از قبل به پایان رسیده است ، اما مرورگر در حال سرد شدن است و منتظر CSS است – تا زمان بارگیری ، هیچ چیز قابل نقاشی نیست. آن را با تصویر قبلی مقایسه کنید ، جایی که منابع تقریباً فوراً بارگیری می شوند در حالی که مرورگر در حال تجزیه HTML بود.
پس از آن ، از نظر فنی ، مرورگر می توانست چیزی را نقاشی کند – اما چیزی وجود ندارد ، ما فقط یک بخش خالی را در پرونده HTML می فرستیم. بنابراین مرورگر با انتظار ادامه می یابد تا پرونده JavaScript بارگیری شود و قابل اجرا باشد.
این فاصله تقریباً 60ms انتظار دقیقاً افزایش در LCP که من می بینم
سرعت را حتی بیشتر کاهش دهید تا ببینید که چگونه پیشرفت می کند. برای بارگیری و بارگذاری ، یک پروفایل شبکه جدید با 10Mbps/1Mbps ایجاد کنید ، 40 تاخیر را نگه دارید و آن را “پهنای باند اینترنت پایین” نامگذاری کنید.
و دوباره آزمون را اجرا کنید.
اکنون مقدار LCP به تقریباً 500 میلی ثانیه افزایش یافته است. بارگیری JavaScript تقریباً 300 میلی ثانیه طول می کشد. و وظایف اجرای JavaScript و کارهای JavaScript در اهمیت نسبتاً صحبت می کنند.
ورزش اضافی
اگر پروژه خود را دارید ، سعی کنید این تست را روی آن اجرا کنید.
- چه مدت طول می کشد تا تمام منابع مهم مسیر را بارگیری کنید؟
- چه مدت طول می کشد تا تمام پرونده های JavaScript بارگیری شود؟
- این بارگیری پس از کار تجزیه و تحلیل HTML چه مقدار از شکاف ایجاد می کند؟
- وظایف اجرای Parse HTML و JavaScript در موضوع اصلی نسبت به بارگیری منابع چقدر بزرگ است؟
- چگونه بر متریک LCP تأثیر می گذارد؟
آنچه در داخل نوار منابع اتفاق می افتد نیز بسیار جالب است. روی نوار جاوا اسکریپت زرد شناور شوید. شما باید چیزی شبیه به این را در آنجا ببینید:
جالب ترین قسمت در اینجا “درخواست ارسال و انتظار” است که تقریباً 40 میلی ثانیه طول می کشد. روی بقیه منابع شبکه شناور – همه آنها آن را خواهند داشت. این تأخیر ما ، تأخیر در شبکه است که ما 40 را تنظیم کردیم. بسیاری از چیزها می توانند بر تعداد تأخیر تأثیر بگذارند. نوع اتصال شبکه یکی از آنهاست. به عنوان مثال ، یک اتصال 3G به طور متوسط پهنای باند 10/1 مگابیت بر ثانیه و تأخیر بین 100 تا 300 میلی ثانیه خواهد داشت.
برای تقلید از آن ، یک پروفایل شبکه جدید ایجاد کنید ، آن را “میانگین 3G” بنامید ، شماره های بارگیری/بارگذاری را از پروفایل “پهنای باند اینترنت پایین” کپی کرده و تأخیر را روی 300 میلی ثانیه تنظیم کنید.
دوباره پروفایل را اجرا کنید. تمام منابع شبکه باید “درخواست ارسال شده و انتظار” به حدود 300 میلی ثانیه افزایش یابد. این فشار را تحت فشار قرار می دهد LCP شماره حتی بیشتر: 1.2 ثانیه برای من
و اکنون بخش سرگرم کننده: اگر پهنای باند را به سرعت های فوق العاده بالا برگردانم اما تأخیر کم را حفظ کنم ، چه اتفاقی خواهد افتاد؟ بیایید این تنظیم را امتحان کنیم:
- بارگیری کردن: 1000 مگابیت در ثانیه
- بارگذاری کردن: 100 مگابیت در ثانیه
- عوارض: 300 ms
اگر سرورهای شما در جایی در نروژ باشند ، به راحتی می تواند اتفاق بیفتد ، اما مشتری ها استرالیایی ثروتمند هستند.
این نتیجه است:
در LCP تعداد اطراف است 960msبشر این بدتر از کمترین سرعت اینترنت است که قبلاً امتحان کردیم! در این سناریو ، اندازه بسته نرم افزاری اهمیتی ندارد و اندازه CSS به هیچ وجه اهمیتی ندارد. حتی اگر هر دو را نصف کنید ، متریک LCP به سختی حرکت خواهد کرد. تأخیر بالا همه چیز را برطرف می کند.
این امر من را به اولین بهبود عملکردی که همه باید در صورتی که هنوز اجرا نکرده اند ، به وجود می آورد. به آن گفته می شود “اطمینان حاصل کنید که منابع استاتیک هستند همیشه از طریق CDN سرو می شود. “
اهمیت CDN
CDN اساساً یک مرحله 0 در هر عملکردی در رابطه با عملکرد است ، قبل از اینکه حتی در مورد چیزهای فانتزی بیشتر مانند تقسیم کد یا اجزای سرور فکر کنید.
هدف اصلی هر CDN (شبکه تحویل محتوا) کاهش تأخیر و تحویل محتوا به کاربر نهایی در اسرع وقت است. آنها چندین استراتژی را برای این کار پیاده سازی می کنند. دو مورد مهم این مقاله “سرورهای توزیع شده” و “ذخیره” هستند.
یک ارائه دهنده CDN چندین سرور در مکان های مختلف جغرافیایی خواهد داشت. این سرورها می توانند یک نسخه از منابع استاتیک شما را ذخیره کرده و در صورت درخواست مرورگر آنها را به کاربر ارسال کنند. CDN اساساً یک لایه نرم در اطراف سرور Origin شما است که آن را از نفوذ بیرونی محافظت می کند و تعامل آن با جهان خارج را به حداقل می رساند. این نوع مانند یک دستیار هوش مصنوعی برای یک درونگرا است ، که می تواند مکالمات معمولی را بدون نیاز به درگیر کردن شخص واقعی انجام دهد.
در مثال بالا ، جایی که ما در نروژ و مشتری در استرالیا سرودهایی داشتیم ، این تصویر را داشتیم:
با استفاده از CDN در بین ، تصویر تغییر می کند. CDN سرور را در جایی نزدیک به کاربر خواهد داشت ، بیایید بگوییم در جایی در استرالیا نیز هست. در بعضی از مواقع ، CDN نسخه هایی از منابع استاتیک را از سرور Origin دریافت می کند. پس از انجام این کار ، هر کاربری از استرالیا یا هرجای نزدیک به آن ، این نسخه ها را به جای اصل از سرور در نروژ دریافت می کند.
این به دو چیز مهم دست می یابد. اول ، بار در سرور Origin کاهش می یابد زیرا کاربران دیگر نیازی به دسترسی مستقیم به آن ندارند. و دوم ، کاربران اکنون این منابع را خیلی سریعتر دریافت می کنند زیرا برای بارگیری چند پرونده JavaScript دیگر مجبور نیستند به اقیانوس ها برسند.
و مقدار LCP در شبیه سازی ما در بالا افت می کند از 960ms به 640msبشر
تاکنون ، ما فقط در مورد عملکرد بازدید برای اولین بار صحبت کرده ایم – عملکرد برای افرادی که هرگز در وب سایت شما نبوده اند. اما امیدوارم که این وب سایت به قدری خوب باشد که بیشتر این بازدید کنندگان بار اول به منظم تبدیل می شوند. یا حداقل آنها بعد از اولین بار ترک نمی کنند ، از طریق چند صفحه حرکت می کنند و شاید چیزی بخرند. در این حالت ، ما معمولاً انتظار داریم که مرورگرها منابع استاتیک مانند CSS و JS را ذخیره کنند – یعنی یک نسخه از آنها را به صورت محلی ذخیره کنید نه اینکه همیشه آنها را بارگیری کنید.
بیایید نگاهی بیندازیم که چگونه نمودارها و شماره های عملکرد در این سناریو تغییر می کنند.
دوباره پروژه مطالعه را باز کنید. در ابزارهای Dev ، شبکه را روی “میانگین 3G” که قبلاً ایجاد کردیم تنظیم کنیم – با تأخیر زیاد و پهنای باند پایین ، فقط بنابراین می توانیم تفاوت را فوراً ببینیم. و اطمینان حاصل کنید که کادر انتخاب “Disable Network Cache” بررسی نشده است.
ابتدا مرورگر را تازه کنید تا مطمئن شوید که ما وضعیت بازدید کننده بار اول را از بین می بریم. و سپس عملکرد را تازه و اندازه گیری کنید.
اگر از پروژه مطالعه استفاده می کنید ، نتیجه نهایی باید کمی تعجب آور باشد زیرا به نظر می رسد:
پرونده های CSS و JavaScript هنوز هم در برگه شبکه بسیار برجسته هستند ، و من 300 میلیون پوند را برای هر دوی آنها در “درخواست ارسال شده و انتظار” می بینم – تنظیم تأخیر که در مشخصات “میانگین 3G” داریم. در نتیجه ، LCP به اندازه ممکن پایین نیست و من وقتی مرورگر فقط منتظر CSS مسدود کننده است ، شکاف 300ms دارم.
چه اتفاقی افتاد؟ آیا مرورگر قرار نبود آن چیزها را ذخیره کند؟
کنترل حافظه نهان مرورگر با هدرهای کنترل حافظه نهان
اکنون باید از پنل شبکه استفاده کنیم تا بفهمیم چه خبر است. آن را باز کنید و پرونده CSS را در آنجا پیدا کنید. باید چیزی شبیه به این باشد:
جالب ترین چیزها در اینجا ستون “وضعیت” و “اندازه” است. در “اندازه” قطعاً اندازه کل پرونده CSS نیست. خیلی کوچک است و در “وضعیت” ، این وضعیت عادی 200 “همه خوب است” ما نیست ، بلکه چیزی متفاوت است – 304 وضعیت.
دو سوال در اینجا – چرا 304 به جای 200 ، و چرا درخواست اصلاً ارسال شد؟ چرا حافظه پنهان کار نکرد؟
اول از همه ، پاسخ 304 این پاسخی است که یک سرور کاملاً پیکربندی شده برای درخواست های مشروط ارسال می کند – جایی که پاسخ بر اساس قوانین مختلف متفاوت است. درخواست هایی مانند این اغلب برای کنترل حافظه نهان مرورگر استفاده می شود.
به عنوان مثال ، هنگامی که سرور درخواستی برای پرونده CSS دریافت می کند ، می تواند بررسی کند که آخرین بار پرونده اصلاح شده است. اگر این تاریخ همانند پرونده نقدی در سمت مرورگر باشد ، 304 را با بدن خالی برمی گرداند (به همین دلیل فقط 223 B است). این به مرورگر نشان می دهد که فقط استفاده مجدد از پرونده ای که قبلاً دارد ، بی خطر است. نیازی به هدر دادن پهنای باند و بارگیری مجدد آن نیست.
به همین دلیل ما شماره بزرگ “درخواست ارسال شده و انتظار” را در تصویر عملکرد می بینیم-مرورگر از سرور می خواهد تا تأیید کند که آیا پرونده CSS هنوز به روز است یا خیر. و به همین دلیل است که “بارگیری محتوا” 0.33ms وجود دارد – سرور با “304 اصلاح نشده” پاسخ داد و مرورگر فقط از پرونده ای که قبلاً بارگیری کرده بود دوباره استفاده کرد.
ورزش اضافی
-
در پروژه مطالعه ، به
dist/assets
پوشه و تغییر نام پرونده CSS -
رفتن به
dist/index.html
پرونده را به پرونده CSS تغییر نام دهید و به روز کنید -
صفحه را که قبلاً باز شده است با برگه شبکه باز شده ، باید ببینید که پرونده CSS با نام جدید ، 200 وضعیت و اندازه مناسب ظاهر می شود – دوباره بارگیری شد. این به عنوان “حافظه پنهان” شناخته می شود-راهی برای مجبور کردن مرورگر برای بارگیری مجدد منابعی که ممکن است ذخیره کرده باشد.
- دوباره صفحه را تازه کنید – به وضعیت 304 باز می گردد و از پرونده ذخیره شده دوباره استفاده می کند.
حالا ، به سوال دوم – چرا این درخواست اصلاً ارسال شد؟
این رفتار توسط عنوان حافظه نهان کنترل سرور کنترل می شود. برای دیدن جزئیات درخواست/پاسخ ، روی پرونده CSS در پنل شبکه کلیک کنید. مقدار “Cache-Control” را در برگه “هدر” در بلوک “هدر پاسخ” پیدا کنید:
در داخل این عنوان می تواند چندین دستورالعمل در ترکیب های مختلف باشد که توسط یک کاما از هم جدا شده است. در مورد ما ، دو مورد وجود دارد:
- حداکثر سن با یک عدد – این پاسخ خاص را برای چه مدت (در ثانیه) کنترل می کند
- باید تأیید کند – این مرورگر را راهنمایی می کند تا در صورت پاسخ دادن به نسخه تازه ، همیشه درخواست نسخه تازه را به سرور ارسال کند. اگر در حافظه نهان طولانی تر از مقدار حداکثر سن باشد ، پاسخ بی نظیر خواهد شد.
بنابراین اساساً ، آنچه این هدر به مرورگر می گوید این است:
- اشکالی ندارد که این پاسخ را در حافظه نهان خود ذخیره کنید ، اما بعد از مدتی با من دوبار بررسی کنید تا مطمئن شوید.
- به هر حال ، زمانی که می توانید آن حافظه پنهان را حفظ کنید دقیقاً است صفر ثانیه موفق باشید
در نتیجه ، مرورگر همیشه با سرور چک کنید و هرگز از حافظه نهان استفاده نکنید.
ما به راحتی می توانیم آن را تغییر دهیم ، هرچند – تنها چیزی که ما نیاز داریم تغییر آن است max-age
شماره به چیزی بین 0 تا 31536000 (یک سال ، حداکثر ثانیه مجاز). برای انجام این کار ، در پروژه مطالعه خود ، به backend/index.ts
پرونده ، کجا پیدا کنید max-age=0
تنظیم شده و آن را به 31536000 (یک سال) تغییر دهید. چند بار صفحه را تازه کنید و باید این پرونده را برای پرونده CSS در برگه شبکه مشاهده کنید:
توجه کنید که چگونه Status
ستون اکنون خاکستری شده است ، و برای Size,
ما می بینیم “(حافظه نهان)”. پرونده CSS اکنون از حافظه نهان مرورگر سرو می شود و برای بقیه سال چنین خواهد بود. چند بار صفحه را تازه کنید تا ببینید که تغییر نمی کند.
اکنون ، تا کل نقطه آشفتگی با عنوان های حافظه پنهان: بیایید دوباره عملکرد صفحه را اندازه گیری کنیم. فراموش نکنید که تنظیمات پروفایل “متوسط 3G” را تنظیم کرده و تنظیم “غیرفعال” را بدون بررسی نگه دارید.
نتیجه باید چیزی شبیه به این باشد:
قسمت “درخواست ارسال شده و انتظار” با وجود تأخیر زیاد تقریباً صفر فرو ریخت ، شکاف بین “پارس HTML” و ارزیابی JavaScript تقریباً ناپدید شد و ما برای مقدار LCP به 650ms پوند بازگشتیم.
ورزش اضافی
-
تغییر
max-age
مقدار تا 10 اکنون (10 ثانیه) - صفحه را با کادر انتخاب “Disable Cache” که برای رها کردن حافظه نهان بررسی شده است ، تازه کنید.
- کادر انتخاب را بردارید و دوباره صفحه را تازه کنید – این بار باید از حافظه نهان حافظه سرو شود.
-
10 ثانیه صبر کنید و دوباره صفحه را تازه کنید. چون
max-age
فقط 10 ثانیه است ، مرورگر این منبع را دو بار بررسی می کند و سرور دوباره 304 را برمی گرداند. - صفحه را بلافاصله تازه کنید – باید دوباره از حافظه سرو شود.
Cache-Montrol و Bundlers مدرن
آیا اطلاعات فوق به این معنی است که حافظه پنهان گلوله نقره ای عملکرد ما است و ما باید تا حد امکان همه چیز را به طرز تهاجمی ذخیره کنیم؟ مطلقاً نه! گذشته از هر چیز دیگری ، فرصتی برای ایجاد ترکیبی از “مشتریان نه فن آوری” و “نیاز به توضیح از طریق تلفن برای پاک کردن حافظه پنهان مرورگر” باعث حملات وحشت برای فصلی ترین توسعه دهندگان خواهد شد.
یک میلیون روش برای بهینه سازی حافظه نهان وجود دارد ، یک میلیون ترکیب از دستورالعمل ها در عنوان حافظه نهان در ترکیب با سایر هدرها که ممکن است یا ممکن است تأثیر بگذارد یا ممکن است در چه مدت حافظه نهان تأثیر بگذارد ، که ممکن است یا ممکن است به اجرای آن نیز بستگی نداشته باشد. سرور احتمالاً چند کتاب با ارزش اطلاعات فقط می توانند در این موضوع نوشته شوند. اگر می خواهید استاد حافظه نهان شوید ، با منابع موجود در منابع: //web.dev/ و منابع MDN شروع کنید و سپس نان های نان را دنبال کنید.
متأسفانه ، هیچ کس نمی تواند به شما بگوید ، “این پنج استراتژی بهترین حافظه پنهان برای همه چیز است.” در بهترین حالت ، پاسخ می تواند این باشد: “اگر این مورد استفاده را دارید ، در ترکیب با این ، این و این ، این ترکیب تنظیمات حافظه نهان انتخاب خوبی است ، اما به آن سکسکه ها توجه داشته باشید”. همه اینها به دانستن منابع شما ، سیستم ساخت شما ، چند بار تغییر منابع ، چقدر ایمن بودن آنها در ذخیره سازی آنها و چه عواقبی در صورت اشتباه انجام می شود.
با این حال ، یک استثنا در این مورد وجود دارد. یک استثنا به روشی که “بهترین عمل” روشن وجود دارد: فایل های JavaScript و CSS برای وب سایت های ساخته شده با ابزار مدرن. بسته های مدرن مانند Vite ، Rollup ، Webpack و غیره می توانند پرونده های JS و CSS “تغییر ناپذیر” ایجاد کنند. آنها واقعاً “تغییر ناپذیر” نیستند. اما این ابزارها نام پرونده هایی با رشته هش را ایجاد می کنند که به محتوای پرونده بستگی دارد. اگر محتوای پرونده تغییر کند ، هش تغییر می کند و نام پرونده تغییر می کند. در نتیجه ، هنگامی که وب سایت مستقر می شود ، مرورگر بدون در نظر گرفتن تنظیمات حافظه نهان ، یک نسخه کاملاً تازه از پرونده را دوباره بدست می آورد. حافظه نهان “شکسته” است ، دقیقاً مانند تمرین قبل از اینکه به صورت دستی به پرونده CSS تغییر نام دادیم.
نگاهی به dist/assets
به عنوان مثال پوشه در پروژه مطالعه. هر دو پرونده JS و CSS دارند index-[hash]
نام پرونده ها آن نام ها را به خاطر بسپارید و اجرا کنید npm run build
چند بار نام ها دقیقاً یکسان باقی می مانند زیرا محتوای آن پرونده ها تغییر نکردند.
حالا برو به src/App.tsx
پرونده و اضافه کردن چیزی مانند console.log('bla')
جایی دویدن npm run build
دوباره ، و پرونده های تولید شده را بررسی کنید. باید ببینید که نام پرونده CSS دقیقاً مانند گذشته باقی می ماند ، اما نام پرونده JS تغییر می کند. هنگامی که این وب سایت مستقر شد ، دفعه بعد که یک کاربر مکرر از آن بازدید می کند ، مرورگر یک فایل JS کاملاً متفاوت را درخواست می کند که قبلاً در حافظه نهان خود ظاهر نشده است. حافظه پنهان شده است.
ورزش اضافی
معادل آن را پیدا کنید dist
پوشه برای پروژه خود و اجرای دستور ساخت خود را اجرا کنید.
-
نام پرونده ها چگونه است؟ مشابه با هش ، یا ساده
index.js
باindex.css
، و غیره؟ - آیا وقتی دوباره دستور ساخت را اجرا می کنید ، نام پرونده ها تغییر می کنند؟
- اگر یک تغییر ساده در جایی از کد ایجاد کنید ، چند نام پرونده تغییر می کند؟
اگر به این ترتیب سیستم ساخت شما پیکربندی شده است – شما در شانس هستید. با خیال راحت می توانید سرورهای خود را پیکربندی کنید تا حداکثر تنظیم شود max-age
هدر برای دارایی های تولید شده. اگر به طور مشابه تمام تصاویر خود را نسخه کنید – حتی بهتر ، می توانید تصاویر را نیز در لیست قرار دهید.
بسته به وب سایت و کاربران آن و رفتار آنها ، این ممکن است باعث افزایش عملکرد بسیار خوبی برای بار اولیه به صورت رایگان شود.
آیا واقعاً باید همه اینها را برای مورد استفاده ساده خود بدانم؟
در این زمان ، شما ممکن است به چیزی مانند “شما مجنون باشید. من یک وب سایت ساده را در آخر هفته با Next.js ساخته ام و آن را در 2 دقیقه به Vercel/Netlify/Hottestnewprovider اعزام کردم. مطمئناً ، آن ابزارهای مدرن همه را کنترل می کنند این برای من؟ ” و به اندازه کافی منصفانه من هم فکر کردم اما پس از آن من واقعاً بررسی کردم ، و پسر ، من تعجب کردم 😅
دو پروژه من داشته است max-age=0
وت must-revalidate
برای پرونده های CSS و JS. معلوم شد که این پیش فرض در ارائه دهنده CDN من است. آنها البته دلیلی برای این پیش فرض دارند. و خوشبختانه ، غلبه بر آن آسان است ، بنابراین هیچ چیز بزرگی نیست. اما هنوز این روزها نمی توان به کسی یا هر چیزی اعتماد کرد.
در مورد ارائه دهنده میزبانی/CDN خود چیست؟ چقدر در مورد پیکربندی گوشواره های حافظه پنهان آنها مطمئن هستید؟
امیدوارم که این یک تحقیق سرگرم کننده باشد ، شما چیز جدیدی یاد گرفتید و حتی ممکن است یک یا دو مسئله را در پروژه های خود برطرف کنید. من الان روی بقیه معیارها کار نمی کنم ، در حالی که شما با پروژه مطالعه بازی می کنید (امیدوارم). به زودی می بینیم!
در ابتدا در https://www.developerway.com منتشر شده است. وب سایت مقالات بیشتری مانند این دارد
به کتاب پیشرفته React نگاهی بیندازید تا دانش React خود را به سطح بعدی برسانید.
مشترک در خبرنامه ، اتصال در LinkedIn یا در توییتر دنبال کنید یا Bluesky به محض انتشار مقاله بعدی مطلع شوید.