در این مقاله یک چک لیست 35 مرحله‌ای Core Web Vitals را با شما به اشتراک می‌گذاریم که می‌توانید از آن برای بررسی وب‌سایت از نظر معیارهای سرعت و عملکرد گوگل به نام Web Vitals استفاده کنید.

• چک لیست Core Web Vitals به سه بخش تقسیم می شود که هر بخش بر یکی از سه معیار Core Web Vitals تمرکز دارد.
• هر مرحله تاثیری را که یک عنصر می‌تواند بر LCP، FID یا CLS داشته باشد، توضیح می‌دهد، مثالی ارائه می‌کند و راه‌حل‌های ممکن را پیشنهاد می‌کند.
• در انتهای لیست، یک پیشنهاد ارائه شده است که می توانید از آن برای انجام بررسی Core Web Vitals هر وب سایتی استفاده کنید.

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

1. ابزار برای حسابرسی هسته وب حیاتی
2. چک لیست 2 Core Web Vitals Audit
2.1. بزرگترین رنگ محتوایی (LCP)
2.2. بزرگترین رنگ محتوا و رندر سمت سرور
2.3. تاخیر ورودی اول (FID)
2.4. تغییر چیدمان تجمعی (CLS)

1. ابزارهایی برای بررسی Core Web Vitals

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

ابزارهای میدانی برای ممیزی Core Web Vitals:

• Google PageSpeed Insights (ابزاری ضروری برای تجزیه و تحلیل Core Web Vitals بر اساس هر صفحه)

کنسول جستجوی گوگل (گزارش Core Web Vitals) (ابزار ضروری برای تجزیه و تحلیل Core Web Vitals به صورت انبوه)

• گزارش تجربه کاربر Chrome (داده‌های گزارش CrUX توسط Google PageSpeed Insights و گزارش Core Web Vitals در GSC استفاده می‌شود)
• کتابخانه جاوا اسکریپت web-vitals (اگر توسعه دهنده هستید و می خواهید Core Web Vitals را در جاوا اسکریپت اندازه گیری کنید، به این ابزار نیازمند خواهید بود)

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

 

ابزارهای آزمایشگاهی برای ممیزی Core Web Vitals:

• Chrome DevTools (ابزار پیشرفته تری که به شما امکان می دهد نحوه بارگذاری سایت خود را به طور کامل تجزیه و تحلیل کنید)

 

• Lighthouse (ایده آل برای انجام آزمایشات و آزمایشات بهبود در محیط آزمایشگاه)

 

• WebPageTest (اگر می خواهید عمیقاً حفاری کنید عالی است)

 

• افزونه Web Vitals Chrome (این برنامه Core Web Vitals را در زمان واقعی روی دسکتاپ اندازه گیری می کند)

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

2. چک لیست Core Web Vitals Audit

این چک لیست Core Web Vitals شامل تمام موارد ممکنی است که باید هنگام بررسی سایت از نظر Core Web Vitals، سیگنال‌های تجربه صفحه گوگل و عملکرد و سرعت کلی بررسی کنید. توجه داشته باشید که اجرای این اصلاحات در بسیاری از موارد نیازمند دانش برنامه نویسی است. شما – به عنوان یک سئوکار – می توانید این چک لیست را به عنوان مجموعه ای از دستورالعمل ها برای توسعه دهندگانی که اصلاحات را تحت راهنمایی شما پیاده سازی می کنند، در نظر بگیرید. توجه داشته باشید که Core Web Vitals تنها یکی از فاکتورهای سئوی درون صفحه هستند.

2.1. بزرگترین رنگ محتوایی (LCP)

Largest Contentful Paint (LCP) عملکرد بارگذاری یک صفحه وب را اندازه گیری می کند. یک وب‌سایت در صورتی که معیار LCP آن کمتر یا برابر با 2.5 ثانیه باشد، تجربه کاربری خوبی ارائه می‌کند.

به زبان ساده، LCP زمان بارگذاری را با محاسبه سرعت بارگیری محتوای اصلی صفحه وب اندازه گیری می کند. یک بلوک متنی یا یک تصویر معمولاً محتوای اصلی در نظر گرفته می شود. ابزارهای میدانی برای اندازه گیری LCP:

• Google PageSpeed Insights (ابزاری که باید هر بار که Core Web Vitals را بر اساس هر صفحه ممیزی می‌کنید از آن استفاده کنید)
• Google Search Console (گزارش Core Web Vitals) (ابزار ضروری برای بررسی Core Web Vitals در کل وب سایت)

