LCP یا همان Largest Contentful Paint یکی از مهم‌ترین عوامل تعیین‌کننده تجربه واقعی کاربر و سئو سایت است. LCP نشان‌دهنده این موضوع است که چقدر زمان می‌برد تا تمام محتوای شما بر روی صفحه نمایش رندر شود. First Contentful Pain نیز نشان‌دهنده این است که رندر ابتدایی محتوای DOM  چقدر زمان می‌برد و ارتباطی به بارگذاری بزرگ‌ترین محتوای تصویری در صفحه ندارد.

شاخص Largest Contentful Paint یا همان LCP یک استاندارد Core Web Vitals است و زمانی را اندازه‌گیری می‌کند که بزرگ‌ترین محتوا  بر روی صفحه به نمایش در می‌آید.

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

• سرعت کم پاسخ سرور
• انسداد رندر در جاوا اسکریپت یا CSS
• سرعت کم بارگذاری سورس اصلی
• Client-Side Rendering

در ادامه شما تمامی این دلایل و عوامل را به شما شرح خواهیم داد:

سرعت کم پاسخ سرور

هرچه بیشتر زمان ببرد تا مرورگر محتوا را از سرور دریافت کند، رندر با سرعت کمتری انجام می‌شود. پاسخ سریع سرور به‌صورت مستقیم باعث بهبود تمام شاخص‌های مرتبط با سرعت صفحه، از جمله LCP می‌شود. پیش از هر چیز دیگر، باید سرور خود را ارتقاء دهید.
 باید بدانید سرور شما کجا و چطور محتوای شما را مدیریت می‌کند و این مسئله را به‌خوبی ارتقاء دهید. شما می‌توانید از Time To First Byte (TTFB) برای اندازه‌گیری پاسخ سرور استفاده کنید. برای بهبود TTFB روش‌های مختلفی وجود دارد:

• سرور خود را بهینه‌سازی کنید
• کاربران را به یک CDN نزدیک‌تر هدایت کنید
• از Cache Assets کمک بگیرید
• یک ارتباط Third-Party ایجاد کنید
• از signed exchanges استفاده نمایید

سرور خود را بهینه‌سازی کنید

آیا به‌دنبال روش‌های گران‌قیمت برای بهبود زمان پاسخ سرور خود هستید؟ یا اینکه اپراتورهای پیچیده دیگری از سمت سرور باعث ایجاد این تأخیر در وبسایت شما می‌شوند؟ تحلیل و بهبود کد‌های سمت سرور باعث تغییرات چشم‌گیر در کاهش پاسخ‌دهی سرور می‌شود. در نتیجه وبسایت شما داده‌ها را با سرعت بیشتری از سرور دریافت خواهد کرد.
به جای آنکه بدون فوت وقت از یک صفحه استاتیک بر روی ریکوئست یک مرورگر استفاده کنید، باید بدانید که بسیاری از چارچوب‌های نرم‌افزاری تحت وب باید یک صفحه وب را به‌صورت پویا و دینامیک ارائه دهند. به زبان ساده‌تر به جای آنکه یک فایل کامل HTML را در زمان درخواست مرورگر ارسال کنید، خود چهارچوب نرم‌افزاری باید از لاجیک مخصوص خود برای ساخت آن صفحه دینامیک استفاده نماید.
 این مسئله ممکن است به‌خاطر نتایج معوقه یک دیتابیس کوئری باشد یا اینکه حتی شاید اجزایی وجود دارند که باید در ساختار UI ایجاد شود. بسیاری از چهارچوب‌های نرم‌افزاری تحت وب که بر روی سرور اجرا می‌شوند، دارای راهنمایی بهبود عملکرد هستند. با مطالعه این راهنما می‌توانید روند محاسبات را افزایش دهید.

کاربران را به یک CDN نزدیک‌تر هدایت کنید

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

استفاده از کَش سرور

