چرا بهینه سازی امتیاز فانوس دریایی شما برای یک وب سایت سریع کافی نیست — مجله Smashing

همه ما آن لحظه را داشته ایم. شما در حال بهینه سازی عملکرد برخی از وب سایت ها هستید، هر میلی ثانیه که طول می کشد تا صفحه فعلی بارگذاری شود را بررسی می کنید. شما Google Lighthouse را از ابزار DevTools کروم راه اندازی کرده اید زیرا همه و عمویشان از آن برای ارزیابی عملکرد استفاده می کنند.

پس از اجرای 151 گزارش خود و تکمیل تمام بهبودهای توصیه شده، نیروانا را تجربه می کنید: نمره عملکرد 100٪ کامل!

وقت آن است که برای کاری که به خوبی انجام شده است به پشت خود ضربه بزنید. شاید بتوانید از این برای افزایش دستمزدی که می خواستید استفاده کنید! به جز، این کار را نکنید - حداقل از Google Lighthouse به عنوان تنها مدرک خود استفاده نکنید. من می دانم که یک نمره عالی همه نوع احساس خوب ایجاد می کند. بالاخره هدف ما این است!

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

گوگل فانوس دریایی در چه چیزی عالی است

من می شنوم که توسعه دهندگان دیگر در مورد امتیازات عالی Lighthouse به خود می بالند و اسکرین شات های منتشر شده در سراسر شبکه های اجتماعی را می بینم. سلام، من خودم این کار را در مقدمه این مقاله انجام دادم!

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

DevTools را باز کنید، روی تب Lighthouse کلیک کنید و گزارش را ایجاد کنید! حتی راه های زیادی وجود دارد که می توانیم Lighthouse را برای اندازه گیری عملکرد در موقعیت های شبیه سازی شده پیکربندی کنیم، مانند سرعت پایین اتصال به اینترنت یا ایجاد گزارش های جداگانه برای موبایل و دسکتاپ. این یک ابزار بسیار قدرتمند برای چیزی است که در یک مرورگر رایگان آماده می شود. همچنین مستقیماً در ابزار PageSpeed \u200b\u200bInsights Google ساخته شده است!

و سریع است. گزارشی را در Lighthouse اجرا کنید، و در عرض 10-15 ثانیه چیزی را دریافت خواهید کرد. سعی کنید گزارش ها را با ابزارهای دیگر اجرا کنید، و متوجه می شوید که قهوه تان را دوباره پر می کنید، به حمام می روید و شاید ایمیل تان را (به ترتیب متفاوت) در حالی که منتظر نتایج هستید چک می کنید. دلیل خوبی برای آن وجود دارد، اما تنها چیزی که می خواهم بگویم این است که Google Lighthouse است رعد و برق سریع تا آنجا که گزارش عملکرد پیش می رود.

برای جمع بندی: فانوس دریایی در خیلی چیزها عالی است!

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

و در مورد آن امتیاز سبز متحرک زیبا و دوست داشتنی چطور - چه کسی آن را دوست ندارد؟!

خوب، این جنبه گلگون گزارش های Lighthouse است. عادلانه است که محدودیت های آن را نیز برجسته کنیم. این برای منصرف کردن شما یا هر شخص دیگری از استفاده از Lighthouse نیست، بلکه بیشتر به این دلیل است که امتیاز شما ممکن است کاملاً واقعیت را منعکس نکند - یا حتی با امتیازاتی که در ابزارهای دیگر، از جمله PageSpeed \u200b\u200bInsights خود Google، کسب می کنید، مطابقت نداشته باشد.

با کاربران واقعی مطابقت ندارد

همه داده ها با سرمایه وب کارایی یکسان ایجاد نمی شوند. دانستن این موضوع مهم است زیرا داده ها مفروضاتی را نشان می دهند که ابزارهای گزارش دهی هنگام ارزیابی معیارهای عملکرد انجام می دهند.

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

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

مت زیونرت، بنیانگذار DebugBear، نحوه اجرای داده ها در یک محیط throttling شبیه سازی شده را تشریح می کند و توضیح می دهد که چگونه Lighthouse از میانگین های "خوش بینانه" و "بدبینانه" برای نتیجه گیری استفاده می کند:

«(درنگ شبیه سازی شده) تنوع بین تست ها را کاهش می دهد. اما اگر تنها یک درخواست مسدود کردن رندر آهسته وجود داشته باشد که منشا آن را با چندین پاسخ سریع به اشتراک بگذارد، لایت هاوس زمان بارگذاری صفحه را دست کم می گیرد.

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

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

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

در حالی که throttling شبیه سازی شده پیش فرض در Lighthouse است، اما از روش های throttling واقعی تر نیز پشتیبانی می کند. اجرای آن تست ها زمان بیشتری می برد اما داده های دقیق تری به شما می دهد. ساده ترین راه برای اجرای Lighthouse با تنظیمات واقعی تر، استفاده از یک ابزار آنلاین مانند تست سرعت وب سایت DebugBear یا WebPageTest است.

بر نمرات Core Web Vitals تأثیری ندارد

