ابزارهای Google را برای ممیزی، بهبود، و نظارت مؤثر بر وب‌سایتتان ترکیب کنید.
تاریخ انتشار: ۲۸ مه ۲۰۲۰
معیارهای کلیدی اصلی وب مجموعه‌ای از سنجه‌ها هستند که تجربه کاربری را براساس معیارهایی مثل عملکرد بار کردن، پاسخ‌گویی به ورودی کاربر، و پایداری چیدمان ارزیابی می‌کنند.
در این راهنما، گردش کاری برای بهبود Core Web Vitals برای وب‌سایت شما بررسی خواهد شد، اما اینکه این گردش کار از کجا شروع می‌شود بستگی به این دارد که آیا داده‌های میدانی خود را جمع‌آوری می‌کنید یا نه. اینکه کجا به‌پایان می‌رسد ممکن است به این بستگی داشته باشد که کدام‌یک از ابزارهای Google را برای تشخیص و رفع مشکلات تجربه کاربری مفید می‌دانید.
«معیارهای کلیدی اصلی وب» بهتر است در فیلد اندازه‌گیری شود
«هسته‌های حیاتی وب» به‌طور خاص برای اندازه‌گیری تجربه کاربران از وب‌سایت شما طراحی شده‌اند—آن‌ها سنجه‌های کاربرمحور هستند. ابزارهای آزمایشگاهی مانند Lighthouse ابزارهای تشخیصی برای برجسته کردن مشکلات عملکردی بالقوه و روال‌های مطلوب هستند. ابزارهای آزمایشگاهی تحت شرایط خاص و ازپیش‌تعریف‌شده‌ای اجرا می‌شوند و ممکن است منعکس‌کننده اندازه‌گیری‌های واقعی «هسته‌های حیاتی وب» که کاربران شما تجربه می‌کنند نباشند.
برای مثال، Lighthouse ابزاری آزمایشگاهی است که آزمایش‌ها را با محدودسازی شبیه‌سازی‌شده در محیط شبیه‌سازی‌شده رایانه یا تلفن همراه اجرا می‌کند. درحالی‌که چنین شبیه‌سازی‌هایی از شرایط شبکه و دستگاه کندتر هنگام تلاش برای تشخیص مشکلات عملکرد مفید هستند، آن‌ها فقط یک بخش از تنوع زیاد در شرایط شبکه و قابلیت‌های دستگاه هستند و بنابراین ممکن است آنچه را که کاربران در سایت‌های شما تجربه می‌کنند منعکس نکنند.
ابزارهای مبتنی بر آزمایشگاه مانند Lighthouse نیز معمولاً یک «بارگیری سرد» از صفحه وب را به‌عنوان یک بازدیدکننده کاملاً جدید انجام می‌دهند. این اغلب کندترین بارگیری است، اما در زندگی واقعی، اگر بازدیدکنندگان قبلاً از سایت بازدید کرده باشند یا درحال مرور سایت باشند، ممکن است برخی‌از دارایی‌ها را در حافظه نهان داشته باشند. بازدیدکنندگان جدید و ابزارها نیز ممکن است به‌دلیل وجود برنمای کوکی یا محتوای دیگری که به آن‌ها نشان داده می‌شود، سایت را به‌طور متفاوتی تجربه کنند.
به‌طور خلاصه، اگرچه ابزارهای مبتنی بر آزمایشگاه می‌توانند نشانه‌ای از مشکلات عملکردی بالقوه ارائه دهند و به شما در اشکال‌زدایی و تکرار کمک کنند، اما ممکن است نشان‌دهنده تعداد بازدیدکنندگانی نباشند که واقعاً وب‌سایت شما را تجربه می‌کنند. از داده‌های فیلد برای اندازه‌گیری عملکرد در دنیای واقعی و از ابزارهای آزمایشگاهی مانند Lighthouse برای تشخیص نحوه بهبود آن استفاده کنید. همچنین بخش زمان استفاده از Lighthouse را ببینید.
Google ازطریق گزارش تجربه کاربری Chrome (CrUX)، Core Web Vitals را اندازه‌گیری می‌کند. این یک مجموعه داده عمومی است که از کاربران واقعی Chrome جمع‌آوری شده است. این پایگاه داده ستون فقرات بسیاری از ابزارهای Google و طرف سوم است که «شاخص‌های کلیدی عملکرد وب» سایت را گزارش می‌کنند.
بااین‌حال، CrUX محدودیت‌های خودش را دارد. اغلب می‌تواند به شما بگوید چه زمانی مشکلی وجود دارد، اما اغلب داده‌های کافی برای گفتن دلیل آن ندارد.
درصورت امکان، داده‌های فیلد خودتان را جمع‌آوری کنید
بهترین مجموعه‌داده برای بهبود عملکرد وب‌سایت در این زمینه، مجموعه‌داده‌ای است که شما می‌سازید. این کار با جمع‌آوری داده‌های میدانی از بازدیدکنندگان وب‌سایت شما شروع می‌شود. نحوه انجام این کار به اندازه سازمان شما بستگی دارد و اینکه آیا می‌خواهید برای یک راه‌حل شخص ثالث هزینه پرداخت کنید یا راه‌حل خودتان را ایجاد کنید.
راه‌حل‌های پولی تقریباً به‌طور قطع Core Web Vitals (و دیگر سنجه‌های عملکرد) را اندازه‌گیری می‌کنند و معمولاً ابزارهای متنوعی برای کاوش در داده‌های حاصل ارائه می‌دهند. در سازمان‌های بزرگ با منابع قابل‌توجه، این روش ممکن است روش ترجیحی باشد.
بااین‌حال، ممکن است عضو سازمان بزرگی نباشید—یا حتی سازمانی که توانایی مالی برای پرداخت هزینه راهکار شخص ثالث را داشته باشد. در این موارد، کتابخانهweb-vitals Google به شما کمک می‌کند همه «حیاتی‌های وب» را جمع‌آوری کنید. اما مسئولیت نحوه گزارش، ذخیره، و تحلیل آن داده‌ها با شما خواهد بود.
اگر درحال‌حاضر از Google Analytics استفاده می‌کنید اما هنوز جمع‌آوری داده‌های میدانی خودتان را شروع نکرده‌اید، ممکن است فرصتی برای شما وجود داشته باشد که از کتابخانه web-vitals برای ارسال «شاخص‌های حیاتی وب» جمع‌آوری‌شده در میدان به Google Analytics استفاده کنید و از صادر کردن BigQuery از GA4 برای گزارش دادن درباره داده‌ها استفاده کنید.
آشنایی با ابزارهای Google
صرف‌نظر از اینکه داده‌های میدانی خودتان را جمع‌آوری می‌کنید یا نه، چندین ابزار Google وجود دارد که ممکن است در تجزیه‌وتحلیل «شاخص‌های کلیدی عملکرد وب» مفید باشد. قبل‌از ایجاد گردش کار، یک نمای کلی سطح بالا از هر ابزار می‌تواند به شما کمک کند تا بفهمید کدام ابزارها ممکن است برای شما بهترین باشند یا نباشند.
گزارش تجربه کاربری Chrome (CrUX)
همان‌طور که قبلاً ذکر شد، CrUX یک مجموعه داده عمومی از داده‌های میدانی است که از بخشی از کاربران واقعی Google Chrome از میلیون‌ها وب‌سایت جمع‌آوری شده است. این گزارش شامل سنجه‌های «معیار کلیدی اصلی وب» و سنجه‌های دیگر برای وب‌سایت‌هایی با ترافیک کافی است.
CrUX به‌صورت مجموعه داده BigQuery ماهانه در سطح مبدأ، یا به‌صورت میانای برنامه‌سازی کاربردی روزانه در سطح نشانی وب یا مبدأ دردسترس است، به‌شرطی که نشانی وب یا مبدأ نمونه‌های کافی در مجموعه داده CrUX داشته باشد. داده‌های CrUX ازطریق ابزارهای مختلف CrUX هم برای دسترسی برنامه‌نویسی‌شده و هم برای ابزارهای دیداری برای استفاده کاربران دردسترس است.
چه زمانی باید از CrUX استفاده کرد
حتی اگر داده‌های فیلد خودتان را جمع‌آوری کنید، CrUX همچنان مفید است. اگرچه CrUX زیرمجموعه‌ای از کاربران Chrome را نشان می‌دهد، اما مقایسه داده‌های فیلد وب‌سایت شما برای دیدن نحوه همسویی آن با داده‌های CrUX مفید است. هرکدام مزایا و معایبی دارند که می‌تواند منجر به تفاوت‌هایی شود. اگر هیچ داده فیلدی برای وب‌سایتتان جمع‌آوری نمی‌کنید، CrUX به‌ویژه برای ارائه نمای کلی سطح بالا ارزشمند است—به‌شرطی که وب‌سایتتان در مجموعه داده آن نشان داده شود.
می‌توانید مستقیماً از CrUX استفاده کنید یا از ابزار دیگری (ازجمله ابزارهای ذکرشده در زیر) استفاده کنید. استفاده مستقیم از مجموعه داده CrUX، بااستفاده از BigQuery یا API، برای نمایش داده‌هایی که در ابزارهای دیگر نشان داده نمی‌شوند مفید است—برای مثال داده‌های سطح کشور اغلب در ابزارهای دیگر دردسترس نیستند، یا برای مشاهده سنجه‌های اضافی در CrUX که بازهم اغلب در ابزارهای دیگر نشان داده نمی‌شوند.
چه زمانی از CrUX استفاده نکنیم
CrUX فقط کاربران Chrome را نشان می‌دهد و حتی در این صورت، فقط زیرمجموعه‌ای از کاربران Chrome را نشان می‌دهد. یک راهکار کامل RUM می‌تواند شامل تجربه‌های بیشتری در Chrome و مرورگرهای دیگر باشد که از سنجه‌های Web Vital پشتیبانی می‌کنند.
وب‌سایت‌هایی که ترافیک کافی دریافت نمی‌کنند در مجموعه داده CrUX نشان داده نمی‌شوند. اگر این مورد برای شما صادق است، باید داده‌های فیلد خود را جمع‌آوری کنید تا متوجه شوید وب‌سایت شما در فیلد چگونه عمل می‌کند، زیرا CrUX گزینه‌ای نخواهد بود. یا اینکه باید به داده‌های آزمایشگاهی تکیه کنید، اما با این محدودیت که ممکن است همان‌طور که قبلاً توضیح داده شد، معرف نباشد.
ازآنجایی‌که داده‌هایی که CrUX ارائه می‌دهد میانگین متحرک ۲۸ روز گذشته است، ابزار ایده‌آلی درطول توسعه نیست، زیرا مدت زمان قابل‌توجهی طول می‌کشد تا بهبودها در مجموعه داده CrUX منعکس شود.
درنهایت، CrUX به‌عنوان یک مجموعه داده عمومی، از نظر میزان اطلاعاتی که می‌تواند دردسترس قرار دهد و نحوه پرس‌وجو از این داده‌ها محدود است. با ضبط کردن داده‌های RUM خودتان می‌توانید جزئیات بیشتری (برای مثال، عنصر LCP) جمع‌آوری کنید و داده‌ها را برای شناسایی مشکلات بیشتر بخش‌بندی کنید. آیا کاربران واردشده به سیستم نسبت‌به کاربران خارج‌شده از سیستم، «شاخص‌های کلیدی عملکرد وب» بهتر یا بدتری را تجربه می‌کنند؟ آیا کاربرانی که LCP کند دارند، عنصر LCP خاصی دارند؟ کدام تعامل‌ها باعث ایجاد مقادیر بالای FID و INP می‌شوند؟
اطلاعات آماری PageSpeed (PSI)
PSI ابزاری است که داده‌های فیلد را از CrUX و آزمایشگاه را از Lighthouse برای صفحه‌ای مشخص گزارش می‌کند. برای جزئیات بیشتر، آن بخش‌های جداگانه را ببینید.
زمان استفاده از PSI
PSI برای ارزیابی عملکرد CrUX در سطح صفحه یا سطح مبدأ، هم برای کاربران تلفن همراه و هم برای کاربران رایانه، عالی است. این گزینه برای نمای کلی اولیه از «هسته‌های حیاتی وب» برای صفحه یا سایت مناسب است. همچنین به شما امکان می‌دهد داده‌های «معیارهای کلیدی اصلی وب» را برای سایت‌های دیگر، مثل رقبا، مشاهده کنید.
PSI همچنین داده‌های Lighthouse را ارائه می‌دهد که توصیه‌های مفیدی برای بهبود «سنجه‌های حیاتی وب» شما ارائه می‌دهد (اگر سنجه‌ها هم‌راستا باشند). در مواردی که این دو باهم هم‌راستا نباشند، توصیه‌های Lighthouse ممکن است کمتر مرتبط باشند.
ازآنجایی‌که Lighthouse از سرور اجرا می‌شود، می‌تواند خط مبنای سازگارتری نسبت به اجرای Lighthouse از DevTools تشکیل دهد.
چه زمانی از PSI استفاده نکنید
PSI فقط برای نشانی‌های وب عمومی دردسترس است. نمی‌توان از آن در سایت‌های توسعه که برای عموم دردسترس نیستند استفاده کرد.
داده‌های CrUX فقط زمانی دردسترس است که سایت‌ها معیارهای واجدشرایط بودن خاصی را داشته باشند، ازجمله آستانه‌های محبوبیت سایت. وقتی داده‌های CrUX برای صفحه یا مبدأ دردسترس نباشد، PSI کمتر مفید است زیرا در این موارد فقط می‌تواند داده‌های آزمایشگاهی Lighthouse را نشان دهد.
به‌طور مشابه، اگر فقط داده‌های CrUX در سطح مبدأ را داشته باشید و نشانی وب خاصی که آزمایش می‌شود را نداشته باشید، این امر نیز مفید بودن همبستگی داده‌های فیلد در سطح مبدأ با تشخیص‌های آزمایشگاهی در سطح صفحه را محدود می‌کند. داشتن داده‌های فیلد سطح مبدأ هنوز اطلاعات بسیار مفیدی برای داشتن خلاصه‌ای از عملکرد سایت است و ممیزی‌های Lighthouse ممکن است کمک کند، اما در این مورد باید احتیاط بیشتری به کار برد.
درنهایت، در مواردی که داده‌های سطح صفحه در CrUX دردسترس است اما با داده‌های آزمایشگاهی Lighthouse تفاوت دارد، توصیه‌های Lighthouse ممکن است ارزش محدودی داشته باشد. این امر به‌ویژه برای مشکلات CLS پس‌از بارگیری و برای «معیارهای کلیدی اصلی وب» تعاملی (FID و INP) که ممیزی‌های آزمایشگاهی در آن‌ها کمتر مفید هستند، ممکن است رخ دهد.
کنسول جستجو
کنسول جستجو ترافیک و عملکرد جستجوی سایت شما را ازجمله Core Web Vitals اندازه‌گیری می‌کند. این ویژگی فقط برای مالکان سایتی دردسترس است که مالکیتشان بر سایت را تأیید کرده‌اند.
یکی از ویژگی‌های ارزشمند «کنسول جستجو» این است که صفحه‌های مشابه (برای مثال، صفحه‌هایی که از یک الگو استفاده می‌کنند) را در یک گروه ارزیابی قرار می‌دهد. Search Console همچنین شامل گزارش Core Web Vitals براساس داده‌های فیلد CrUX است.
چه زمانی از «کنسول جستجو» استفاده کنید
«کنسول جستجو» هم برای توسعه‌دهندگان و هم برای افرادی که نقش توسعه‌دهنده ندارند بسیار مناسب است تا عملکرد جستجو و صفحه را به روش‌هایی ارزیابی کنند که سایر ابزارهای Google نمی‌توانند. ارائه داده‌های CrUX و گروه‌بندی صفحه‌ها براساس شباهت، اطلاعات آماری جدیدی درباره نحوه تأثیر بهبود عملکرد بر کل دسته‌های صفحه‌ها ارائه می‌دهد.
چه زمانی نباید از «کنسول جستجو» استفاده کنید
ممکن است «کنسول جستجو» برای پروژه‌هایی که از ابزارهای شخص ثالث مختلفی استفاده می‌کنند که صفحه‌ها را براساس شباهت گروه‌بندی می‌کنند، یا اگر وب‌سایتی در مجموعه داده CrUX نشان داده نشده باشد، مناسب نباشد.
همچنین وقتی صفحه‌های نمونه در یک گروه ویژگی‌های متفاوتی نسبت‌به بقیه گروه داشته باشند، گروه‌بندی صفحه می‌تواند تاحدودی گیج‌کننده باشد—برای مثال، اگر گروه به‌طور کلی در «هسته‌های حیاتی وب» خاصی ناموفق باشد، اما به‌نظر برسد همه صفحه‌های نمونه در همان «هسته‌های حیاتی وب» موفق بوده‌اند. این اتفاق زمانی رخ می‌دهد که گروهی حاوی صفحات دیریاب یا صفحاتی باشد که به‌ندرت بازدید می‌شوند و ممکن است سرعت بار شدن آن‌ها کمتر باشد، زیرا احتمال ذخیره شدن آن‌ها در حافظه نهان کمتر است. وقتی حجم کافی از این صفحه‌ها در دیریاب وجود داشته باشد، می‌توانند بر نرخ قبولی کلی گروه تأثیر بگذارند.
Lighthouse
Lighthouse ابزاری آزمایشگاهی است که فرصت‌های خاصی را برای بهبود عملکرد صفحه ارائه می‌دهد. جریان‌های کاربر Lighthouse همچنین به توسعه‌دهندگان اجازه می‌دهد تا جریان‌های تعامل را برای آزمایش عملکرد فراتر از بارگیری صفحه اسکریپت کنند.
Lighthouse-CI ابزار مرتبطی است که Lighthouse را درطول ساخت و استقرار پروژه اجرا می‌کند تا به آزمایش رگرسیون عملکرد کمک کند. این ابزار گزارش Lighthouse را به‌همراه درخواست‌های واکشی ارائه می‌دهد و سنجه‌های عملکرد را درطول زمان ردیابی می‌کند.
زمان استفاده از Lighthouse
Lighthouse برای یافتن فرصت‌های بهبود عملکرد درطول توسعه در محیط‌های محلی و مرحله‌ای عالی است. Lighthouse CI به‌طور مشابه در مراحل ساخت و استقرار در محیط‌های مرحله‌بندی و تولید مفید است، جایی که آزمایش رگرسیون عملکرد برای حفظ تجربه‌های کاربری خوب موردنیاز است.
چه زمانی از Lighthouse استفاده نکنید
Lighthouse (یا Lighthouse CI) جایگزینی برای داده‌های میدانی نیست. Lighthouse در درجه اول ابزاری تشخیصی است که مشکلات احتمالی و روال‌های مطلوب را از بار صفحه ازپیش‌تعریف‌شده فهرست می‌کند. توصیه‌هایی که ارائه می‌دهد ممکن است همیشه با عملکردی که کاربران شما تجربه می‌کنند مطابقت نداشته باشد.
درحالی‌که Lighthouse می‌تواند برای تشخیص سایت‌های تولید ازطریق ابزارهایی مانند PageSpeed Insights استفاده شود، Lighthouse به‌طور ایده‌آل در محیط‌های توسعه و ادغام مداوم برای رفع مشکلات عملکرد قبل‌از رسیدن به تولید استفاده می‌شود.
ممیزی‌هایی که Lighthouse ارائه می‌دهد ازطریق «اطلاعات آماری» در پانل «عملکرد» در Chrome DevTools نیز دردسترس است که تجزیه‌وتحلیل عمیق‌تری از عملکرد صفحه ارائه می‌دهد.
پانل «عملکرد» در Chrome DevTools
Chrome DevTools مجموعه‌ای از ابزارهای توسعه درون‌مرورگر است، ازجمله پانل عملکرد. پانل «عملکرد» ابزاری آزمایشی است که از دو «حالت» تشکیل شده است:
وقتی پانل «عملکرد» برای اولین‌بار باز می‌شود، صفحه «سنجه‌های زنده» سنجه فعلی «معیارهای کلیدی اصلی وب» را ارائه می‌دهد و امکان وارد کردن داده‌های فیلد از CrUX را فراهم می‌کند. این ابزار به‌عنوان نمای «زنده» از عملکرد هنگام تعامل با صفحه برای تلاش جهت کشف مشکلات عملکرد مفید است—به‌ویژه برای مشکلات پس‌از بارگیری که ممکن است با سنجه‌های CLS و INP مشاهده کنید.
دوم اینکه پانل «عملکرد» به توسعه‌دهندگان اجازه می‌دهد نمایه‌ای (یا ردی) از همه فعالیت‌های صفحه را درطول بار کردن صفحه یا دوره زمانی ضبط‌شده ثبت کنند. این نما اطلاعات آماری عمیقی درباره هر چیزی که در ابعاد مختلف مشاهده می‌کند ارائه می‌دهد، ازجمله فعالیت‌های شبکه، رندر کردن، رنگ‌آمیزی، و اسکریپت‌نویسی، و همچنین «هسته‌های حیاتی وب» صفحه. همچنین شامل اطلاعات آماری، مشابه اطلاعات آماری ارائه‌شده توسط Lighthouse، است.
چه زمانی باید از پانل «عملکرد» استفاده کرد
توسعه‌دهندگان باید از پانل «عملکرد» برای به‌دست آوردن اطلاعات آماری عمیق درباره عملکرد صفحه‌ای خاص استفاده کنند.
از نمای سنجه‌های فعال می‌توان برای درک سریع ویژگی‌های عملکرد فعلی صفحه و همچنین شناسایی مشکلات احتمالی هنگام تعامل با صفحه استفاده کرد.
نمای ردیابی به‌ویژه برای اشکال‌زدایی مشکلات پاسخ‌دهی که بر INP تأثیر می‌گذارند مفید است. وقتی تعاملی با پاسخ ضعیف شناسایی و تکرار شود، پانل «عملکرد» می‌تواند داده‌های فراوانی درباره آنچه در مرورگر اتفاق می‌افتد ارائه دهد تا به درک مشکل کمک کند، از مسدود شدن رشته اصلی گرفته تا پشته‌های فراخوانی جاوا اسکریپت و کار پردازش.
زمان‌هایی که نباید از پانل «عملکرد» استفاده کنید
پانل «عملکرد» ابزاری برای توسعه‌دهندگان است که عمدتاً داده‌های آزمایشگاهی را ارائه می‌دهد—هرچند با برخی زمینه‌های فیلد از CrUX. این داده‌ها جایگزینی برای داده‌های میدانی نیست.
نمای ردگیری حاوی اطلاعات اشکال‌زدایی زیادی است، اما به همین دلیل، درک آن برای توسعه‌دهندگان تازه‌کار یا افرادی که در نقش‌های غیرتوسعه‌دهنده هستند دشوار است. بااین‌حال، نمای سنجه‌های زنده که پانل با آن باز می‌شود، این مشکل را با ارائه یک واسط کاربری آسان‌تر برای کسانی که به جزئیات کامل نیاز ندارند، برطرف می‌کند.
گردش کار سه‌مرحله‌ای برای اطمینان از اینکه «معیارهای کلیدی اصلی وب» وب‌سایت شما سالم باقی می‌مانند
هنگام تلاش برای بهبود تجربه کاربری، بهتر است این فرایند را به‌عنوان یک چرخه مداوم درنظر بگیرید. برای بهبود «معیارهای کلیدی اصلی وب» و دیگر سنجه‌های عملکرد، یک رویکرد می‌تواند این باشد:
- ارزیابی سلامت وب‌سایت و شناسایی چالش‌های عمده.
- اشکال‌زدایی و بهینه‌سازی.
- با ابزارهای ادغام مداوم نظارت کنید تا رگرسیون‌ها را شناسایی و از آن‌ها جلوگیری کنید.
مرحله ۱: ارزیابی سلامت وب‌سایت و شناسایی فرصت‌های بهبود
بهتر است برای ارزیابی سلامت وب‌سایت با داده‌های فیلد شروع کنید.
- از PageSpeed Insights برای مشاهده سنجه‌های کلی تجربه «معیارهای کلیدی اصلی وب» در مبدأ و اطلاعات خاص درباره نشانی وب تکی استفاده کنید.
- کنسول جستجو می‌تواند برای شناسایی صفحه‌هایی که نیاز به بهبود دارند مفید باشد، زیرا ویژگی گروه‌بندی صفحه آن برای سایت شما به‌خوبی کار می‌کند.
- اگر داده‌های RUM دارید، اغلب بهترین گزینه برای شناسایی صفحه‌ها یا بخش‌های ترافیک خاصی است که مشکل دارند.
چه داده‌های فیلدی را که خودتان جمع‌آوری می‌کنید تجزیه‌وتحلیل کنید و چه داده‌های CrUX را، این گام اول حیاتی است. اگر داده‌های فیلد را جمع‌آوری نمی‌کنید، داده‌های CrUX ممکن است برای راهنمایی شما کافی باشد—باز هم، به شرطی که وب‌سایت شما در مجموعه داده‌ها نشان داده شده باشد.
تجزیه‌وتحلیل عملکرد سایت با «اطلاعات آماری PageSpeed»
PageSpeed Insights داده‌های CrUX را که پوشش‌دهنده داده‌های تجربه کاربری ۲۸ روز گذشته در صدک ۷۵ است نمایش می‌دهد. این یعنی اگر ۷۵٪ از تجربه‌های کاربری آستانه تعیین‌شده برای سنجه‌ای خاص را برآورده کند، آن تجربه «خوب» درنظر گرفته می‌شود.
اگر صفحه خاصی را برای بررسی عملکرد مدنظر دارید، از آن استفاده کنید. برای داشتن نمای کلی از سایت وقتی برای اولین‌بار بهینه‌سازی را شروع می‌کنید، شاید بهتر باشد از صفحه اصلی شروع کنید، زیرا معمولاً یکی از پرطرفدارترین صفحه‌ها در بسیاری از سایت‌ها است.
در ابتدا روی بخش آنچه کاربران واقعی شما تجربه می‌کنند در PSI تمرکز کنید. حداکثر چهار نمای داده را خواهید دید: تلفن همراه و رایانه برای نشانی وب واردشده و کل مبدأ. این‌ها را مقایسه کنید و ببینید چه تفاوتی دارند. تلفن همراه معمولاً عملکرد ضعیف‌تری نسبت‌به رایانه دارد زیرا دستگاهی با منابع محدودتر است که تحت شرایط شبکه احتمالاً ناپایدارتری کار می‌کند. اگر داده‌های نشانی وب و مبدأ تفاوت قابل‌توجهی دارند، سعی کنید دلیل آن را بفهمید: صفحه‌های اصلی اغلب اولین صفحه‌هایی هستند که بازدید می‌شوند (یعنی صفحه مقصد)، بنابراین می‌توانند کندتر از مبدأ باشند، زیرا کاربران بار کامل حافظه نهان مرورگر آماده‌نشده را متحمل می‌شوند. صفحه‌های بعدی احتمالاً سریع‌تر بار می‌شوند، زیرا هر دارایی هم‌رسانی‌شده‌ای ذخیره می‌شود و داده‌های سطح مبدأ تجمیعی را کاهش می‌دهد.
PSI همچنین هر سه «معیار کلیدی اصلی وب» (LCP، CLS، و INP) به‌علاوه سنجه‌های تشخیصی TTFB و FCP را نشان می‌دهد. آیا هیچ‌کدام از «معیارهای کلیدی اصلی وب» ناموفق هستند و به چه میزان؟ این به شما نشان می‌دهد که تلاش‌هایتان را کجا متمرکز کنید.
رابطه بین این اعداد را درک کنید—به‌ویژه برای LCP. اگر «بزرگ‌ترین رنگ محتوایی» کند است، همان‌طور که در این مثال می‌بینید، به «زمان رسیدن اولین بایت» و «اولین رنگ محتوایی» که هر دو نقاط عطف آن سنجه هستند نگاه کنید. در این مثال، TTFB ما ۱٫۸ ثانیه است که رسیدن به آستانه توصیه‌شده ۲٫۵ ثانیه برای LCP خوب را بسیار دشوار می‌کند. این نشان‌دهنده زیرینه کند (مشکلات سرور یا نبود CDN)، شبکه‌های کندتر، یا هدایت‌های مجددی است که اولین بایت‌های HTML را به‌تأخیر می‌اندازند. برای اطلاعات بیشتر، به راهنمای بهینه‌سازی TTFB مراجعه کنید. FCP یک ثانیه دیگر به آن اضافه می‌کند که این هم می‌تواند نشان‌دهنده شبکه‌های کندتر باشد. در این مثال، LCP مدت زیادی پس‌از FCP نیست که نشان می‌دهد منبع LCP پس‌از بار شدن خود صفحه به‌خوبی بهینه‌سازی شده است. CrUX اکنون اطلاعات عیب‌یابی بیشتری را در انواع منابع و بخش‌های فرعی نشان می‌دهد که به شما کمک می‌کند مشکلات LCP را عیب‌یابی کنید.
برای CLS، به امتیازهای CrUX CLS و Lighthouse CLS نگاه کنید تا ببینید آیا این مشکل CLS بارگیری است (که Lighthouse آن را شناسایی می‌کند و درباره آن توصیه می‌کند) یا مشکل CLS پس‌از بارگیری است که Lighthouse آن را شناسایی نمی‌کند. برای اطلاعات بیشتر، راهنمای «بهینه‌سازی CLS» را ببینید.
برای پاسخ‌گویی، به امتیازهای INP نگاه کنید. ممیزی‌های TBT را در Lighthouse بررسی کنید تا ببینید آیا پردازش جاوا اسکریپت زیادی درطول بارگیری اولیه صفحه اتفاق می‌افتد یا نه، که احتمالاً بر INP تأثیر می‌گذارد. INP می‌تواند سنجه‌ای دشوار برای بهبود باشد، بنابراین برای اطلاعات بیشتر به راهنمای بهینه‌سازی INP مراجعه کنید.
شناسایی صفحه‌هایی با عملکرد ضعیف در «کنسول جستجو»
درحالی‌که PSI زمانی مفید است که نشانی وب خاصی دارید که می‌خواهید آن را آزمایش کنید یا کل سایت را آزمایش کنید، «کنسول جستجو» می‌تواند به هدف‌یابی تلاش‌هایتان برای انواع خاصی از صفحه‌ها کمک کند. این به‌ویژه زمانی مفید است که صفحه‌های زیادی دارای فناوری‌ها یا زمینه‌های مشترک باشند و «کنسول جستجو» بتواند آن‌ها را باموفقیت شناسایی کند.
گزارش «هسته‌های حیاتی وب» در «کنسول جستجو» تصویر کلی عملکرد وب‌سایتتان را نشان می‌دهد، اما همچنان می‌توانید به صفحه‌های خاصی که نیاز به توجه دارند دسترسی پیدا کنید. با «کنسول جستجو» می‌توانید کارهای زیر را نیز انجام دهید:
- گروه‌های صفحه تکی را که نیاز به بهبود دارند و گروه‌هایی را که تجربه کاربری خوبی ارائه می‌دهند شناسایی کنید.
- داده‌های دانه‌ای درباره عملکرد براساس نشانی وب را که براساس وضعیت، سنجه، و گروه‌های صفحات وب مشابه (مثل صفحه‌های جزئیات محصول در وب‌سایت تجارت الکترونیک) گروه‌بندی شده‌اند دریافت کنید.
- گزارش‌های تفصیلی دریافت کنید که نشانی‌های وب را در هر دسته کیفیت تجربه کاربری برای تلفن همراه و رایانه دسته‌بندی می‌کند.
وقتی صفحه‌های خاصی برای بررسی دارید، می‌توانید از PSI همان‌طور که قبلاً توضیح داده شد استفاده کنید تا درک بیشتری از مشکلات آن صفحه‌ها به‌دست آورید.
مرحله ۲: اشکال‌زدایی و بهینه‌سازی
در مرحله ۱، باید صفحه‌هایی را که نیاز به بهبود عملکرد دارند و همچنین سنجه‌های «معیار کلیدی اصلی وب» را که می‌خواهید بهبود دهید شناسایی کرده باشید. می‌توانید از ابزار Google برای دریافت اطلاعات بیشتر جهت درک علت ریشه‌ای برای شناسایی مشکل استفاده کنید.
- برای دریافت راهنمایی سطح بالا برای صفحه، به ارزیابی‌های Lighthouse نگاه کنید
- از نمای سنجه‌های زنده پانل عملکرد برای تجزیه‌وتحلیل هم‌زمان «معیارهای کلیدی اصلی وب» استفاده کنید.
- از ردیابی پانل «عملکرد» برای اشکال‌زدایی مشکلات عملکرد و آزمایش تغییرات کد استفاده کنید.
برای راهنمایی دقیق‌تر، این راهنماها را ببینید:
کشف فرصت‌ها با Lighthouse
PageSpeed Insights Lighthouse را برای شما اجرا می‌کند. همچنین می‌توانید Lighthouse را از Chrome DevTools اجرا کنید که برای اعتبارسنجی محلی اصلاحات مفید است، هرچند «پانل عملکرد» (که در ادامه پوشش داده می‌شود) ابزار جامع‌تری برای شناسایی و رفع محلی مشکلات عملکرد است.
نکته کلیدی این است که تأیید کنید ممیزی Lighthouse مشکلاتی را که می‌خواهید حل کنید (برای مثال، LCP کند یا مشکلات CLS) تکرار می‌کند. به‌طور پیش‌فرض، Lighthouse فقط تجربه کاربر را درطول بار شدن صفحه ارزیابی می‌کند. ازآنجایی‌که این ابزار آزمایشگاهی است، INP را نیز به‌نفع TBT مستثنی می‌کند.
وقتی سنجه‌های Lighthouse مشکلی مشابه با مشکلی را که می‌خواهید حل کنید پیشنهاد می‌کنند، اطلاعات غنی موجود در ممیزی‌های آن می‌تواند به شناسایی مشکلات و پیشنهاد راه‌حل‌ها کمک کند.
می‌توانید ممیزی‌ها را فقط به Core Web Vitals موردعلاقه‌تان فیلتر کنید تا روی رفع مشکلات مربوط به سنجه‌ای خاص تمرکز کنید:
برای INP، از ممیزی‌های TBT برای شناسایی مشکلاتی که می‌توانند به‌طور بالقوه بر این سنجه‌ها تأثیر بگذارند استفاده کنید، اما توجه داشته باشید که بدون تعامل، Lighthouse در میزان تشخیص خود محدود است.
تجزیه‌وتحلیل کردن هم‌زمان با صفحه سنجه‌های زنده Chrome DevTools
صفحه سنجه‌های زنده Chrome DevTools در پانل «عملکرد»، «معیارهای کلیدی اصلی وب» را در زمان واقعی درطول بار کردن صفحه و هنگام مرور صفحه نشان می‌دهد. به همین دلیل، می‌تواند INP و همچنین تغییرات چیدمان را که پس‌از بارگیری رخ می‌دهد ثبت کند. همچنین می‌توانید اطلاعات دقیق‌تری درباره هر سنجه ببینید:
این نما اطلاعات مفید زیادی برای کمک به شناسایی مشکلات عملکرد ارائه می‌دهد و حتی می‌تواند اطلاعات فیلد را از CrUX دریافت کند. برای اطلاعات بیشتر می‌توانید با ردیابی جزئیات بیشتری را ببینید.
جزئیات را با پانل «عملکرد» بررسی کنید
پانل «عملکرد» در Chrome DevTools به شما امکان می‌دهد نمایه (یا ردگیری) همه رفتارهای صفحه را درطول دوره زمانی ضبط‌شده ضبط کنید.
اطلاعات آماری عملکرد در پانل کناری اطلاعات آماری دردسترس است. این بخش همچنین سنجه‌های «معیار کلیدی اصلی وب» را به‌همراه مقادیر فیلد آن‌ها (درصورت دردسترس بودن) نشان می‌دهد.
قطعه تغییرات چیدمان تغییرات چیدمان را برجسته می‌کند و کلیک کردن روی آن‌ها جزئیات بیشتری درباره عناصری که برای اشکال‌زدایی CLS تغییر کرده‌اند ارائه می‌دهد.
زمان‌بندی‌های کلیدی (مانند LCP) در زمان‌بندی‌ها که در پایین ردیابی دردسترس است نشان داده می‌شود. برای جزئیات بیشتر، روی این‌ها کلیک کنید.
«تکالیف طولانی» (که می‌تواند منجر به مشکلات INP شود) نیز با مثلث‌های قرمز در نمودار شعله‌ای برجسته می‌شوند.
این ویژگی‌ها—و همچنین اطلاعات موجود در بخش‌های دیگر پانل عملکرد—می‌توانند به شما کمک کنند تا تعیین کنید آیا اصلاحات تأثیری بر «هسته‌های حیاتی وب» صفحه دارند یا نه.
اشکال‌زدایی کردن Core Web Vitals در فیلد
ابزارهای آزمایشگاهی همیشه نمی‌توانند علت همه مشکلات «شاخص‌های کلیدی عملکرد وب» را که بر کاربران شما تأثیر می‌گذارند شناسایی کنند. این یکی از دلایلی است که جمع‌آوری داده‌های میدانی خودتان بسیار مهم است، زیرا عواملی را درنظر می‌گیرد که داده‌های آزمایشگاهی نمی‌توانند درنظر بگیرند.
برای اطلاعات بیشتر، اشکال‌زدایی عملکرد در فیلد را ببینید.
مرحله ۳: پایش کردن تغییرات
پس‌از برطرف کردن مشکلات، باید مطمئن شوید که تأثیر لازم را داشته‌اند و مشکلات جدید «هسته‌های حیاتی وب» شما را مختل نمی‌کنند. این کار مستلزم نظارت بر مشکلات عملکرد به‌عنوان بخشی از گردش کار توسعه‌دهنده است تا از انتشار مشکلات عملکرد در تولید جلوگیری شود، و همچنین نظارت منظم بر داده‌های میدانی برای اطمینان از اینکه این اتفاق می‌افتد.
پایش برای درخواست‌های عملکرد در محیط‌های ادغام مداوم (CI)
Lighthouse-CI به شما امکان می‌دهد ممیزی‌های Lighthouse را به‌طور خودکار روی ثبت کدها اجرا کنید تا از ورود پسرفتهای عملکردی به کد جلوگیری کنید. این کار می‌تواند زمان‌بندی‌های عملکرد (که درمعرض تغییرپذیری هستند) را بررسی کند، یا فقط برای ممیزی‌های عملکرد، به‌عنوان ابزار linting برای جلوگیری از شیوه‌های بد در کد استفاده شود.
مشاهده روندهای سلامت وب‌سایت با داده‌های فیلد
درحالی‌که باید هدف شما شناسایی و رفع همه مشکلات عملکردی قبل‌از رسیدن به مرحله تولید باشد، نظارت بر داده‌های میدانی بااستفاده از RUM برای یافتن هرگونه مشکلی که ممکن است از قلم افتاده باشد ضروری است. محصولات تجاری RUM زیادی دردسترس هستند که می‌توانند در این زمینه کمک کنند. کتابخانه جاوا اسکریپت web-vitals می‌تواند جمع‌آوری داده‌های میدانی وب‌سایت را خودکار کند و به‌طور اختیاری از این داده‌ها برای تقویت داشبوردهای سفارشی و سیستم‌های هشدار استفاده کند.
برای سایت‌های بدون راهکار RUM، می‌توانید از ابزارهای مختلف CrUX به‌عنوان تحلیل روند پایه داده‌های میدانی استفاده کنید.
نتیجه‌گیری
تضمین تجربه کاربری سریع و لذت‌بخش مستلزم داشتن ذهنیت «عملکرد در اولویت» و اتخاذ گردش کاری برای تضمین پیشرفت است. با ابزارها و فرایندهای مناسب برای ممیزی، اشکال‌زدایی، و پایش، ساختن تجربه‌های کاربری عالی و ماندن در آستانه‌های تعریف‌شده برای «اصول حیاتی وب» خوب در دسترس شما است.