اگر کد HTML شما استاتیک باشد، دیگر در هر بار درخواست، نیازی به تغییر ندارد. کَش از بازسازی غیرضروری دوباره این کد جلوگیری می‌کند. برای این کار می‌توانید یک نسخه کپی از کد HTML تولید‌شده را بر روی هارد درایو خود نگه دارید. کَش از سمت سرور می‌تواند منجر به کاهش TTFB و در نتیجه کاهش مصرف شما از منابع سرور شود.
بر اساس ToolChain  شما، روش‌های مختلفی برای اعمال کردن سرور کش وجود دارد:

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

از Cache-First در صفحات HTML استفاده کنید

زمانی که این سیستم را نصب کنید، یک Service Worker  در پس‌زمینه مرورگر کاربر اجرا خواهد شد و می‌تواند درخواست کاربر از سرور را کوتاه‌تر کند. این سطح از برنامه‌نویسی کنترل کَش باعث می‌شود تا بتوانید قسمتی یا تمام محتوای صفحه HTLM را کَش کنید و فقط زمانی که محتوا تغییر کرد، تنها کَش را آپدیت نمایید. شکل زیر کاهش توزیع LCP را در اثر استفاده از این الگوریتم نشان می‌دهد: 

این جدول توزیع LCP از یک سایت در 28 روز را نشان می‌دهد. هر بخش توسط یک Service Worker ایجاد شده است. در این جدول به تفاوت سرعت LCP بعد از اعمال Cache-first HTML دقت کنید. بخش آبی روشن نشان‌دهنده زمانی است که از این سرور استفاده کرده‌اند.

از یک کانکشن Third-Party استفاده کنید

درخواست سرور به یک اورجین یا URL شخص ثالث (Third-Party) نیز می‌تواند بر LCP وبسایت شما تأثیرگذار باشد. مخصوصاً اگر این درخواست مربوط به یک محتوای ضروری باشد، این تأثیرگذاری بیشتر احساس می‌شود. شما می‌توانید از rel="preconnect" استفاده کنید تا به مرورگر بگویید که این صفحه باید در کمترین زمان ممکن یک کانکشن ایجاد کند.

link rel="preconnect" href="https://example.com"

همچنین می‌توانید از dns-prefetch استفاده کنید تا لوک آپ DNS  سریع‌تر انجام شود. 

link rel="dns-prefetch" href="https://example.com"

با وجود اینکه این دو روش به‌صورت کامل با یکدیگر تفاوت دارند؛ اما dns-prefetch می‌تواند در مرورگرهایی که از  preconnect پشتیبانی نمی‌کنند، نقش یک فال بک  را ایفا کند.

از signed exchanges استفاده کنید (SXGs)

signed exchanges یک مکانیزم تحویل محسوب می‌شود. این مکانیزم باعث می‌شود تا محتوا سریع‌تر به دست کاربر برسد. این مکانیزم برای چنین کاری محتوا را در فرمتی ارائه می‌دهد که به‌راحتی قابل کش شدن باشد.
 این مکانیزم مخصوصاً در نتایج جستجو گوگل، signed exchanges را کَش و بعضی اوقات هم prefetch  می‌کند. SXGs یک ابزار بسیار مفید برای بهبود LCP وبسایت‌هایی محسوب می‌شود که بیشتر ترافیک خود را از طریق جستجو گوگل به دست می‌آورند.

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

پیش از آنکه یک مرورگر بتواند هر گونه محتوا را رندر کند، باید مارک آپ HTML را به یک درخت DOM تجزیه نماید. تجزیه شدن HTML به درخت DOM اگر با هرگونه استایل شیت link rel="stylesheet" یا تگ‌های جاوا اسکریپت همزمان script src="main.js" مواجه شود، متوقف خواهد شد.
اسکریپت‌ها و همچنین استایل شیت‌ها هر دو منبع انسداد را رندر می‌کنند. همین مسئله باعث ایجاد تعویق بیشتر در FCP و متعاقباً تعویق در LCP می‌شود. به تأخیر انداختن هر گونه جاوا اسکریپت و CSS غیرضروری می‌تواند باعث افزایش سرعت بارگذاری محتوای اصلی صفحه وبسایت شما شود.

