مرورگر چگونه صفحه را می سازد

از لحظه ای که HTML می رسد چه اتفاقی می افتد

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

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

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

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

چرا CSS نمایش را نگه می دارد ولی تصویر نگه نمی دارد

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

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

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

یک نمونه عملی که می توانید همین حالا چک کنید: صفحه اول همین سایت هیچ تگ link rel=stylesheet ندارد. کل CSS قالب داخل خود پاسخ HTML فرستاده می شود، یعنی برای اولین نمایش هیچ رفت و برگشتی به شبکه لازم نیست. این تنها راه درست نیست و هزینه خودش را هم دارد، ولی نشان می دهد که «فایل CSS را بهینه کنیم» تنها گزینه روی میز نیست.

جاوااسکریپت کجای این مسیر می ایستد

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

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

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

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

پس «اول CSS بعد جاوااسکریپت» خرافه نیست

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

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

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

و مرزی که باید بدانید: چند اسکریپت واقعا باید قبل از اولین رنگ آمیزی اجرا شوند، مثل تکه کدی که تم روشن یا تیره را تعیین می کند تا صفحه یک لحظه سفید و بعد تیره نشود. آن یکی را عمدا مسدودکننده نگه می دارند و این تصمیم درستی است. قاعده «همه را عقب بینداز» یک استثنا دارد و همین است.

این را روی سایت خودتان چطور ببینید

برای این کار به هیچ ابزاری احتیاج ندارید. سورس صفحه را باز کنید و فقط داخل head را نگاه کنید. دو چیز را بشمارید: چند تگ link rel=stylesheet هست، و چند تگ script با src که نه defer دارند و نه async. جمع این دو عدد، فهرست چیزهایی است که اولین نمایش صفحه شما را نگه داشته اند. اگر عدد دوم صفر نیست، معمولا اولین و ارزان ترین کار همان جاست.

اگر ترجیح می دهید از خط فرمان این کار را بکنید، این دستور همان تگ ها را چاپ می کند تا خودتان ببینید کدامشان defer یا async دارد:

curl -s https://example.com/ | tr '\n' ' ' | sed 's/<\/head>.*//' | grep -oE '<link[^>]*stylesheet[^>]*>|<script[^>]*src=[^>]*>'

نسخه ساده تر همین دستور که محدوده head را خط به خط با sed جدا می کند، روی صفحه های فشرده شده جواب غلط می دهد و ما خودمان سرش وقت گذاشتیم. HTML فشرده معمولا یک خط بلند است، پس آن محدوده تا آخر سند باز می ماند و اسکریپت های انتهای بدنه را هم به حساب می آورد. دستور بالا اول هر چه بعد از </head> است را دور می ریزد و به همین دلیل روی هر دو حالت درست کار می کند.

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

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