این Core Web Vitals که همه درباره آنها صحبت می کنند معیارهای استاندارد Google برای اندازه گیری عملکرد هستند. آنها فراتر از گزارش های ساده «صفحه شما در X ثانیه بارگیری می شوند» با مشاهده مجموعه ای از جزئیات مرتبط تر که تشخیصی از نحوه بارگیری صفحه، منابعی که ممکن است سایر منابع را مسدود کرده باشند، تعاملات آهسته با کاربر و میزان جابه جایی صفحه در اطراف، فراتر می روند. از بارگذاری منابع و محتوا. Zeunert یک پست عالی دیگر در اینجا در مجله Smashing دارد که هر معیار را به طور مفصل مورد بحث قرار می دهد.

نکته اصلی در اینجا این است که داده های شبیه سازی شده Lighthouse تولید می کند (و اغلب هم دارد) با معیارهای عملکرد از ابزارهای دیگر متفاوت است. من برای توضیح این موضوع در مقاله دیگری هزینه زیادی کردم. اصل موضوع این است که امتیازات Lighthouse بر داده های Core Web Vitals تأثیر نمی گذارد. دلیل آن این است که Core Web Vitals به داده های مربوط به کاربران واقعی که از گزارش به روزرسانی ماهانه Chrome User Experience (CrUX) استخراج شده است، متکی است. در حالی که داده های CrUX ممکن است به دلیل اخیراً استخراج داده ها محدود شود، اما بازتاب دقیق تری از رفتارهای کاربر و شرایط مرور نسبت به داده های شبیه سازی شده در Lighthouse است.

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

«داده های (سنتتیک) اساساً با این واقعیت محدود می شوند فقط به یک تجربه در یک محیط از پیش تعریف شده نگاه می کند. این محیط اغلب حتی با کاربر واقعی معمولی در وب سایت همخوانی ندارد، که ممکن است اتصال شبکه سریعتر یا CPU کندتر داشته باشد.

روی قسمت مهمش تاکید کردم. در زندگی واقعی، کاربران احتمالاً بیش از یک تجربه در یک صفحه خاص دارند. اینطور نیست که به یک سایت بروید، بگذارید بارگذاری شود، آنجا بنشینید و سپس صفحه را ببندید. به احتمال زیاد در آن صفحه کاری انجام دهید. و برای یک معیار Core Web Vital که به دنبال رنگ آهسته در پاسخ به ورودی کاربر است - یعنی تعامل با رنگ بعدی (INP) - هیچ راهی برای لایت هاوس برای اندازه گیری آن وجود ندارد!

این همان معامله برای معیارهایی مانند تغییر چیدمان تجمعی (CLS) است که «پایداری قابل مشاهده» طرح بندی صفحه را اندازه گیری می کند، زیرا تغییرات چیدمان اغلب در صفحه پایین تر اتفاق می افتد. بعد از یک کاربر به پایین پیمایش کرده است. اگر Lighthouse به داده های CrUX متکی بود (که اینطور نیست)، می توانست بر اساس کاربران واقعی که با صفحه تعامل دارند و می توانند CLS را تجربه کنند، مفروضاتی ایجاد کند. در عوض، Lighthouse صبورانه منتظر بارگذاری کامل صفحه است و هرگز با بخش هایی از صفحه ارتباط برقرار نمی کند، بنابراین راهی برای دانستن چیزی در مورد CLS ندارد.

اما هنوز یک "شروع خوب" است

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

اما یک تصویر کامل، اینطور نیست. برای آن، چیزی که ما می خواهیم ابزاری است که بر آن تکیه کند داده های واقعی کاربر. ابزارهایی که داده های CrUX را ادغام می کنند در آنجا بسیار خوب هستند. اما باز هم، این داده ها هر ماه (دقیقاً 28 روز) جمع آوری می شوند، بنابراین ممکن است رفتارها و تعاملات اخیر کاربر را منعکس نکند، اگرچه هر روز به صورت متوالی به روزرسانی می شود و در واقع می توان سوابق تاریخی را برای نمونه های بزرگ تر جستجو کرد. اندازه ها

حتی بهتر از آن استفاده از ابزاری است که کاربران را در زمان واقعی نظارت می کند.

داده هایی که مستقیماً از سایت مبدا استخراج می شوند، واقعاً داده های استاندارد طلایی هستند که ما می خواهیم، \u200b\u200bزیرا از منبع حقیقت می آیند. این باعث می شود ابزارهایی که با سایت شما ادغام می شوند بهترین راه برای به دست آوردن بینش و تشخیص مشکلات باشند زیرا دقیقاً به شما می گویند که بازدیدکنندگان شما چگونه سایت شما را تجربه می کنند.

من در مورد استفاده از Performance API در جاوا اسکریپت برای ارزیابی معیارهای سفارشی و Core Web Vitals نوشته ام، بنابراین می توانید آن را به تنهایی اجرا کنید. اما بسیاری از خدمات موجود در خارج وجود دارد که این کار را برای شما انجام می دهند، با تجسم ها، سوابق تاریخی و واقعی نظارت بر کاربر در زمان واقعی (اغلب به اختصار RUM نامیده می شود). چه خدماتی؟ خب، DebugBear یک مکان عالی برای شروع است. من قبلا به Matt Zeunert اشاره کردم و DebugBear محصول اوست.

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

(gg, yk)