کاهش زمان انسداد CSS

شما باید با روش‌های زیر مطمئن شوید که حداقل CSS انسداد کننده بر روی وبسایت شما رندر می‌شوند:

• CSS را تا حد امکان کوچک کنید
• CSS های غیرضروری را به تعویق بیاندازید
• از CSS های ضروری به‌صورت این‌لاین یا همان درون برنامه‌ای استفاده کنید

CSS را تا حد امکان کوچک کنید

برای خوانایی بیشتر، فایل CSS می‌تواند شامل کاراکترهایی همانند فاصله، دندانه یا کامنت‌های مختلف باشد. این کاراکترها همگی برای مرورگر غیرضروری هستند. با کاهش این کاراکترها، انسداد CSS نیز کاهش پیدا می‌کند. به این ترتیب زمان رندر محتوای اصلی پیج بهبود پیدا خواهد. در نتیجه شاهد بهبود شاخص LCP خواهیم بود.
Module Bundler یا Built Tool شامل پلاگین‌هایی می‌شوند که می‌توانید با کمک آن‌ها CSS خود را تا حد امکان کوچک‌تر کنید.

• برای Webpack می‌توانید از پلاگین optimize-css-assets-webpack-plugin استفاده نمایید.
• برای Gulp می‌توانید از پلاگین gulp-clean-css استفاده نمایید.
• برای Rollup می‌توانید از پلاگین rollup-plugin-css-porter استفاده نمایید.

CSS های غیر‌ضروری را به تأخیر بیاندازید

از بخش Coverage در Chrome DevTools استفاده نمایید تا هرگونه CSS غیرضروری که مورد استفاده قرار نمی‌گیرد را پیدا کنید.
برای بهبود CSS می‌توانید مراحل زیر را انجام دهید:

• شما می‌توانید یک CSS که استفاده‌ای از آن نمی‌شود را به‌صورت کامل حذف کنید. البته اگر فقط در یک صفحه وبسایت شما کاربرد دارد، می‌توانید آن را به یک استایل شیت دیگر منتقل کنید.
• اگر CSS در رندر ابتدایی صفحه مورد استفاده قرار نمی‌گیرد، از LoadCSS استفاده کنید تا فایل‌ها به‌صورت غیرهمزمان رندر شوند. برای این کار می‌توانید از لوریج rel="preload" و onload استفاده نمایید.

html از CSS های ضروری به‌صورت این‌لاین استفاده کنید

هر نوع CSS ضروری که در بخش بالایی محتوای صفحه  شما قرار دارد را به‌صورت مستقیم با تگ head و این‌لاین قرار دهید. با این‌لاین کردن استایل‌های مهم، برای انجام ریکوست، دیگر نیازی نیست کد بار از ابتدا خوانده شود. با به تأخیر انداختن مابقی CSSها، زمان انسداد CSS کاهش پیدا می‌کند. اگر به‌صورت دستی نمی‌توانید استایل را این لاین کنید، از یک لایبراری برای خودکار کردن این پروسه استفاده نمایید. به‌عنوان مثال:

• Critters یک پلاگین وب پک است که CSSهای ضروری را این‌لاین می‌کند و بار سنگین را به تأخیر می‌اندازد.
• همچنین Criticalv، CriticalCSS و Penthouse هم می‌توانند به‌صورت خودکار عملیات این‌لاین کردن را انجام دهند.

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

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

• فایل‌های جاوا اسکریپت را کوچک و فشرده کنید
• اسکریپت‌هایی که استفاده نمی‌شوند را به تأخیر بیندازید
• تعداد پلی‌فیل‌هایی که استفاده ندارند را به حداقل میزان خود برسانید

زمان کند بارگذاری سورس

اگر چه افزایش CSS یا اسکریپت باعث افزایش زمان انسداد می‌شود و به‌صورت مستقیم بر روی عملکرد وبسایت تأثیر می‌گذارد؛ اما زمانی که برای بارگذاری انواع مختلف سورس نیاز است نیز می‌تواند بر LCP تأثیرگذار باشد. به‌صورت کلی این المان‌ها بر روی LCP تأثیرگذار هستند.

