نحوه بهبود Core Web Vitals برای سئو

 Core Web Vitals مجموعه ای از معیارها هستند که برای ارزیابی عملکرد وب سایت شما از نظر تجربه کاربری طراحی شده اند. آنها می توانند در رابطه با سرعت بارگذاری و تغییرات در چیدمان و همچنین پاسخگویی و دسترسی به سایت شما باشند. به خواندن ادامه دهید تا بدانید Core Web Vitals چیست، چرا برای سئو مهم است و چگونه می توانید آنها را بهبود ببخشید! ما در آیسو دیزاین علاوه بر پروژه های طراحی سایت در اصفهان و سئو در اصفهان خود برای شما خدمات بهبود سرعت و Core Web Vitals را انجام میدهیم.

Core Web Vitals چیست؟

اساساً Core Web Vitals مجموعه‌ای از معیارها هستند که برای اندازه‌گیری جنبه‌های مختلف تجربه کاربر از سایت شما طراحی شده‌اند. داده ها هم از دسکتاپ و هم از موبایل در یک دوره جمع آوری 28 روزه گرفته شده است.

چرا Core Web Vital ها مهم هستند؟

جدا از ارتباط موضوعی، اولویت Google تجربه کاربر است و خواهد بود. در این زمینه، Core Web Vitals مهم هستند زیرا مستقیماً به تعامل کاربر با صفحه وب شما مربوط می شوند. آنها بینشی در مورد نقاط درد بالقوه و دلایل معیارهایی مانند نرخ پرش بالاتر در صفحات خاص یا در کل سایت ارائه می دهند.

آیا نمرات عملکرد Core Web Vitals به طور مستقیم بر SEO تأثیر می گذارد؟

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

چگونه Core Web Vitals را تجزیه و تحلیل می کنید؟

نکات Core Web Vitals را می‌توانید در Google Search Console ، در بخش تجربه صفحه برای 3 معیار کلیدی پیدا کنید :

• LCP
• CLS
• FID

با این حال، برای اطلاعات دقیق‌تر از Google، می‌توانید به PageSpeed ​​Insights نیز دسترسی داشته باشید PSI. یک گزارش تجربه کاربر رایگان برای دسکتاپ و موبایل است که پیشنهاداتی را بر اساس یک صفحه جداگانه یا یک سایت مرتبط با میانگین ارائه می دهد. داده ها از 28 روز گذشته جمع آوری شده است. اگر داده های کافی وجود نداشته باشد، احتمالاً به دلیل عدم بازدید کاربر است. همچنین می تواند مربوط به جدید بودن صفحه باشد.

“ estimated savings پس انداز تخمینی” به چه معناست ؟

پس انداز تخمینی مربوط به تمام فرآیندهای مختلف مرتبط با بارگذاری صفحه است. بنابراین هنگامی که “صرفه جویی تخمینی 7 ثانیه” را مشاهده می کنید، این لزوماً به این معنی نیست که صفحه شما در بارگذاری اولیه 7+ ثانیه طول می کشد. در عوض، به تمام عناصر بارگذاری صفحه مربوط می شود که به فرآیندهای جداگانه آنها تقسیم می شود.

معیارهای Key Core Web Vitals و نحوه بهبود آنها

معیارهای اصلی Core Web Vitals به شرح زیر است: 

• LCP
• CLS
• FID
•  (FCP) 
•  (INP) 
•  (TTFB) 

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

LCP چیست؟

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

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

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

نحوه رفع مشکلات LCP

برای رفع مشکلات LCP ، ابتدا باید از منابعی مانند PageSpeedInsights استفاده کنید تا بفهمید کدام عنصر باعث ایجاد مشکل شده است. 

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

فرآیند LCP را می توان به مراحل زیر تقسیم کرد:

1. TTFB (زمان تا اولین بایت) : زمانی از زمانی که صفحه شروع به بارگیری می کند تا زمانی که مرورگر اولین بایت پاسخ سند HTML را دریافت می کند. 
2. تأخیر بارگیری منبع : مدت زمانی که طول می کشد تا یک منبع (تصویر، اسکریپت و غیره) بعد از درخواست صفحه بارگیری شود.
3. زمان بارگذاری منبع : زمانی که طول می کشد تا یک منبع به طور کامل بارگذاری شود.
4. تأخیر رندر عنصر: تأخیر بین زمانی که بارگیری منبع LCP تمام می شود و عنصر LCP (خود تصویر و غیره) به طور کامل رندر می شود.

بهینه سازی هر چهار بخش مهم است. این به این دلیل است که در برخی موارد، زمانی که در یک قسمت ذخیره می‌شود، در صورتی که آنها نیز بهینه نباشند، به قسمت‌های دیگر منتقل می‌شود.

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

