امتیازهای Lighthouse یک سیگنال معماری هستند، نه یک چک‌لیست بهینه‌سازی

برای مدت طولانی، تصور می‌کردم که امتیازهای بالای Lighthouse عمدتاً نتیجه تنظیمات است. فشرده‌سازی تصاویر، به تأخیر انداختن اسکریپت‌ها، رفع تغییرات لی‌اوت، تنظیم حالت پس زمینه، تعویض افزونه‌ها و تکرار چرخه هر بار که هشدار جدیدی ظاهر می‌شد.

با گذشت زمان، این فرض دیگر با آنچه در عمل می‌دیدم مطابقت نداشت.

سایت‌هایی که به طور مداوم امتیاز خوبی کسب می‌کردند، سایت‌هایی با بیشترین تلاش بهینه‌سازی نبودند. آنها سایت‌هایی بودند که مرورگر به سادگی کار کمتری برای انجام دادن داشت.

در آن مرحله، Lighthouse دیگر مانند یک ابزار بهینه‌سازی نبود و شروع به احساس شدن مانند یک سیگنال تشخیصی برای انتخاب‌های معماری کرد.

آنچه Lighthouse در واقع اندازه‌گیری می‌کند

Lighthouse فریم‌ورک‌ها یا ابزارها را ارزیابی نمی‌کند. نتایج را ارزیابی می‌کند.

سرعت ظاهر شدن محتوای معنادار.

میزان مسدود کردن رشته اصلی توسط JavaScript.

پایدار میزان ثبات لی‌اوت در طول بارگذاری.

میزان دسترسی و قابلیت خزیدن ساختار سند.

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

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

JavaScript به عنوان منبع اصلی واریانس

در بین حسابرسی‌هایی که انجام داده‌ام و پروژه‌هایی که روی آنها کار کرده‌ام، اجرای JavaScript رایج‌ترین منبع رگرسیون‌های Lighthouse است.

این به این دلیل نیست که کد کیفیت پایینی دارد. به این دلیل است که JavaScript برای یک محیط اجرای تک‌رشته‌ای در طول بارگذاری صفحه رقابت می‌کند.

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

معماری‌هایی که به طور پیش‌فرض JavaScript را فرض می‌کنند، نیاز به تلاش مداوم برای کنترل عملکرد دارند. معماری‌هایی که JavaScript را به عنوان یک انتخاب صریح در نظر می‌گیرند، تمایل به تولید نتایج پایدار تری دارند.

خروجی استاتیک عدم قطعیت را کاهش می‌دهد

خروجی از پیش رندر شده چندین متغیر را از معادله عملکرد حذف می‌کند.

هیچ هزینه رندر کردن سمت سرور در زمان درخواست وجود ندارد.

هیچ بوت‌استرپ سمت کلاینت برای ظاهر شدن محتوا مورد نیاز نیست.

مرورگر HTML کامل و قابل پیش‌بینی دریافت می‌کند.

از دیدگاه Lighthouse، این معیارهایی مانند TTFB، LCP و CLS را بدون نیاز به کار بهینه‌سازی هدفمند بهبود می‌بخشد. تولید استاتیک امتیازهای کامل را تضمین نمی‌کند، اما به طور قابل توجهی دامنه حالت‌های شکست را محدود می‌کند.

یک مطالعه موردی

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

از روی کنجکاوی، رویکرد متفاوتی را امتحان کردم که HTML استاتیک را ابتدا فرض می‌کرد و JavaScript را به عنوان یک استثنا در نظر می‌گرفت. من Astro را برای این آزمایش انتخاب کردم، زیرا محدودیت‌های پیش‌فرض آن با سؤالاتی که می‌خواستم آزمایش کنم همسو بود.

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

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

مبادلات مهم هستند

این رویکرد به طور جهانی بهتر نیست.

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

فریم‌ورک‌هایی که رندرینگ سمت کلاینت را فرض می‌کنند، در آن موارد انعطاف‌پذیری بیشتری ارائه می‌دهند، به قیمت پیچیدگی بالاتر زمان اجرا. نکته این نیست که یک رویکرد برتر است، بلکه این است که مبادلات مستقیماً در معیارهای Lighthouse منعکس می‌شوند.

چرا امتیازهای Lighthouse تمایل به پایدار یا شکننده بودن دارند

آنچه Lighthouse نشان می‌دهد تلاش نیست، بلکه آنتروپی است.

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

این تفاوت توضیح می‌دهد که چرا برخی سایت‌ها نیاز به کار مداوم عملکرد دارند در حالی که دیگران با مداخله حداقلی پایدار می‌مانند.

افکار پایانی

امتیازهای بالای Lighthouse به ندرت نتیجه پاس‌های بهینه‌سازی تهاجمی هستند. آنها معمولاً به طور طبیعی از معماری‌هایی ظهور می‌کنند که آنچه را که مرورگر باید در اولین بارگذاری انجام دهد، به حداقل می‌رسانند.

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

این تغییر کمتر در مورد انتخاب فریم‌ورک مناسب است و بیشتر در مورد انتخاب جایی است که پیچیدگی مجاز به وجود است.