• المان‌های img
• المان‌های image که داخل المان svg قرار دارند
• المان video
• یک المان با تصویر پس‌زمینه که همراه با تابع url اجرا شود
• المان Block-level که شامل تکست نود یا المان‌های متنی این‌لاین باشند

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

• تصاویر را بهینه‌سازی و فشرده کنید
• منابع مهم را پری-لود کنید
• فایل‌های متنی را فشرده کنید
• بر اساس شبکه از منابع مختلف استفاده نمایید (Adaptive Serving)
• منابع کش را با استفاده از Service Worker به کار ببرید

تصاویر را بهینه‌ و فشرده‌سازی کنید

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

• در وهله اول از تصاویر استفاده نکنید. اگر تصویر شما با محتوا ارتباط ندارد، آن را حذف کنید
• تصاویر را فشرده کنید
• تصاویر را به فرمت‌های جدیدتر همانند Webp,JPEG2000 یا JPEG XR تبدیل کنید
• از تصاویر ریسپانسیو  استفاده کنید
• از یک image CDN استفاده نمایید

منابع ضروری و مهم را پری- لود کنید

در بسیاری از موارد، منابعی استفاده شده در یک CSS یا اسکریپت، پس از زمانی که شما انتظار دارید فچ  خواهند شد.  در این باره می‌توان یک فونت را مثال زد که در بسیاری از فایل‌های CSS شما قرار دارد.

اگر می‌دانید که استفاده از این منبع باید در اولویت قرار بگیرد، از link rel="preload" استفاده کنید تا زودتر فچ شود. بسیاری از منابع را شما می‌توانید پری – لود کنید؛ اما پیش از آن باید به منابع ضروری که نیاز به پری – لود دارند، توجه داشته باشید. به‌عنوان مثال فونت‌ها، تصاویری که در بخش بالایی سایت قرار دارند، ویدئو‌‌ها و همچنین پچ‌های ضروری CSS یا جاوا اسکریپت جزو منابعی هستند که نیاز به پری – لود خواهند داشت.

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

link
  rel="preload"
  as="image"
  href="wolf.jpg"
  imagesrcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w"
  imagesizes="50vw"

فایل‌های متنی را فشرده کنید

الگوریتم‌های مختلف فشرده‌سازی همانند Gzip و Brotli می‌توانند به طور چشم‌گیری اندازه فایل‌های متنی را کاهش دهند. به این ترتیب به‌راحتی و باسرعت مناسب بین سرور و مرورگر تبادل پیدا می‌کنند. Gzip و Brotli روش‌هایی بسیار موثر هستند که اکثر مرورگرها از آن‌ها پشتیبانی می‌کنند و نتایج بسیار مطلوبی را ارئه می‌دهند.
فشرده‌سازی سورس‌ها به شما کمک می‌کند تا اندازه آن‌ها کاهش پیدا کند و در نتیجه زمان بارگذاری کمتر شود که در نهایت به بهبود LCP ختم خواهد شد.

1. پیش از شروع بررسی کنید که آیا سرور شما به‌صورت خودکار عملیات فشرده‌سازی را انجام می‌دهد یا نه. اکثر پلت‌فرم‌های هاست، CDNها و همچنین سرورهای پراکسی معکوس، به‌صورت پیش‌فرض منابع خود را فشرده می‌کنند تا پیکربندی آن‌ها ساده‌تر باشد.
2. اگر برای فشرده‌سازی فایل‌های خود باید تنظیمات سرور خود را تغییر دهید، به جای Gzip از Brotli استفاده کنید. Brotli فشرده‌سازی بهتری را ارائه می‌دهد.
3. پس از انتخاب الگوریتم، باید فشرده‌سازی را آغاز کنید. بهتر است فشرده‌سازی را هنگام پروسه ساخت انجام دهید. به این ترتیب لازم نیست همزمان با اجرای کد و درخواست مرورگر، عملیات فشرده‌سازی را انجام کنید. با این کار به سرور فشار نمی‌آید و هنگام درخواست با تأخیر مواجه نمی‌شوید. این مسئله مخصوص زمانی که قصد فشرده‌سازی فایل‌های حجیم را دارید به‌خوبی احساس می‌شود.