1. از بین بردن تاخیر بار منبع

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

با این حال، زمانی که:

• عنصر LCP یک <img> است که به صورت پویا از طریق جاوا اسکریپت اضافه می شود.
• این عنصر با یک کتابخانه جاوا اسکریپت بارگذاری می شود که ویژگی های src یا srcset خود را پنهان می کند احتمالاً به عنوان data-src یا data-srcset این بدان معنی است که برای بارگیری در صورت نیاز تنظیم شده است و با استفاده از یک برنامه جاوا اسکریپت مدیریت می شود. 
• عنصر LCP به تصویری نیاز دارد که با استفاده از CSS به عنوان پس‌زمینه نمایش داده شود.

در این موارد، منبع باید از قبل بارگذاری شود، با اولویت واکشی بالا.

بهینه سازی اولویت منابع

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

با استفاده از ویژگی fetchpriority می توانید به مرورگر خود بگویید کدام منابع مهم ترین هستند. برای مثال، اگر عنصر LCP شما باشد، ایده خوبی است که fetchpriority=”high” را روی <img> تنظیم کنید.

اطمینان حاصل کنید که منبع LCP در همان مبدا میزبانی می شود

اگر در مبدا (وب سایت) دیگری میزبانی شود، این درخواست از مرورگر می‌خواهد تا قبل از شروع بارگیری منبع، به آن مبدا متصل شود.

2. تاخیر رندر عنصر را حذف کنید

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

• بارگیری منبع به پایان رسیده است، اما عنصر LCP منتظر است تا برخی از اسکریپت ها یا شیوه نامه های همگام در <head> بارگیری شوند (منبع آماده است، اما منتظر است تا اسکریپت ها یا سبک ها بارگذاری شوند تا بارگیری شوند).
• رندر (نمایش) کل صفحه به دلیل اسکریپت ها یا شیوه نامه های همزمان در <head> که هنوز در حال بارگیری هستند مسدود شده است.
• این عنصر توسط کد دیگری پنهان می شود.
• کارهای طولانی، رشته اصلی (بخش اصلی صفحه وب) را مسدود می کنند، و کار رندر باید تا پایان آنها صبر کند.

شیوه نامه های مسدود کننده رندر را کاهش دهید یا درون خطی کنید

برگه‌های سبک بارگیری شده از نشانه‌گذاری HTML، رندر تمام محتوایی را که به دنبال آنها می‌آید، مسدود می‌کند، که معمولاً مثبت است. با این حال، اگر شیوه نامه به قدری بزرگ باشد که بارگذاری آن بیشتر از منبع LCP طول بکشد، از رندر شدن آن جلوگیری می کند. 

برای رفع این مشکل می توانید: 

• شیوه نامه را در HTML قرار دهید (فقط در صورتی مناسب است که صفحه سبک شما کوچک باشد). این بدان معناست که به جای داشتن یک فایل جداگانه برای استایل صفحه شما، مستقیماً در کد صفحه قرار دارد. 
• اندازه شیوه نامه را کاهش دهید تا از منبع LCP کوچکتر باشد (ترجیحا).

برای کاهش اندازه صفحه سبک، می توانید:

