بروزرسانی: 30 خرداد 1404
چرا مرورگرها نتایج عملکرد متفاوتی تولید می کنند - مجله Smashing
من داشتم با مت زیونرت از DebugBear چت می کردم و در این فرآیند، او به طور اتفاقی به این موضوع اشاره کرد. حالت تنگ هنگام توصیف نحوه واکشی و اولویت بندی منابع توسط مرورگرها. می خواستم با سر تکان دهم که انگار می دانستم درباره چه چیزی صحبت می کند، اما در نهایت باید بپرسم: حالت "Tight" چیست؟
چیزی که من به دست آوردم دو اثر هنری بود، یکی از آنها ویدیوی زیر از رابین مارکس، کارشناس اجرای وب Akamai بود که چند هفته پیش در We Love Speed \u200b\u200bدر فرانسه صحبت می کرد:
مصنوع دیگر یک سند Google است که در ابتدا توسط پاتریک مینان در سال 2015 منتشر شد اما اخیراً در نوامبر 2023 به روز شده است. وبلاگ پاتریک از سال 2014 غیرفعال بوده است، بنابراین من به سادگی پیوندی به سند Google برای شما می گذارم تا بررسی کنید.
این تمام چیزی است که من دارم و می توانم در مورد این چیزی به نام حالت تنگ که به نظر می رسد تأثیر زیادی بر نحوه کار وب دارد در وب بیابم. رابین کمبود اطلاعات در مورد آن را در ارائه خود تصدیق کرد و میزان تحقیق اول شخص در سخنرانی او قابل توجه و ارزش توجه است زیرا تلاش می کند تا توصیف و نشان دهد که چگونه مرورگرهای مختلف منابع مختلف را با اولویت های متفاوت واکشی می کنند. با توجه به کمبود مطالب در مورد موضوع، تصمیم گرفتم آنچه را که توانستم از تحقیقات رابین و مقاله به روز شده پاتریک حذف کنم، به اشتراک بگذارم.
این اولین مرحله از دو مرحله است
این واقعیت که تاریخ انتشار اولیه پاتریک به سال 2015 می رسد، جای تعجب ندارد که در حال حاضر درباره چیزی تقریباً 10 ساله صحبت می کنیم. به روزرسانی 2023 انتشارات در «سال های وب» نسبتاً قدیمی است، با این حال وقتی سعی می کنم آن را جستجو کنم هنوز حالت تنگ وجود ندارد.
بنابراین، چگونه حالت تنگ را تعریف کنیم؟ پاتریک اینطور توضیح می دهد:
کروم منابع را در 2 مرحله بارگیری می کند. «حالت تنگ» فاز اولیه و محدودیت ها (sic) بارگیری منابع با اولویت پایین تر است تا زمانی که بدنه به سند متصل شود (در اصل، پس از اجرای همه اسکریپت های مسدودکننده در سر).»- پاتریک مینان
بسیار خوب، بنابراین ما این فرآیند دو قسمتی را داریم که Chrome از آن برای واکشی منابع از شبکه استفاده می کند و بخش اول روی هر چیزی متمرکز است که «منبع با اولویت پایین تر» نیست. ما راه هایی داریم که به مرورگرها می گوییم کدام منابع ما فکر کنید در قالب Fetch Priority API و تکنیک های بارگذاری تنبلی که به صورت ناهمزمان منابع را هنگام ورود به نمای در اسکرول بارگذاری می کنند، اولویت پایینی دارند - همه این موارد رابین در ارائه خود پوشش می دهد. اما حالت تنگ روش خاص خود را برای تعیین اینکه چه منابعی باید ابتدا بارگیری شود دارد.
حالت تنگ منابع را متمایز می کند و هر چیزی را که به عنوان اولویت بالا و متوسط \u200b\u200bعلامت گذاری شده است، در نظر می گیرد. هر چیز دیگری محدود شده و در خارج باقی می ماند، تا زمانی که بدنه محکم به سند متصل شود، به داخل نگاه می کند، که نشان می دهد اسکریپت های مسدودکننده اجرا شده اند. در آن نقطه است که منابع مشخص شده با اولویت کم در مرحله دوم بارگیری در درب مجاز می شوند.
یک هشدار بزرگ برای آن وجود دارد، اما ما به آن خواهیم رسید. نکته مهمی که باید به آن توجه کرد این است که…
Chrome و Safari حالت فشرده را اعمال می کنند
بله، کروم و سافاری هر دو دارای نوعی حالت فشرده هستند که در پس زمینه اجرا می شوند. آخرین تصویر حالت فشرده کروم را نشان می دهد. بیایید سافاری بعدی را بررسی کنیم و این دو را با هم مقایسه کنیم.
به آن نگاه کن! سافاری منابع با اولویت بالا را در واکشی اولیه خود، درست مانند کروم، متمایز می کند، اما رفتار بارگیری بسیار متفاوتی بین دو مرورگر دریافت می کنیم. توجه داشته باشید که چگونه به نظر می رسد سافاری پنج تصویر اول PNG را که با اولویت متوسط \u200b\u200bعلامت گذاری شده اند در جایی که کروم به آن ها اجازه می دهد حذف می کند. به عبارت دیگر، Safari همه منابع با اولویت متوسط \u200b\u200bو پایین را مجبور می کند تا زمانی که همه موارد با اولویت بالا بارگذاری شوند، در صف منتظر بمانند، حتی اگر ما دقیقاً با همان HTML کار می کنیم. ممکن است بگویید که رفتار سافاری بسیار منطقی است، همانطور که در تصویر آخر مشاهده می کنید که ظاهراً کروم برخی از منابع با اولویت بالا را خارج از حالت فشرده حذف می کند. واضح است که برخی از احمقانه ها در آنجا اتفاق می افتد که ما به آنها خواهیم رسید.
فایرفاکس کجای این همه است؟ هنگام ارزیابی اولویت منابع در یک صفحه، هیچ گونه اقدامات سختگیرانه اضافی انجام نمی دهد. ممکن است این رویکرد آبشار «کلاسیک» برای برداشت و بارگیری منابع در نظر گرفته شود.
کروم و سافاری حالت تنگ را به طور متفاوت راه اندازی می کنند
رابین در صحبت هایش این را مثل روز روشن می کند. کروم و سافاری هر دو طرفدار حالت تنگ هستند، اما در شرایط مختلف آن را فعال می کنند که می توانیم به شرح زیر بیان کنیم:
| کروم | سافاری | |
|---|---|---|
| حالت تنگ فعال شد | در حین مسدود کردن JS در | While blocking JS or CSS anywhere is busy. |
Notice that Chrome only looks at the document when prioritizing resources, and only when it involves JavaScript. Safari, meanwhile, also looks at JavaScript, but CSS as well, and anywhere those things might be located in the document — regardless of whether it’s in the or . That helps explain why Chrome excludes images marked as High priority in Figure 2 from its Tight Mode implementation — it only cares about JavaScript in this context.
So, even if Chrome encounters a script file with fetchpriority="high" در بدنه سند، فایل اولویت «بالا» در نظر گرفته نمی شود و پس از بقیه موارد بارگذاری می شود. سافاری در این میان افتخار می کند fetchpriority در هر نقطه از سند این به توضیح اینکه چرا کروم دو اسکریپت را در شکل 2 روی میز گذاشته است، کمک می کند، در حالی که به نظر می رسد سافاری آنها را در حالت تنگ بارگذاری می کند.
این بدان معنا نیست که سافاری در روند خود کار عجیبی انجام نمی دهد. با توجه به نشانه گذاری زیر:
...شما ممکن است انتظار داشته باشید که Safari دو اسکریپت با اولویت پایین را به تاخیر بیاندازد until the five images in the are downloaded. But that’s not the case. Instead, Safari loads those two scripts during its version of Tight Mode.
Chrome And Safari Exceptions
I mentioned earlier that Low-priority resources are loaded in during the second phase of loading after Tight Mode has been completed. But I also mentioned that there’s a big caveat to that behavior. Let’s touch on that now.
According to Patrick’s article, we know that Tight Mode is “the initial phase and constraints loading lower-priority resources until the body is attached to the document (essentially, after all blocking scripts in the head have been executed).” But there’s a second part to that definition that I left out:
“In tight mode, low-priority resources are only loaded if there are less than two in-flight requests at the time that they are discovered.”
A-ha! So, there is a way for low-priority resources to load in Tight Mode. It’s when there are less than two “in-flight” requests happening when they’re detected.
Wait, what does “in-flight” even mean?
That’s what’s meant by less than two High- or Medium-priority items being requested. Robin demonstrates this by comparing Chrome to Safari under the same conditions, where there are only two High-priority scripts and ten regular images in the mix:
بیایید ابتدا به کارهایی که Safari انجام می دهد نگاه کنیم زیرا این ساده ترین رویکرد است:
هیچ چیز مشکلی در مورد آن وجود ندارد، درست است؟ دو اسکریپت با اولویت بالا ابتدا دانلود می شوند و 10 تصویر بلافاصله بعد از آن وارد می شوند. حالا بیایید کروم را بررسی کنیم:
همانطور که انتظار می رود، ابتدا دو اسکریپت با اولویت بالا بارگذاری شده است. اما سپس کروم تصمیم می گیرد تا پنج تصویر اول با اولویت متوسط \u200b\u200bرا وارد کند، سپس پنج تصویر آخر را با اولویت کم حذف می کند. چی . هک
دلیل این امر بسیار مهم است: کروم می خواهد پنج تصویر اول را بارگذاری کند، زیرا احتمالاً بزرگترین رنگ محتوایی (LCP) اغلب یکی از این تصاویر خواهد بود و کروم شرط بندی می کند که در صورت خودکار، سرعت وب در کل سریع تر خواهد شد. برخی از این منطق را کنترل می کند. باز هم، این یک خط استدلال شریف است، حتی اگر قرار باشد 100٪ دقیق نباشد. با این حال، آب ها را گل آلود می کند و درک حالت تنگ را بسیار سخت تر می کند وقتی که می بینیم اقلام با اولویت متوسط \u200b\u200bو پایین به عنوان شهروندان با اولویت بالا در نظر گرفته می شوند.
حتی بدتر از آن این است که به نظر می رسد Chrome فقط تا دو منبع با اولویت متوسط \u200b\u200bرا در این فرآیند تبعیض آمیز می پذیرد. بقیه با اولویت کم مشخص شده اند.
منظور ما از «کمتر از دو درخواست در حین پرواز» این است. اگر کروم ببیند که فقط یک یا دو مورد وارد حالت تنگ می شوند، پس به طور خودکار تا پنج تصویر اول غیر مهم را اولویت بندی می کند به عنوان یک تلاش بهینه سازی LCP.
در حقیقت، سافاری کاری مشابه انجام می دهد، اما در زمینه متفاوت. سافاری به جای پذیرش موارد با اولویت پایین زمانی که کمتر از دو درخواست در حین پرواز وجود دارد، اولویت متوسط \u200b\u200bو پایین را در حالت تنگ و از هر نقطه ای از سند بدون در نظر گرفتن اینکه آیا در آن قرار دارند می پذیرد. or not. The exception is any asynchronous or deferred script because, as we saw earlier, those get loaded right away anyway.
How To Manipulate Tight Mode
This might make for a great follow-up article, but this is where I’ll refer you directly to Robin’s video because his first-person research is worth consuming directly. But here’s the gist:
- We have these high-level features that can help influence priority, including resource hints (i.e.,
preloadوpreconnect)، واکشی API اولویت، و تکنیک های بارگذاری تنبل. - می توانیم نشان دهیم
fetchpriority="high"وfetchpriority="low"روی اقلام
- با استفاده از
fetchpriority="high"یکی از راه هایی است که می توانیم آیتم های پایین تری را در منبع موجود در حالت تنگ دریافت کنیم. با استفاده ازfetchpriority="lowیکی از راه هایی است که می توانیم آیتم های بالاتر در منبع حذف شده از حالت تنگ را دریافت کنیم. - برای Chrome، این روی تصاویر، اسکریپت های ناهمزمان/به تاخیر افتاده و اسکریپت های واقع در پایین
. - برای سافاری، این فقط روی تصاویر کار می کند.
دوباره، صحبت رابین را برای داستان کامل که از ساعت 28:32 شروع می شود، تماشا کنید.
حالت تنگ است
برای من ناراحت کننده است که اطلاعات کمی در مورد حالت تنگ در سراسر وب وجود دارد. من انتظار دارم که چنین چیزی در جایی به خوبی مستند شود، مطمئناً در توسعه دهندگان کروم یا جایی مشابه، اما تنها چیزی که ما داریم یک Google Doc سبک وزن و یک ارائه کامل برای ترسیم تصویری از نحوه واکشی و اولویت بندی دو مرورگر از سه مرورگر اصلی است. منابع اگر اطلاعات بیشتری دارید که منتشر کرده اید یا پیدا کرده اید، به من اطلاع دهید - مایلم آنها را در بحث قرار دهم.
(Yk)منبع: https://smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/