Adaptive serving

وقتی منابعی که محتوای اصلی پیج را می‌سازند را لود می‌کنید، بهتر است به‌صورت مشروط، منابع مختلف را بر اساس دستگاه یا شبکه کاربر فچ کنیم. این کار را می‌توانیم با کمکAPI های Network Information، Device Memory و HardawreConcurrency انجام دهیم.
اگر Assets  بزرگی دارید که در هنگام رندر ابتدایی ضروری هستند، باید بر اساس ارتباط و نوع دستگاه کاربر، از انواع مختلف آن در یک منبع استفاده کنید. به‌عنوان مثال زمانی که کانکشن کاربر شما ضعیف‌تر از 4G باشد، به جای فیلم، تصاویر ثابت به نمایش در بیاورید.

if (navigator.connection && navigator.connection.effectiveType) {
  if (navigator.connection.effectiveType === '4g') {
    // Load video
  } else {
    // Load image
  }
}

در ادامه شما را با برخی از کد‌های مفیدی که می‌توانید استفاده کنید آشنا خواهیم کرد:

• navigator.connection.effectiveType: برای استفاده موثر از نوع کانکشن کاربر؛
• navigator.connection.saveData: فعال‌سازی/ غیرفعال‌سازی Data-Saver؛
• navigator.hardwareConcurrency: شمارنده تعداد هسته CPU؛
• navigator.deviceMemory: تشخیص حافظه دستگاه.

است‌های کش با استفاده از Server Worker

Server Worker ها کاربردهای بسیار مفیدی دارند. همان طور که قبلآ اشاره کردیم، آن‌ها می‌توانند پاسخ‌های HTML کوچک‌تری را ارائه دهند. همچنین از Server Worker ها می‌توان برای کش کردن هر نوع منبع استاتیک استفاده کنید. این منابع را می‌توان در شرایط ریکوئست‌‌های تکراری، به مرورگر ارائه نمود.
پری – کش کردن منابع ضروری با استفاده ازServer Worker می‌تواند بار وبسایت را به‌مراتب کاهش دهد. مخصوصاً زمانی که کاربر از یک کانکشن ضعیف برای بارگذاری وبسایت استفاده می‌کنند یا حتی زمانی که به‌صورت کامل آفلاین است. لایبراری‌های همانند WorkBoxv می‌توانند پری – کش کردن است‌ها را ساده‌تر کنند. استفاده از این لایبراری‌ها به‌مراتب ساده‌تر از ایجاد دستی Server Worker ها هستند.

رندر از سمت کاربر 

بسیاری از وبسایت‌ها از جاوا اسکریپت client-side برای رندر مستقیم صفحات در مرورگر استفاده می‌کنند. فریم‌ورک‌ها و لایبراری‌های مختلفی همانند React، Angular و همچنین Vue ساخت SPA  ‌را ساده‌تر می‌کند. این SPA ها می‌توانند به‌خوبی وجوه مختلف یک صفحه وب را بر اساس کاربر نهایی و نه سرور مدیریت کنند.  
زمانی که اکثر بخش‌های وبسایت شما از طرف مشتری رندر شود و حجم باندل جاوا اسکریپت بالا باشد، باید بسیار مراقب تأثیر آن بر LCP وبسایت خود باشید. اگر از روش‌های بهینه‌سازی استفاده نکنید، کاربر پیش از استفاده و ارتباط با وبسایت شما، باید منتظر بماند تا تمامی جاوا اسکریپت‌های ضروری دانلود و اجر شوند.
برای آنکه یک سایت رندر شده از سمت کاربر داشته باشید، باید حتماً بهینه‌سازی‌های زیر را در نظر بگیرید:

• جاوا اسکریپت‌های ضروری خود را به حداقل برسانید
• از رندر Server-side استفاده کنید
• از پری – رندرینگ استفاده کنید