• CSS استفاده نشده CSS) که استفاده نمی شود( و می تواند حذف یا به تعویق بیفتد را حذف کنید.
• CSS غیر بحرانی را به تعویق بیندازید (سبک شیت را به سبک های مورد نیاز برای بارگذاری اولیه صفحه و سبک هایی که می توانند با تنبلی بارگذاری شوند تقسیم کنید).
• کوچک کردن و فشرده سازی CSS – این به معنای کوچکتر کردن کد سبک با حذف کاراکترهای غیر ضروری است.

جاوا اسکریپت مسدود کردن رندر را به تعویق بیندازید یا درون خطی کنید

به طور کلی، لازم نیست اسکریپت هایی بدون ویژگی های async یا defer در بخش <head> صفحات خود داشته باشید. این احتمالاً بر عملکرد صفحه تأثیر منفی می گذارد.

در عوض، محتویات اسکریپت را مستقیماً در HTML قرار دهید (فقط اگر اسکریپت های بسیار کوچک باشند).

از رندر سمت سرور استفاده کنید

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

• منابع تصویری شما از منبع HTML قابل کشف خواهند بود (با نگاه کردن به کد صفحه، دیدن مکان تصاویر در صفحه آسان تر است).
• محتوای صفحه نیازی به درخواست های جاوا اسکریپت اضافی نخواهد داشت (صفحه وب می تواند به سرعت بدون نیاز به منتظر ماندن برای کد اضافی نمایش داده شود).

3– زمان بارگذاری منابع را کاهش دهید

برای کاهش زمان صرف شده برای انتقال بایت های منبع به دستگاه کاربر، می توانید:

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

4– زمان را به بایت اول کاهش دهید

اساساً، نتیجه ایده آل این است که کد اولیه را در سریع ترین زمان ممکن تحویل دهید. TTFB کند را می توان به عواملی مانند:

• قبل از اینکه به URL نهایی برسید چندین تغییر مسیر. 
• هنگامی که محتوای کش شده را نمی توان از یک سرور لبه CDN استفاده کرد، به این معنی که درخواست ها باید به سرور اصلی هدایت شوند. این بدان معنی است که کپی محتوا در نزدیکی شما ذخیره نمی شود و در عوض باید به سرور منبع اصلی برگردد.

FID (تاخیر ورودی اول) چیست؟

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

یک امتیاز ایده آل FID 100 میلی ثانیه است. هر چیزی بین 100-300ms نیاز به بهبود دارد. هر چیزی بالاتر از 300 میلی ثانیه ضعیف در نظر گرفته می شود. 

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

نحوه رفع مشکلات FID

برای کمک به کاهش تاخیر زمانی که کاربر با سایت تعامل دارد، می توانید:

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

INP (تعامل با رنگ بعدی) چیست؟

در اصل، INP معیاری است که جایگزین FID (تأخیر ورودی اول) در بخش Search Console Core Web Vitals خواهد شد. این تغییر در مارس 2024 اعمال شد. 

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

INP کمتر از 200 میلی‌ثانیه نشان می‌دهد که صفحه شما واکنش‌گرا است و 200 تا 500 میلی‌ثانیه نشان‌دهنده نیاز به بهبود است.

نحوه رفع مشکلات INP

INP از سه مرحله تشکیل شده است که عبارتند از:

1. تاخیر ورودی : زمانی که کاربر با صفحه ارتباط برقرار می کند شروع می شود و زمانی پایان می یابد که اقدامات مربوط به رویداد متوقف شود.
2. زمان پردازش : چه مدت طول می کشد تا وظایف مرتبط با دستور به پایان برسد.
3. تأخیر ارائه : مدت زمانی که مرورگر طول می کشد تا نتیجه بصری تعامل را نشان دهد.

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

هنگامی که از ابزاری مانند PageSpeed ​​Insights برای تعیین کنش(های) کند در صفحه استفاده کردید، می توانید راه حل هایی مانند :

شناسایی و به حداقل رساندن تاخیر ورودی

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

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

CLS (Cumulative Layout Shift) چیست؟

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

به طور کلی، CLS در نتیجه بارگیری منابع به صورت ناهمزمان اتفاق می‌افتد (چند کار به طور همزمان انجام می‌شوند، به جای انتظار در صف برای اتمام هر کدام). 

همچنین می‌تواند در نتیجه افزودن پویا عناصر DOM به صفحه بالای محتوای موجود اتفاق بیفتد (متن، تصاویر و غیره در بالای آنچه قبلاً وجود داشت، قرار دادن یک لایه جدید روی لایه موجود).

شایع ترین علل عبارتند از:

• تصاویر بدون ابعاد 
• فونت های وب 
• تبلیغات، جاسازی ها و آیفریم های بدون ابعاد 

نمره CLS خوب 0.1 یا کمتر است. هر چیزی بین 0.1 و 0.25 به عنوان نیاز به بهبود طبقه بندی می شود و هر چیزی بالاتر از 0.25 به عنوان ضعیف طبقه بندی می شود.

نحوه رفع مشکلات CLS

هنگامی که منبع تغییرات طرح بندی را شناسایی کردید، باید:

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

FCP (نخستین رنگ محتوایی) چیست؟

First Contentful Paint  مربوط به زمانی است که صفحه شروع به بارگذاری می کند و سپس هر بخشی از محتوای صفحه (تصاویر، متن و غیره) روی صفحه ظاهر می شود. 

هر چیزی کمتر از 1.8 به عنوان یک امتیاز FCP خوب در نظر گرفته می شود، با 1.8-3 ثانیه نیاز به بهبود دارد، و هر چیزی بالاتر از 3 ثانیه ضعیف است.

نحوه رفع مشکلات FCP

برای رفع مشکلات FCP، می توانید موارد زیر را امتحان کنید: 

• منابع مسدودکننده رندر را حذف کنید
• CSS را کوچک کنید
• تعداد درخواست‌ها را کم نگه دارید و اندازه‌های انتقال را کوچک نگه دارید – تعداد درخواست‌های جداگانه‌ای که سایت شما هنگام بارگذاری محتوا می‌کند را کاهش دهید. این بدان معناست که نیازی به دریافت منابع زیادی از سرور نیست
• اطمینان حاصل کنید که متن در حین بارگذاری وب فونت قابل مشاهده است ، زمانی که از فونت های سفارشی استفاده می کنید، متن باید بلافاصله برای کاربران قابل مشاهده و خواندن باشد حتی زمانی که وب فونت در حال بارگیری است. این به جلوگیری از تاخیر کمک می کند
• عمق درخواست بحرانی را به حداقل برسانید – تعداد مراحل مورد نیاز برای بارگیری ضروری ترین عناصر صفحه قبل از نمایش آن به کاربر را کاهش دهید.
• CSS استفاده نشده را حذف کنید.
• جاوا اسکریپت استفاده نشده را حذف کنید.
• پیش اتصال به مبداهای مورد نیاز – اتصال زودهنگام به سرورها یا منابعی که صفحه وب شما منابع خود را از آنها بارگیری می کند.
• کاهش زمان پاسخ سرور (TTFB)
• از تغییر مسیرهای متعدد اجتناب کنید.
• از بارهای سنگین شبکه خودداری کنید.
• درخواست های کلیدی را از قبل بارگیری کنید.
• از اندازه DOM بیش از حد خودداری کنید.

شاخص سرعت چیست؟

اساساً، Speed ​​Index سرعت نمایش بصری محتوا را در حین بارگذاری صفحه اندازه می‌گیرد. 

بین 0 تا 3.4 ثانیه به عنوان سریع طبقه بندی می شود که 3.4-5.8 ثانیه متوسط ​​است و هر چیزی بیش از 5.8 به عنوان کند طبقه بندی می شود.

نحوه رفع مشکلات شاخص سرعت

برای اصلاح شاخص سرعت، باید به مسائل زیر توجه کنید :

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

زمان مسدود کردن کل چیست؟

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

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

سایت شما باید در مجموع زمان مسدود شدن کمتر از 200 میلی‌ثانیه بر روی موبایل متوسط ​​داشته باشد.

نحوه رفع کل زمان مسدود شدن

شما می توانید زمان مسدودسازی کل را با بررسی مسائلی مانند:

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

زمان تعامل چیست؟

TTI مدت زمانی است که طول می کشد تا صفحه شما کاملاً تعاملی شود. این زمانی است که:

• صفحه محتوای مفیدی را نشان می دهد اندازه گیری شده با First Contentful Paint
• کنترل کننده رویداد برای اکثر عناصر قابل مشاهده ثبت شده است .
• صفحه به تعاملات کاربر در عرض 50 میلی ثانیه پاسخ می دهد .

امتیاز بین 0 تا 3.8 سریع در نظر گرفته می شود که 3.9-7.3 متوسط ​​است و هر چیزی بیش از 7.3 کند است.

چگونه Time to Interactive را رفع کنیم

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

تفاوت بین TTI و FID چیست؟

در حالی که TTI مربوط به مدت زمانی است که صفحه شما به طور کامل با تمام ورودی‌ها تعاملی می‌شود، FID مدت زمانی را که طول می‌کشد تا صفحه به اولین تعامل کاربر پاسخ دهد، توصیف می‌کند.

نکاتی برای Shopify Core Web Vitals

• استفاده از تم ها و فونت های سنگین باعث می شود که مرورگر کدهای پیچیده تری را در هنگام بارگذاری سایت مدیریت کند.
• بسیاری از تم های Shopify همراه با چرخ فلک و لغزنده هستند. با این حال، اینها می توانند مشکلاتی را در رابطه با پاسخگویی تلفن همراه ایجاد کنند و تصاویر متعدد می توانند زمان بارگذاری را افزایش دهند. علاوه بر این، می‌تواند نرخ کلیک شما را کاهش دهد، زیرا کاربران مجبور هستند برای رسیدن به آنچه می‌خواهند، کلیک‌های اضافی انجام دهند. در عوض باید یک طرح بندی تصویر قهرمان ثابت را برای افزایش تبدیل و سرعت بخشیدن به صفحه اصلی خود در نظر بگیرید.
• نصب برنامه‌ها یا اسکریپت‌های اضافی در Shopify، مانند برنامه‌های ردیابی، می‌تواند به تاخیر کمک کند، زیرا سایت باید کد شخص ثالث اضافی را بارگیری کند. در عوض باید از Google Tag Manager برای متمرکز کردن تلاش های ردیابی خود استفاده کنید. 
• از استفاده از GIF اجتناب کنید و در عوض تصاویر ثابت بهینه شده را انتخاب کنید. 
• فشرده سازی تصویر برای اطمینان از اینکه مرورگرها می توانند محتوای صفحه شما را سریعتر بارگذاری کنند، کلیدی است. همچنین باید مطمئن شوید که اندازه تصاویر به صراحت است تا از تغییر طرح بندی جلوگیری شود.

بهترین سازنده وب سایت برای Core Web Vitals چیست؟

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

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