• Chrome User Experience Report (داده‌های گزارش CrUX توسط Google PageSpeed Insights و Google Search Console استفاده می‌شود.
• کتابخانه جاوا اسکریپت web-vitals (اگر توسعه دهنده هستید)

ابزارهای آزمایشگاهی برای اندازه گیری LCP:

• Chrome DevTools (LCP سایت آزمایش شده را به شما نشان می دهد)

• Lighthouse (این ابزار شبیه PSI کار می کند زیرا PSI داده های آزمایشگاهی را از Lighthouse می گیرد)

• WebPageTest (ابزاری ایده آل برای کاربران حرفه ای که می خواهند عمیقاً در مورد نحوه بارگیری سایت تحقیق کنند)
• افزونه Web Vitals Chrome (ابزاری عالی برای آزمایش Core Web Vitals برای دسکتاپ و در محیط آزمایشگاه)

برای انجام این بررسی، توصیه می کنیم از Google PageSpeed Insights و گزارش GSC Core Web Vitals برای بررسی داده های میدانی در مورد LCP استفاده کنید. علاوه بر این، مطمئن شوید که از Chrome DevTools، Lighthouse و WebPageTest برای بررسی اینکه چه چیزی به عنوان LCP صفحه وب آزمایش شده در نظر گرفته می شود، استفاده کنید.

1. بررسی کنید که آیا سرور به درستی بهینه شده است؟

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

در اینجا کارهایی که می توانید انجام دهید، آورده شده است:

• وب سایت را با ابزار Google PageSpeed Insights تست کنید. این ابزار نشان می دهد که آیا مشکلات پاسخ سرور کند در سایت وجود دارد یا خیر.

• بسیاری از ارائه دهندگان هاست به شما اجازه می دهند برخی از بهینه سازی های اولیه سرور را پیاده سازی کنید.
• یکی از بهینه‌سازی‌هایی که می‌توانید انجام دهید، به‌روزرسانی PHP به آخرین نسخه است.
• گوگل راهنمای خوبی در مورد نحوه بهینه سازی یک سرور اضافه بار دارد.

2. بررسی کنید که آیا از یک شبکه تحویل محتوا (CDN) استفاده می شود؟

یک شبکه تحویل محتوا (CDN) یک شبکه توزیع شده جغرافیایی از سرورها است که با یکدیگر برای ارائه سریع منابع وب سایت کار می کنند. وب‌سایتی که از CDN استفاده می‌کند سریع‌تر بارگذاری می‌شود، زیرا کاربران آن مجبور نیستند منتظر درخواست‌های شبکه به سرورهای دوردست بمانند. به جای آن از سرورهای واقع در همسایگی استفاده خواهد شد.

• بررسی کنید که آیا وب سایت از CDN استفاده می کند. برای بررسی سریع آن می توانید از ابزار CDN Finder استفاده کنید.

• اگر سایت از CDN استفاده نمی کند، توصیه می کنیم که از این ابزار استفاده کنید. CDN های زیادی وجود دارد. محبوب ترین آنها Cloudflare است که رایگان است.

3. بررسی کنید که آیا محتواهای وب سایت دارای کش هستند؟

ذخیره کردن محتواهای وب‌سایت یکی از مهم‌ترین عوامل بهبودهای سرعت و عملکرد است که مستقیماً بر متریک Largest Paint تأثیر می‌گذارد. اگر کد HTML وب سایت ثابت است (و نیازی به تغییر آن در هر درخواستی نیست)، پس – به لطف کش – نیازی به ایجاد مجدد آن نیست. این موضوع می تواند به طور قابل توجهی متریک TTFB را کاهش دهد و استفاده از منابع را به حداقل برساند.

• از ابزار Google PageSpeed Insights برای بررسی اینکه آیا محتوای وب‌سایت در حافظه پنهان هستند یا خیر، استفاده کنید.
• این ابزار فهرستی از منابعی را نشان می دهد که در حافظه پنهان ذخیره نمی شوند یا از کش استفاده نمی کنند.

• توصیه به استفاده از کش سرور. راه های مختلفی برای استفاده از کش سرور وجود دارد:
  1. پروکسی های معکوس مانند Varnish یا Nginx را دسته بندی کنید تا مانند یک سرور کش عمل کنند یا محتوای کش را ارائه دهند.
  2. حافظه های ابری خود، مانند Azure یا AWS را برای ذخیره محتواها دسته بندی کنید.
  3. از CDN استفاده کنید.

4. بررسی کنید که آیا صفحات HTML به طور کامل یا جزئی در ابتدا در حافظه پنهان ارائه می شوند؟

سرویس کش صفحات HTML ابتدا امکان ذخیره برخی یا تمام محتوای HTML یک صفحه وب و به روز رسانی کش را تنها در صورت تغییر محتوا فراهم می کند. این موضوع را می توان با استفاده از یک سرویس دهنده که در پس زمینه اجرا می شود و هرگونه درخواست سرور را رهگیری می کند، انجام می شود. استفاده از یک سرویس‌دهنده می‌تواند به طور قابل‌توجهی متریک Largest Contentful Paint را بهبود بخشد.

• می‌توانید از افزونه Service Worker Detector Chrome برای بررسی اینکه آیا یک وب‌سایت از یک Service Worker استفاده می‌کند استفاده کنید.

• اگر سایت از یک سرویس دهنده استفاده نمی کند، استفاده از آن را توصیه کنید.
• توسعه‌دهنده باید بداند که چگونه یک سرویس‌کار را برای دستیابی به بارهای کوچک‌تر HTML پیاده‌سازی کند.

5. بررسی کنید که آیا اتصالات شخص ثالث زودتر برقرار شده است؟

اگر اتصالات شخص ثالث در اسرع وقت برقرار شود، می توان LCP را به میزان قابل توجهی کاهش داد. ایجاد اتصالات شخص ثالث به ویژه در صورتی مهم است که درخواست سرور به منابع شخص ثالث برای نمایش محتوای حیاتی صفحه وب ضروری باشد. یک وب سایت می تواند از “rel=”preconnect یا “rel=”dns-prefetch برای این کار استفاده کند.

• وب سایت را با استفاده از ابزار Google PageSpeed Insights آزمایش کنید تا بررسی کنید که آیا اتصالات شخص ثالث زودتر برقرار شده است یا خیر.
• اگر سایت از rel=”preconnect” استفاده می‌کند، ابزار آن را  علامت‌گذاری می‌کند.

• شما می توانید یکی از راه حل های زیر را توصیه کنید:
  1. از rel=”پیش اتصال” استفاده کنید
  2. از rel=”dns-prefetch” استفاده کنید
  3. یا از rel=”dns-prefetch” به عنوان بازگشتی برای مرورگرهایی استفاده کنید که از rel=”preconnect” پشتیبانی نمی کنند (بیشتر توصیه می شود)

6. بررسی کنید که آیا CSS به حداقل میزان مسدود شدن رسیده است؟

صفحه‌های سبک و اسکریپت‌ها منابعی هستند که رندر را مسدود می‌کنند که تأثیر منفی بر تاخیر اول ورودی (FID) و بزرگترین رنگ محتوایی (LCP) دارند. سایت باید حداقل مقدار CSS لازم برای مسدود کردن رندر را داشته باشد. Minification یکی از راه‌های کاهش میزان مسدود کردن CSS است.

• سایت را با Google PageSpeed Insights تست کنید تا ببینید CSS کوچک شده است یا خیر.
• این ابزار نشان می دهد که آیا CSS به حداقل میزان مسدود شدن رسیده است یا خیر.

• برای وب‌سایت‌هایی که از مسدود کننده ماژول یا ابزار ساخت استفاده می‌کنند، باید افزونه‌ای ویژه برای فشرده سازی فایل‌های CSS را توصیه کنید.
  1. بهینه سازی-css-assets-webpack-plugin (برای بسته وب)
  2. gulp-clean-css (برای Gulp)
  3. rollup-plugin-css-porter (برای Rollup)

7. بررسی کنید که آیا CSS غیر بحرانی حذف شده است؟

CSS غیر بحرانی باید به تعویق بیفتد زیرا می تواند تأثیر زیادی بر متریک Largest Contentful Paint داشته باشد و یک منبع مسدودکننده رندر است. راه دیگر برای بهینه سازی تحویل CSS، به تعویق انداختن CSS غیر بحرانی است که زمان مسدود شدن CSS را به حداقل می رساند.

• با استفاده از برگه Coverage در Chrome DevTools می‌توانید هر CSS استفاده‌نشده را در صفحه وب پیدا کنید.

• ابزار Google PageSpeed Insights همچنین CSS غیر بحرانی را که ممکن است به تعویق بیفتد شناسایی می کند.

• توصیه کنید هر CSS استفاده نشده به طور کامل حذف شود یا اگر در صفحه وب دیگری استفاده می شود به شیوه نامه دیگری منتقل شود.
• در مورد CSS که برای رندر اولیه مورد نیاز نیست، توصیه کنید فایل ها را به صورت ناهمزمان با استفاده از loadCSS بارگیری کنید.
  <link rel=”preload” href=”stylesheet.css” as=”style” onload=”this.rel=’stylesheet'”>

8. بررسی کنید که آیا CSS بحرانی درون خطی است؟

قرار دادن سبک‌های مهم، سرعت CSS بحرانی را برای مرورگر بسیار سریع‌تر می‌کند، که LCP صفحه را بهبود می‌بخشد. هر CSS مهمی که در قسمت بالای صفحه وب سایت استفاده می شود، باید مستقیماً در <head> درج شود.

• وب سایت را با Google PageSpeed Insights آزمایش کنید تا بررسی کنید که آیا CSS حیاتی درون خطی است یا خیر.

• اگر CSS بحرانی درون خطی نیست، یکی از موارد زیر را توصیه کنید:
  1. اضافه کردن دستی استایل های درون خطی به سایت.
  2. استفاده از کتابخانه برای خودکارسازی فرآیند. نمونه هایی از کتابخانه ها عبارتند از Critical، CriticalCSS و Penthouse. همچنین یک پلاگین webpack Critters وجود دارد.
  3. در مورد وب سایت های وردپرسی، می توانید از یکی از افزونه های بهینه سازی متعدد استفاده کنید. من WP Rocket را توصیه می کنم.

9. بررسی کنید که آیا فایل های جاوا اسکریپت کوچک و فشرده شده اند؟

با کاهش میزان مسدود کردن جاوا اسکریپت می توانید امتیاز LCP وب سایت را به میزان قابل توجهی کاهش دهید. سایت باید فقط حداقل مقدار جاوا اسکریپت لازم را به کاربران ارائه دهد. هدف کوچک‌سازی جاوا اسکریپت ایجاد یک فایل JS سبک‌تر اما همچنان معتبر با حذف هرگونه فضای خالی یا کد غیر ضروری است.

• ابزار Google PageSpeed Insights به شما نشان می دهد که آیا فایل های جاوا اسکریپت در صفحه وب کوچک شده اند یا خیر.

• اگر JS کوچک نشده باشد، ممیزی باید کوچک سازی JS را توصیه کند. اصلاحاتی که می توانید توصیه کنید عبارتند از:
  1. یک ابزار فشرده سازی محبوب JS به نام Terser.
  2. Webpack نسخه 4 یا بالاتر دارای افزونه ای است که به طور پیش فرض فایل ها را برای این کتابخانه کوچک می کند. WP Rocket یک افزونه درخشان وردپرس است که می تواند این کار را به صورت خودکار انجام دهد.

10. بررسی کنید که آیا جاوا اسکریپت استفاده نشده به تعویق افتاده است؟

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

• صفحه وب را با استفاده از ابزار Google PageSpeed Insights آزمایش کنید تا بررسی کنید که آیا جاوا اسکریپت استفاده نشده را شناسایی می کند یا خیر.

• همچنین می‌توانید از Chrome DevTools (برگه Coverage همانطور که در بالا نشان داده شده است) استفاده کنید تا ببینید صفحه وب چقدر جاوا اسکریپت استفاده نشده دارد.
• یکی از بهترین راه‌ها برای رفع این مشکل، به تعویق انداختن اسکریپت‌های غیر بحرانی جاوا اسکریپت و شخص ثالث با استفاده از async یا defer است.
• به طور کلی، همه اسکریپت های شخص ثالث باید به طور پیش فرض با استفاده از async یا defer بارگذاری شوند.
  <script defer src=”…”></script>
  <script async src=”…”></script>

11. بررسی کنید که آیا پلی پرهای استفاده نشده به حداقل رسیده است؟

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

• وب‌سایت‌هایی که از ترانسپایلر Babel استفاده می‌کنند می‌توانند از @babel/preset-env استفاده کنند تا فقط پلی‌فیل‌های مورد نیاز برای مرورگرهای مورد نظر را شامل شود یا گزینه رفع اشکال را برای بهینه‌سازی بیشتر polyfill‌های غیرضروری فعال کنند.
• شما می توانید از <script type=”module”> برای جلوگیری از ارسال کد انتقال یافته به مرورگرهایی که به آن نیاز ندارند استفاده کنید.
• دو بسته جداگانه با استفاده از الگوی ماژول/نومول تحویل دهید.
• این وظیفه یک توسعه دهنده است که سایت را تجزیه و تحلیل کند و تصمیم بگیرد که آیا و چگونه polyfills را بهینه کند.
• توسعه‌دهنده می‌تواند در اینجا درباره بهینه‌سازی پلی‌فیل‌های استفاده نشده بیشتر بیاموزد.

12. بررسی کنید که آیا تصاویر بهینه و فشرده شده اند؟

زمان مورد نیاز برای بارگیری انواع مختلف منابع نیز می تواند بر بزرگترین امتیاز رنگ محتوای صفحه وب تأثیر بگذارد. انواع منابعی که بر LCP تأثیر می‌گذارند عبارتند از عناصر <img>، عناصر <video>، عناصر <image> در عنصر <svg>، عناصر با تصویر پس‌زمینه بارگذاری شده با url()، عناصر سطح بلوک با گره‌های متنی، و موارد دیگر. انواع عناصر متن درون خطی بهترین راه برای بهبود زمان بارگذاری، بهینه سازی و فشرده سازی تصاویر است.

Google PageSpeed Insights نشان می دهد که آیا منابعی وجود دارد که نیاز به بهینه سازی دارند. این ابزار همچنین به شما می گوید که چه نوع بهینه سازی هایی در یک مورد خاص توصیه می شود.

• بررسی کنید که آیا یک تصویر بعد از بارگیری صفحه، بزرگترین عنصر در ویوپورت است یا خیر. نمونه‌های رایج آن تصاویر بنر، چرخ فلک‌های بزرگ و تصاویر قهرمان هستند.
• برخی از راه‌های بهبود زمان بارگذاری و رندر تصاویر عبارتند از:
  1. از استفاده از یک تصویر به عنوان قطعه اصلی محتوا در ویوپورت خودداری کنید.
  2. فشرده سازی تصاویر
  3. از تصاویر واکنش گرا استفاده کنید.
• تصاویر را به فرمت های جدید مانند JPEG 2000، JPEG XR یا WebP تبدیل کنید.
• در مورد سایت های وردپرسی، می توانید از افزونه هایی مانند WP Rocket و Imagify استفاده کنید.

13. بررسی کنید که آیا منابع مهم از قبل بارگذاری شده اند؟

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

در اینجا کارهایی که باید در حسابرسی خود انجام دهید و توصیه کنید آمده است:

• صفحه وب را با ابزار Google PageSpeed Insights تست کنید. این ابزار نشان می دهد که آیا درخواست های کلیدی از قبل بارگذاری شده اند یا خیر.

• اگر درخواست‌های کلیدی از قبل بارگیری نشده‌اند، توصیه می‌کنید از <link rel=”preload”> برای واکشی اولیه این منابع استفاده کنید.
• در مورد وب سایت های وردپرسی، می توانید با استفاده از یک افزونه خاص مانند WP Rocket، این فرآیند را خودکار کنید.

14. بررسی کنید که آیا فایل های متنی فشرده شده اند؟

فشرده سازی منابع و فایل های متنی می تواند زمان بارگذاری یک صفحه وب را به میزان قابل توجهی بهبود بخشد و در نتیجه امتیاز Largest Contentful Paint را کاهش دهد. اندازه فایل های متنی مانند HTML، جاوا اسکریپت یا CSS را می توان با استفاده از الگوریتم های فشرده سازی مانند Gzip یا Brotli کاهش داد.

کارهایی که باید انجام دهید و در نظر داشته باشید:

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

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

15. بررسی کنید که آیا از سرویس تطبیقی استفاده می شود؟

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

• اگر سایتی که حسابرسی می کنید از سرویس تطبیقی استفاده نمی کند و دارایی های عظیمی دارد که می تواند به صورت مشروط ارائه شود، می توانید یکی از API های زیر را توصیه کنید:
  1. اطلاعات شبکه
  2. حافظه دستگاه
  3. ارز سخت افزاری
• برای مثال، اگر سرعت اتصال به اینترنت از 4G کندتر است، می‌توانید به جای ویدیو، یک تصویر نمایش دهید.
  } if (nagigator.connection && nagivator.connection.effectiveType)
  } if (nagivator.connection.effectiveType===’4g’)
  // Load video
  } else {
  }
  {

2.2. بزرگترین رنگ محتوا و رندر سمت سرور

سه نکته زیر در بررسی Core Web Vitals به ویژه برای وب‌سایت‌هایی که از چارچوب‌ها و کتابخانه‌هایی مانند Angular، React یا Vue استفاده می‌کنند که در بسیاری از موارد صفحات وب را به جای سرور، روی کلاینت ارائه می‌کنند، مهم است.

16. بررسی کنید که آیا جاوا اسکریپت حیاتی به حداقل رسیده است؟

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

بهترین راه برای بهینه سازی سایت هایی که در سمت مشتری رندر می شوند، به حداقل رساندن مقدار جاوا اسکریپت استفاده شده است.

• صفحه وب را با ابزار Google PageSpeed Insights تست کنید تا ببینید جاوا اسکریپت بهینه شده است یا خیر. ابزار هر فرصتی را در این زمینه نشان خواهد داد.

• شما می توانید توصیه هایی را از نکات 9، 10 و 11 ارائه کنید که عبارتند از:
  1. کوچک سازی جاوا اسکریپت
  2. به تعویق انداختن فایل های جاوا اسکریپت استفاده نشده
  3. به حداقل رساندن پلی پرهای استفاده نشده
• این توسعه دهنده است که تصمیم نهایی را در مورد اینکه آیا و چگونه جاوا اسکریپت را در یک سایت خاص بهینه کند می گیرد.

17. بررسی کنید که آیا رندر سمت سرور قابل استفاده است؟

استفاده از رندر سمت سرور نیز می تواند به بهبود معیارهای Largest Contentful Paint کمک کند. رندر سمت سرور به گونه ای عمل می کند که محتوای اصلی صفحه بر روی سرور رندر می شود نه روی کلاینت. این می تواند LCP را به طور قابل توجهی بهبود بخشد، اما در عین حال، می تواند زمان پاسخ سرور را افزایش دهد و زمان تا اولین بایت (TTFB) و زمان به تعامل (TTI) را بدتر کند.

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

18. بررسی کنید که آیا از پیش رندر استفاده شده است؟

پیش رندر روش دیگری برای بهبود معیارهای Largest Contentful Paint است. پیش رندر در مقایسه با رندر سمت سرور پیچیدگی کمتری دارد، اما همچنین می تواند به بهبود LCP کمک کند. درست مانند رندر سمت سرور، پیش رندر می‌تواند تأثیر منفی بر زمان تعامل (TTI) داشته باشد، اما بر زمان پاسخگویی سرور تأثیر چندانی ندارد.

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

 

کارهای زیادی برای بهبود LCP باید انجام شود، اینطور نیست؟ حال بیایید دو معیار باقیمانده را تحلیل کنیم.

 

2.3. تاخیر ورودی اول (FID)

تاخیر ورودی اول (FID) تعامل یک صفحه وب را اندازه گیری می کند. یک وب سایت تجربه کاربری خوبی را ارائه می دهد اگر صفحات آن امتیاز FID برابر یا کمتر از 100 میلی ثانیه داشته باشند.

اولین تاخیر ورودی به ورودی واقعی کاربر نیاز دارد، بنابراین نمی توان آن را در آزمایشگاه اندازه گیری کرد. زمان انسداد کل (TBT) متریکی است که نزدیک‌ترین مقدار به FID است، با FID همبستگی دارد و می‌تواند در آزمایشگاه اندازه‌گیری شود. Time to Interactive (TTI) همچنین می تواند به عنوان یک شاخص آزمایشگاهی برای FID استفاده شود.

بهبود در زمان انسداد کل (TBT) معمولاً منجر به بهبود تاخیر ورودی اول (FID) می شود. اجرای سنگین جاوا اسکریپت معمولاً دلیل اصلی امتیاز ضعیف FID است. بنابراین، بهترین راه برای بهبود FID، بهینه سازی تجزیه، کامپایل و اجرای جاوا اسکریپت است. گوگل اخیراً معیار آزمایشی جدیدی را معرفی کرده است – Interaction To Next Paint (INP) – که ممکن است جایگزین FID شود.

ابزار اندازه گیری FID:

• Google PageSpeed Insights (این ابزاری است که باید برای ممیزی FID بر اساس هر صفحه استفاده کنید، با این فرض که گزارش CrUX داده های کافی برای سایت دارد).

• کنسول جستجوی گوگل (گزارش Core Web Vitals) (این یک ابزار ضروری برای بررسی مقادیر واقعی FID در کل وب سایت است)

• گزارش تجربه کاربر Chrome (داده‌های CrUX توسط PSI و Lighthouse استفاده می‌شود)
• کتابخانه جاوا اسکریپت web-vitals (اگر توسعه دهنده هستید و می خواهید از برنامه خود برای اندازه گیری FID استفاده کنید)

برای اهداف این ممیزی، توصیه می کنم از Google PageSpeed Insights و گزارش GSC Core Web Vitals برای بررسی FID استفاده کنید. توجه داشته باشید که FID فقط بر اساس داده های میدانی قابل اندازه گیری است. از ابزارهای آزمایشگاهی مانند Chrome DevTools، Lighthouse و WebPageTest برای بررسی سایر معیارها مانند TTI و TTB که با FID مرتبط هستند و همچنین شاخص های خوبی برای آمادگی تعامل هستند، استفاده کنید.

19. بررسی کنید که آیا وظایف طولانی جاوا اسکریپت شکسته شده است؟

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

• از ابزار Google PageSpeed Insights برای بررسی اینکه آیا بهینه سازی جاوا اسکریپت وجود دارد یا خیر استفاده کنید.

• از ابزارهای توسعه دهنده Chrome برای بررسی اینکه آیا کارهای طولانی در وب سایت وجود دارد یا خیر استفاده کنید.
• تنها کاری که باید انجام دهید این است که ردی از بارگذاری یک صفحه وب (در پنل عملکرد) ثبت کنید. همه وظایف به رنگ خاکستری نشان داده شده اند و کارهای طولانی دارای پرچم قرمز هستند.

• همچنین می توانید از Lighthouse برای بررسی اینکه آیا کارهای طولانی وجود دارد یا خیر استفاده کنید.

• کارهای طولانی را تجزیه و تحلیل کنید و بازخورد خود را به توسعه دهنده ارائه دهید که پیشنهاد می کند این کارهای طولانی باید به کارهای کوچکتر تقسیم شوند.
• شما می توانید در مورد وظایف طولانی جاوا اسکریپت در web.dev اطلاعات بیشتری کسب کنید.

20. بررسی کنید که آیا اجرای اسکریپت شخص اول تأثیر منفی بر آمادگی تعامل دارد؟

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

• سایت را با Google PageSpeed Insights یا Lighthouse آزمایش کنید و نمرات معیارهایی را که بر آمادگی تعامل تأثیر می‌گذارند بررسی کنید.

• معیارهایی که باید بررسی شوند عبارتند از: تاخیر ورودی اول (FID)، زمان انسداد کل (TBT) و زمان تعامل (TTI).
• همچنین می‌توانید از Chrome DevTools برای بررسی معیارهای مربوط به FID استفاده کنید.
• یافته های خود را در ممیزی گزارش دهید. می توانید موارد زیر را توصیه کنید:
  1. بارگذاری تدریجی کد
  2. رندر سمت سرور یا پیش رندر بسته به نوع وب سایت و برنامه.
  3. حذف اسکریپت های غیر ضروری از مسیر رندر بحرانی.

21. بررسی کنید که آیا واکشی داده بر آمادگی تعامل تأثیر منفی دارد؟

واکشی داده ها همچنین می تواند تأثیر منفی بر بسیاری از جنبه های آمادگی تعاملی سایت داشته باشد. این معمولاً در صورتی اتفاق می‌افتد که یک وب‌سایت به واکشی داده‌های آبشاری متکی باشد و اگر تعداد زیادی از اجرای اسکریپت بر روی مشتری انجام شود.

• بسته به نمرات FID، TTI، و TBT گزارش شده توسط Google PageSpeed Insights یا Lighthouse، می توانید برخی بهینه سازی های واکشی داده جاوا اسکریپت را توصیه کنید.

• بهینه‌سازی‌های جاوا اسکریپت برای توصیه شامل تاکتیک‌هایی مانند:
  1. به حداقل رساندن واکشی داده های آبشاری.
  2. به حداقل رساندن مقدار جاوا اسکریپت برای پردازش و اجرا بر روی مشتری.
  3. تاکتیک‌هایی که قبلاً در این راهنما با شما به اشتراک گذاشتم (کوچک‌سازی و فشرده‌سازی جاوا اسکریپت، به تعویق انداختن جاوا اسکریپت استفاده‌نشده، و به حداقل رساندن چندپرهای استفاده نشده).
• توجه داشته باشید که این توسعه دهنده باید تصمیم نهایی را در مورد نحوه بهینه سازی جاوا اسکریپت در وب سایت بگیرد.

22. بررسی کنید که آیا اجرای اسکریپت شخص ثالث بر آمادگی تعامل تأثیر منفی دارد؟

اجرای اسکریپت شخص ثالث (به خصوص اگر سنگین باشد) می تواند تأثیر منفی بر تأخیر تعامل سایت داشته باشد. اسکریپت های شخص ثالث می توانند موضوع اصلی را به صورت دوره ای مشغول و بدون پاسخ نگه دارند. خوشبختانه، چند روش برتر اجرای اسکریپت شخص ثالث، مانند بارگیری بر اساس تقاضا، وجود دارد.

• وب‌سایت را با Google PageSpeed Insights آزمایش کنید تا ببینید آیا اسکریپت‌های شخص ثالث بر معیارهایی مانند FID، TTB و TTI تأثیر منفی می‌گذارند.

• بررسی کنید که آیا سایت دارای تجزیه و تحلیل های شخص ثالث و برچسب هایی است که بر تأخیر تعامل تأثیر می گذارد.

• بررسی کنید که آیا اسکریپت های شخص ثالث از اسکریپت های شخص اول در مورد اولویت و پهنای باند آنها در رشته اصلی استفاده می کنند یا خیر. می‌توانید آن را در Chrome DevTools در بخش Network بررسی کنید.

• یافته‌های خود را گزارش کنید و تکنیک‌های بهینه‌سازی ممکن را پیشنهاد دهید، مانند:
  1. بارگیری تبلیغات زیر صفحه بعد از نزدیک‌تر شدن به نمای دید
  2. اولویت بندی بارگذاری اسکریپت ها
• تصمیم نهایی در مورد اینکه چه اسکریپتی باید زودتر یا دیرتر بارگذاری شود باید توسط توسعه دهنده گرفته شود.

23. بررسی کنید که آیا یک وب کارگر وجود دارد یا می توان از آن استفاده کرد (Comlink، Workway، Workerize)؟

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

• وب سایت را با Google PageSpeed Insights، Lighthouse و Chrome DevTools آزمایش کنید تا بررسی کنید که آیا رشته اصلی مسدود شده است و چه چیزی آن را مسدود می کند.

• بسته به نوع وب‌سایت، می‌توانید از یکی از وب‌کارهای زیر استفاده کنید:
  1. کاملینک
  2. مسیر کار
  3. کارگری کنید
• درست مانند نکات قبلی، این برنامه باید تصمیم نهایی را در مورد بهینه سازی هایی که دقیقاً پیاده سازی کند، بگیرد.

24. بررسی کنید که آیا جاوا اسکریپت استفاده نشده به تعویق افتاده است؟

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

25. بررسی کنید که آیا پلی پرهای استفاده نشده به حداقل رسیده است؟

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

2.4. تغییر چیدمان تجمعی (CLS)

چیدمان تجمعی (CLS) ثبات بصری یک وب سایت را اندازه گیری می کند. یک وب سایت در صورتی که CLS صفحات آن برابر یا کمتر از 0.1 باشد، تجربه کاربری خوبی را ارائه می دهد.

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

ابزارهای میدانی برای اندازه گیری تغییر چیدمان تجمعی:

• Google PageSpeed Insights (ابزار ضروری برای اندازه‌گیری CLS بر اساس هر صفحه)

 

• کنسول جستجوی گوگل (گزارش Core Web Vitals) (ابزار ضروری برای بررسی CLS در کل وب سایت بر اساس داده های دنیای واقعی).

 

• گزارش تجربه کاربر Chrome (داده‌های گزارش CrUX در GSC، PSI، و Lighthouse استفاده می‌شود)
• کتابخانه جاوا اسکریپت web-vitals (راه حلی که ممکن است بخواهید اگر توسعه دهنده هستید از آن استفاده کنید)
  

  ابزارهای آزمایشگاهی برای اندازه گیری تغییر چیدمان تجمعی:

• Chrome DevTools (ایده آل برای حسابرسی CLS با جزئیات در محیط آزمایشگاه)
• Lighthouse (ایده آل اگر می خواهید بهینه سازی های خود را در زمان واقعی آزمایش کنید)

• WebPageTest (اگر شما یک گیک هستید و می خواهید به اطلاعات موجود در Core Web Vitals و نحوه بارگیری صفحه بپردازید، این ابزار برای شماست)
• Cumulative Layout Shift Gif Generator (ابزاری بسیار سرگرم کننده)

برای اهداف این ممیزی، توصیه می‌کنم از Google PageSpeed Insights و گزارش GSC Core Web Vitals برای بررسی داده‌های میدانی در CLS استفاده کنید. در مورد داده‌های آزمایشگاهی، از Chrome DevTools، Lighthouse و WebPageTest برای تجزیه و تحلیل CLS با استفاده از تنظیمات مختلف و وضوح صفحه استفاده کنید. تجمعی Layout Shift Gif Generator نیز می تواند بسیار سرگرم کننده باشد. هرچه ابزارهای بیشتری استفاده کنید، حسابرسی شما بهتر و عمیق تر خواهد بود.

26. بررسی کنید که آیا عناصر تصویر یا ویدیو بدون ابعاد وجود دارد؟

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

• وب‌سایت را با Google PageSpeed Insights و Lighthouse آزمایش کنید و – بسته به امتیاز CLS – توصیه کنید که فضای مناسبی را برای عناصر تصویر یا ویدیو رزرو کنید.

• توصیه می شود که ویژگی های اندازه عرض و ارتفاع به صورت عادی تنظیم شوند. این کد نمونه است:
  <–  set a 640:360 i.e a 16:9 -aspect ratio –!>
  “img src=”puppy.jpg” width=”640″ height=”360″ alt=”Puppy with balloons>
  </
• همه مرورگرهای مدرن نسبت ابعاد پیش‌فرض تصاویر را بر اساس اندازه‌های مشخص شده تنظیم می‌کنند که از تغییر طرح‌بندی جلوگیری می‌کند.

در مورد وب سایت های وردپرسی، این بهینه سازی ها اغلب با استفاده از یک افزونه به صورت خودکار انجام می شود. اما استفاده از WP Rocket را نیز توصیه می کنیم.

27. بررسی کنید که آیا فضای ذخیره شده ایستا برای جایگاه آگهی وجود دارد؟

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

• صفحه وب را با ابزار Google PageSpeed Insights آزمایش کنید تا امتیاز CLS آن را بررسی کنید.
• در صورت امکان، داده های ارائه شده توسط گزارش GSC Core Web Vitals را تجزیه و تحلیل کنید.
• همچنین توصیه می‌کنم نمره تغییر چیدمان تجمعی را با ابزارهای دیگر (مانند Chrome DevTools، Lighthouse و WebPageTest) تجزیه و تحلیل کنید و از وضوح‌های مختلف صفحه استفاده کنید.

• اگر مشکلاتی با CLS وجود دارد، تعیین کنید که آیا این تبلیغ مقصر است یا خیر. اگر این تبلیغ است، می توانید یکی از موارد زیر را توصیه کنید:
  1. قبل از بارگیری کتابخانه تگ آگهی، با استایل دادن به عنصر، فضا را به صورت ایستا رزرو کنید.
  2. تبلیغاتی که در جریان محتوا قرار می‌گیرند نیز باید دارای اندازه اسلات رزرو شده باشند، اما اگر از روی صفحه بارگیری شوند، نباید باعث بروز مشکلات CLS شوند.

28. بررسی کنید که آیا تبلیغات در نزدیکی بالای پنجره نمایش قرار می گیرند؟

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

• صفحه را با ابزار Google PageSpeed Insights بررسی کنید تا امتیاز CLS آن را ببینید.
• گزارش Google Search Console Core Web Vitals همچنین حاوی داده های میدانی ارزشمندی در CLS است.
• مقدار متریک CLS گزارش شده توسط ابزارهای دیگر، مانند Chrome DevTools و WebPageTest را بررسی کنید. مطمئن شوید که تست هایی را با وضوح صفحه نمایش متفاوت اجرا کنید.
• اگر مشکلاتی با CLS وجود دارد، تعیین کنید که آیا این تبلیغ مقصر است یا خیر.
• اگر این آگهی است که در نزدیکی بالای نمای درج شده است، می توانید توصیه کنید:
  1. تبلیغ زیر را به گونه‌ای جابجا کنید که نزدیک بالای نمای درج نشود یا به طور کامل از صفحه اول خارج شود.
  2. رزرو فضای کافی برای شکاف (همانطور که در نکته قبل توصیه شد).

 

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

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

• صفحه وب را با بیش از یک ابزار آزمایش کنید تا ببینید در سناریوهای تبلیغاتی مختلف چگونه رفتار می کند.
• ممکن است تکرار شرایطی که هیچ تبلیغی برگردانده نمی شود و فضای رزرو شده از بین می رود بسیار چالش برانگیز باشد. ممکن است سعی کنید کد تبلیغات را مسدود کنید و بررسی کنید که چه اتفاقی می‌افتد (می‌توانید از یک مسدودکننده تبلیغات برای آن استفاده کنید).
• اگر فضای تبلیغاتی رزرو شده که از بین می‌رود مقصر اصلی است، می‌توانید موارد زیر را توصیه کنید:
  1. رزرو بزرگترین جایگاه تبلیغاتی ممکن
  2. همیشه مکان‌نمای آگهی را نشان می‌دهد.
  توصیه‌های بالا ممکن است منجر به ایجاد یک فضای خالی شود، اما از تغییر طرح جلوگیری می‌کند.

30. بررسی کنید که آیا فضای کافی برای embed و iframe در نظر گرفته شده است؟

جاسازی‌ها، مانند ویدیوهای YouTube، نقشه‌های گوگل، یا پست‌های رسانه‌های اجتماعی نیز می‌توانند باعث تغییر چیدمان شوند، اگر فضای کافی برای آن‌ها در نظر گرفته نشود. جاسازی‌ها می‌توانند شکلی از iframe embed، قطعه HTML درون خطی یا یک بازگشت HTML با تگ JS داشته باشند، پلتفرم‌هایی که اجازه جاسازی را می‌دهند (برای مثال وردپرس) همیشه نمی‌دانند اندازه یک جاسازی چقدر خواهد بود و بنابراین فضای کافی برای آن جاسازی ها رزرو نکنید. این، بدیهی است که منجر به تغییر چیدمان می شود.

• صفحه وب را با بیش از یک ابزار برای تجزیه و تحلیل سناریوهای مختلف تغییرات چیدمان تجمعی آزمایش کنید.
• اگر متوجه شدید که این یک جاسازی است که مقصر امتیاز ضعیف CLS یک وب سایت است، می توانید موارد زیر را توصیه کنید:
  1. فضای لازم برای جاسازی ها را با یک بک بک یا مکان نگهدار از قبل محاسبه کنید.
  2. اندازه جاسازی را با بررسی آن با DevTools تعیین کنید.
  3. با در نظر گرفتن ابعاد جاسازی بازرسی شده، یک مکان نگهدار استایل کنید.
  اطمینان حاصل کنید که توسعه دهنده تصمیم نهایی را در مورد اینکه چه چیزی و چگونه باید اجرا شود می گیرد.

31. بررسی کنید که آیا محتوای جدید بالای محتوای موجود درج شده است؟

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

تنها موقعیتی که درج محتوای جدید بالاتر از محتوای موجود درست است زمانی است که در پاسخ به تعامل کاربر انجام می شود.

• صفحه وب را با جزئیات با استفاده از حداقل 2-3 ابزار توصیه شده برای بررسی سناریوهای مختلف تغییر طرح بررسی کنید.
• اگر تشخیص می دهید که محتوای جدیدی که در بالای محتوای موجود درج شده است مقصر است، می توانید به سادگی توصیه کنید که فضای لازم را در ویوپورت رزرو کنید (مشابه کاری که باید با تبلیغات انجام دهید). این را می توان با استفاده از یک UI اسکلت یا یک مکان نگهدار انجام داد.

32. بررسی کنید که آیا فونت جایگزین با یک فونت جدید جایگزین شده است (FOUT)

فلش متن بدون استایل (FOUT) که ممکن است در طول فرآیند بارگیری و رندر فونت ها اتفاق بیفتد، می تواند باعث تغییر طرح بندی شود. Flash of Unstyled Text زمانی ظاهر می شود که فونت بازگشتی در یک صفحه وب با یک فونت جدید در حین بارگذاری جایگزین شود.

• ابزار Google PageSpeed Insights نشان می‌دهد که آیا صفحه وب با فونت‌هایی که باعث FOUT می‌شوند مشکل دارد یا خیر.
• پیشنهاد استفاده از font-display: اختیاری یا/و استفاده از <link rel=”preload”>.
• بهترین راه حلی که در اینجا توصیه می شود این است که فونت های اختیاری را از قبل بارگذاری کنید.

33. بررسی کنید که آیا متن “Invisible” نمایش داده می شود تا زمانی که یک فونت جدید ارائه شود (FOIT)

فلش متن نامرئی (FOIT) یکی دیگر از مشکلات رایج است که ممکن است باعث تغییر طرح بندی در یک صفحه وب شود. Flash of Invisible Text زمانی اتفاق می‌افتد که متن «نامرئی» در طول فرآیند رندر کردن فونت‌های وب نمایش داده شود.

توصیه ها و اصلاحات مانند بالا (برای FOUT) است.

34. بررسی کنید که آیا فونت های وب کلیدی از قبل بارگذاری شده اند؟

اگر سایت فونت‌های وب را از قبل بارگذاری نمی‌کند، احتمالاً در طول فرآیند رندر و بارگذاری اولیه، تغییراتی در طرح‌بندی ایجاد می‌شود. بهترین راه برای جلوگیری از مشکلات طرح‌بندی ناشی از فونت‌های وب، بارگذاری قبلی قلم‌های کلیدی با استفاده از <link rel=”preload”> است.

توصیه ها و اصلاحات:

• صفحه وب را با Google PageSpeed Insights و گزارش Google Search Console Core Web Vitals آزمایش کنید.
• ابزار Google PageSpeed Insights نشان می دهد که آیا مشکلی در ارائه یا دانلود فونت وجود دارد یا خیر.
• اگر تشخیص دادید که این فونت‌های وب هستند که باعث تغییر طرح‌بندی می‌شوند، باید موارد زیر را توصیه کنید:
  1. استفاده از font-display: optional
  2. استفاده از  Font Loading API
  3. استفاده از <link rel=”preload”> برای فونت های کلیدی وب
  4. ترکیب <link rel=”preload”> با font-display: اختیاری است

35. بررسی کنید که آیا انیمیشن هایی از ویژگی ها وجود دارد که باعث تغییرات طرح بندی می شود.

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

نمونه هایی از مقادیری که ممکن است باعث تغییر طرح شوند عبارتند از box-shadow و box-sizing.

• صفحه وب را با Google PageSpeed Insights و WebPageTest تست کنید.
• آبشار را تجزیه و تحلیل کنید و مشخص کنید که چه چیزی باعث تغییر چیدمان می شود.
• اگر فکر می‌کنید که انیمیشن‌های ویژگی‌ها مقصر هستند، مطالعه بیشتر در مورد محرک‌های CSS و انیمیشن‌های با کارایی بالا را بررسی کنید.

 

سخن پایانی

دراین مقاله که از سری مجموعه آموزش سئو پشتیبانی سئوهاما خدمت شما ارائه شد، به معرفی core web vitals که با تمرکز بر افزایش سرعت سایت و تجربه کاربر (از مهم ترین آپدیت های سال ۲۰۲۰ میلادی) پرداختیم و با معرفی متریک های آن، امتیاز بهینه و همچنین روش های بهبود آن ها شما را با این مفاهیم به صورت کامل آشنا ساختیم. گوگول روز به روز بیشتر به پارامترهای Core Web Vitals اهمیت می‌دهد و احتمالا در آینده ای نزدیک، وب سایت هایی که این پارامترها را بهینه نکرده باشند، جایی در نتایج جستجو نخواهند داشت. اما دقت داشته باشید که بهبود این پارامترها کاری زمان بر می باشد و توصیه می شود اگر بهبود سئو وب سایت و سئو تضمینی این پارامترها برای شما مهم است، قبل از انعقاد قرارداد، پشتیبانی سئوهاما که کار طراحی سایت را انجام میدهد درخواست کنید تا این پارامترها را برای شما بهینه می کند.