جاوا اسکریپت‌های ضروری را به حداقل برسانید

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

• جاوا اسکریپت را تا حد امکان کاهش دهید
• جاوا اسکریپت‌هایی که استفاده نمی‌شوند را به تأخیر بیاندازید
• polyfills که استفاده نمی‌شوند را به حداقل برسانید

از رندر Server – sider استفاده کنید

وبسایت‌هایی که بیشتر رندر آن‌ها از سمت کاربر است باید پیش از هر چیز دیگر تمرکز کامل بر کاهش مقدار جاوا اسکریپت داشته باشند. شما همیشه باید بخشی از رندر وبسایت خود را در سمت سرور قرار دهید تا LCP شما نیز بهبود پیدا کند.
بر اساس این استراتژی از سرور برای رندر اپلیکیشن در میان HTLM استفاده می‌شود. در این حالت کاربران تمام جاوا اسکریپت‌ها را hydrates می‌کنند و داده‌ها باید به‌سمت همان محتوای DOM هدایت شوند. به این صورت محتوای اصلی صفحه وبسایت به جای اینکه فقط از سمت کاربر رندر شود، ابتدا از سمت سرور رند خواهد شد و در نتیجه باعث بهبود LCP می‌شود. این روش شاید مفید به نظر برسد؛ اما چند ایراد کلی نیز دارد:

• نگه داشتن همان اپلیکیشن جاوا اسکریپت رندر شده بر روی سرور و مشتری باعث افزایش پیچیدگی محاسبات می‌شود
• اجرای جاوا اسکریپت برای رندر یک فایل HTML بر روی سرور باعث افزایش زمان پاسخ سرور یا همان TTFB در مقایسه با زمانی که فقط صفحات استاتیک از سرور ارائه می‌شود خواهد شد
• از نظر ظاهری به نظر می‌رسد که یک صفحه Server – rendered  می‌تواند قابل تعامل باشد؛ اما تا زمانی که تمام جاوا اسکریپت‌های Client – Side اجرا نشوند، هیچ پاسخی به کاربر نمی‌دهد. به‌صورت کلی می‌توان گفت که این مسئله باعث افزایش TTI خواهد شد

از پری – رندرینگ استفاده کنید

پری – رندرینگ در مقایسه با رندرینگ Server – side یک روش ساده‌تر است. این روش می‌تواند باعث بهبودی LCP وبسایت شما شود. از یک مرورگر بی‌سر که یک مرورگر بدون رابط کاربری است، می‌توانید برای ساخت فایل HTML استاتیک برای هر روت در طول Build Time  استفاده کنید. از این فایل‌ها می‌توان در کنار باندل‌های جاوا اسکریپتی که برای وبسایت نیاز است استفاده کرد.
جالب است بدانید پری – رندرینگ نیز تأثیر منفی بر TTI خواهد گذاشت. با وجود این، تأثیر منفی آن به اندازه تأثیر منفی رندرینگ Server – side  نخواهد بود. رندرینگ Server- side هر پیج را بعد از زمانی که درخواست شد به‌صورت دینامیک رندر می‌کند. به همین خاطر تأثیری به‌مراتب مخرب‌تر بر TTI خواهد گذاشت.

برای دریافت خدمات سئو و بهینه سازی وبسایت، از آژانس دیجیتال مارکتینگ منتوریکس راهنمایی بخواهید! 

ابزارهای مخصوص توسعه‌دهندگان

• Lighthouse 6.0 که از اندازه‌گیری LCP در شرایط آزمایشگاهی پشتیبانی می‌کند؛
• بخش Timing از پنل Performance در Chrome DevTools که شامل مارکر LCP می‌شود. این بخش زمانی که شما بر روی Node Field مربوطه قرار بگیرید، به شما نشان می‌دهد که کدام LCP با آن Node  در ارتباط است. 
• Chrome User Experience Report اطلاعات کاربران واقعی را از اورجین‌های مختلف را در اختیار توسعه‌دهنده قرار می‌دهد.

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

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

Core Web Vitals