سلام! من نگینم.
میدونم، شنیدن اسم «سرعت سایت» و «Core Web Vitals» حال خیلیا رو بد میکنه. انگار داریم وارد یه زیرزمین تاریک و ترسناک میشیم که پر از کدهای پیچیده است.
راستش، این بخش از کار، یعنی همون سئو تکنیکال (Technical SEO)، دقیقاً همونجاییه که خیلیا بیخیالش میشن. اما بذار یه چیزی رو بهت بگم… این اصلاً ترسناک نیست!
این دقیقاً مثل مرتب کردن موتور ماشینه. اگه میخوای ماشینت (سایتت) سریع و روان حرکت کنه و حال کاربرت رو خوب کنه، باید بدونی تو موتور چه خبره. تو این گپ دوستانه، قراره با هم آچار به دست بشیم و این غول Core Web Vitals رو انقدر ساده کالبدشکافی کنیم که خودت هم باورت نشه.
قبل از اینکه شیرجه بزنیم تو عمق ماجرا، بیا یه تقلب سریع و کاربردی از این سه تا معیار اصلی داشته باشیم که کل داستان دستت بیاد:
| معیار (Metric) | چی رو اندازه میگیره؟ (به زبان ساده) | نمره “خوب” (Good) |
| LCP (Largest Contentful Paint) | سرعت لود (چقدر طول میکشه اصل مطلب بیاد؟) | زیر ۲.۵ ثانیه |
| INP (Interaction to Next Paint) | سرعت تعامل (چقدر طول میکشه به کلیک جواب بده؟) | زیر ۲۰۰ میلیثانیه |
| CLS (Cumulative Layout Shift) | ثبات ظاهری (صفحه موقع لود میپره یا نه؟) | زیر 0.1 |
چرا سرعت سایت دیگر یک گزینه نیست، یک ضرورت است؟
بذار راحت بگم: دیگه دورهای که میگفتیم «حالا محتوای خوب بذارم، سرعت بعداً» تموم شده. امروز، سرعت بخش اصلی همون «محتوای خوب» به حساب میاد. اگه کاربر نتونه محتوای عالی تو رو ببینه، انگار که اصلاً وجود نداره. این موضوع روی همهچیز، از سئو گرفته تا اعتماد کاربرت، تأثیر مستقیم میذاره.
تأثیر مستقیم سرعت بر رتبهبندی گوگل (SEO) و تجربه کاربری (UX)
بیا یه قرارداد نانوشته رو با هم مرور کنیم: گوگل دقیقاً همون چیزی رو میخواد که کاربر میخواد.
کاربر چی میخواد؟ سرعت. جواب سریع. رسیدن به هدفش بدون معطلی.
گوگل هم همینو میخواد. به همین دلیل بود که «تجربه کاربری» یا همون UX رو بهعنوان یکی از فاکتورهای اصلی رتبهبندی معرفی کرد و بعدش هم با معرفی Core Web Vitals (CWV)، رسماً به همهی ما اعلام کرد: «سایتهای سریعتر، در اولویت هستن.»
وقتی سایت تو کُنده، تو داری مستقیماً به گوگل سیگنال میدی که تجربه کاربری خوبی ارائه نمیدی. گوگل هم مثل یه راهنمای تور خوب، مسافرهاش (کاربرها) رو به هتلی که پذیرش کُند و اعصابخردکنی داره، نمیفرسته. به همین سادگی!
آمار تکاندهنده: ارتباط سرعت سایت با نرخ پرش (Bounce Rate) و نرخ تبدیل (Conversion Rate)
بریم سراغ قسمت ترسناک ماجرا: اعداد!
گاهی ما به عنوان صاحب کسبوکار، توی دنیای خودمون غرق میشیم و یادمون میره که کاربر «صبور» نیست. اصلاً چرا باید باشه؟
-
نرخ پرش (Bounce Rate): آمارها نشون میدن که اگه بارگذاری صفحهات به جای ۱ ثانیه، ۳ ثانیه طول بکشه، احتمال پریدن کاربر (همون Bounce Rate) تا ۳۲٪ افزایش پیدا میکنه. اگه ۵ ثانیه طول بکشه؟ این عدد به ۹۰٪ میرسه! یعنی از هر ۱۰ نفر، ۹ نفر صفحهات رو ندیده میبندن و احتمالاً سراغ یه نتیجه دیگه میرن.
-
نرخ تبدیل (Conversion Rate): این فاجعه است. هر ثانیه تأخیر در لود، میتونه نرخ تبدیل (فروش، ثبتنام، هرچی!) رو تا ۷٪ کاهش بده. حالا خودت حساب کن اگه یه سایت فروشگاهی داری و روزی ۱ میلیون تومن میفروشی، فقط ۱ ثانیه تأخیر در سال چقدر برات هزینه داره!
این اعداد فقط آمار خشکوخالی نیستن؛ اینها صدای کاربرهایی هستن که از ما ناامید شدن.
سرعت و E-E-A-T: چگونه سرعت پایین، تخصص (Expertise) و اعتماد (Trust) شما را زیر سوال میبرد؟
این بخش، دقیقاً تخصص منه و میخوام خیلی روش تأکید کنم. E-E-A-T (تجربه، تخصص، اعتبار، اعتماد) همهچیزِ یه محتوای خوبه. حالا سرعت کجای این پازله؟
۱. ضربه به تخصص (Expertise):
تصور کن من ادعا کنم بهترین متخصص سئو هستم، اما سایتم ۱۰ ثانیه طول بکشه تا باز بشه. تو چی فکر میکنی؟ احتمالاً میگی: «این اگه متخصص بود، اول یه فکری به حال سایت خودش میکرد!» سرعت پایین، نشون میده که کارت رو «سهلانگارانه» یا «عجولانه» انجام دادی. این دقیقاً برعکس چیزیه که «تخصص» باید نشون بده.
۲. نابودی اعتماد (Trust):
سرعت فقط فنی نیست؛ حسیه. سایتی که کُنده، حس «ناامن بودن» یا «بیکیفیت بودن» رو منتقل میکنه. چطور میتونی به سایتی که لود شدنش انقدر طول میکشه، اعتماد کنی و اطلاعات کارت اعتباریت رو وارد کنی؟ کاربر احساس میکنه به وقتش احترام نذاشتی.
۳. زیر سوال بردن تجربه (Experience):
وقتی من از تجربه شخصیام در مورد یه محصول مینویسم، میخوام تو اون حس رو سریع دریافت کنی. اگه صفحه کُند باشه، اون حس خوب، اون «تجربه»ی واقعی که میخوام منتقل کنم، در نطفه خفه میشه.
در نهایت، سایتی که کُنده، سایتی نیست که کسی بخواد بوکمارکش کنه یا به دوستش معرفی کنه. سرعت، اولین قدم برای جلب اعتماد و اثبات تخصص توئه.
کالبدشکافی Core Web Vitals: سه معیار حیاتی گوگل برای سنجش تجربه کاربری
ببین، گوگل برای اینکه بفهمه سایت تو چقدر «حالِ کاربر رو خوب میکنه»، سه تا سوال اصلی از خودش میپرسه:
۱. چقدر طول میکشه تا کاربر «اصل مطلب» رو ببینه؟ (سرعت لود)
۲. چقدر طول میکشه تا سایت به «دستور» اول کاربر جواب بده؟ (سرعت تعامل)
۳. آیا صفحه موقع لود شدن «لق میزنه» و بالا پایین میپره؟ (ثبات ظاهری)
جواب این سه تا سوال، همون سه معیار اصلی Core Web Vitals هستن.
LCP (Largest Contentful Paint): سنجش سرعت بارگذاری (Loading)
LCP به زبون ساده: چقدر طول میکشه تا بزرگترین و مهمترین چیزی که تو صفحه هست (معمولاً یه عکس بزرگ، یه بنر اصلی یا بلاک اصلی متن) برای کاربر نمایش داده بشه؟
تجربهاش کردی: فرض کن وارد یه صفحه محصول شدی. تو منتظر چی هستی؟ عکس اصلی اون محصول. LCP دقیقاً همینو اندازه میگیره. تا وقتی اون عکس اصلیه لود نشده، صفحه از نظر تو «هنوز لود نشده»، حتی اگه دکمه «خرید» پایین صفحه اومده باشه.
گوگل میخواد مطمئن بشه که کاربرت خیلی سریع به اون «اصل مطلب» میرسه و به صفحهی سفید زل نمیزنه.
FID (First Input Delay) و جایگزین جدید آن INP (Interaction to Next Paint): سنجش تعاملپذیری (Interactivity)
اینجا جاییه که من همیشه میگم «سایت زنده است یا نه؟»
-
FID (که دیگه داره بازنشسته میشه): میدونی اون حس بد رو که وارد یه سایت میشی، روی یه دکمه کلیک میکنی و هیچ اتفاقی نمیافته؟ انگار دکمههه قفل کرده. این تأخیر بین «کلیک تو» و «جواب دادن سایت»، همون FID بود.
-
INP (جایگزین خیلی باهوشتر): گوگل فهمید که فقط «اولین» کلیک مهم نیست. شاید اولین کلیک سریع باشه، اما وقتی میخوای «محصول رو به سبد خرید اضافه کنی» یا «منوی دستهبندی» رو باز کنی، سایت هنگ میکنه. INP اومده که تمام تعاملهای کاربر در طول حضورش تو صفحه رو اندازه بگیره و مطمئن بشه سایت همیشه پاسخگو و سریعه.
تجربهاش کردی: این دقیقاً حس فشار دادن دکمه آسانسوریه که میدونی خرابه. یه بار میزنی، کار نمیکنه. دوباره میزنی. اعصابت خرد میشه. INP میخواد مطمئن بشه سایت تو حس اون آسانسور خراب رو به کاربر نمیده.
CLS (Cumulative Layout Shift): سنجش ثبات بصری (Visual Stability)
و اما میرسیم به منفورترین تجربهی کاربری از نظر من!
CLS به زبون ساده: آیا اجزای صفحه تو، موقع لود شدن، یهو بالا پایین میپرن و جابهجا میشن؟
تجربهاش کردی (و قطعاً حرص خوردی): این همون سناریوی کابوسواره که میخوای روی دکمهی «تأیید» کلیک کنی، اما درست لحظهی آخر، یه بنر تبلیغاتی که دیر لود شده، بالای صفحه باز میشه، کل صفحه رو میده پایین و تو به جاش روی دکمهی «انصراف» کلیک میکنی!
این اتفاق فاجعه است. نه تنها اعصاب کاربر رو خرد میکنه، بلکه «اعتماد» (Trust) رو هم نابود میکنه. سایتی که جلو چشمت رژه میره و نمیتونی روش یه کلیک درست انجام بدی، سایت قابل اعتمادی نیست. CLS پایین (یعنی نزدیک به صفر) نشون میده که سایت تو باثباته و به کاربر احترام میذاره.
جعبه ابزار سنجش سرعت: چگونه Core Web Vitals را اندازهگیری کنیم؟
قبل از اینکه بپریم سراغ ابزارها، باید یه مفهوم حیاتی رو با هم صاف کنیم. اگه اینو ندونی، هر گزارشی که ببینی میتونه گیجکننده باشه.
تفاوت حیاتی دادههای میدانی (Field Data) و دادههای آزمایشگاهی (Lab Data)
بذار با یه مثال برات روشن کنم:
-
داده آزمایشگاهی (Lab Data): فرض کن میخوای سرعت یه ماشین رو تست کنی. میبریش تو یه پیست تست استاندارد، با یه راننده حرفهای، هوای عالی و بنزین سوپر. همهچیز کنترلشده است. ابزارهایی مثل Lighthouse اینجوری کار میکنن.
-
داده میدانی (Field Data): حالا همون ماشین رو بردار بیار تو ترافیک سنگین ساعت ۶ عصر تهران، با یه گوشی میانرده که داره به زور به اینترنت 4G وصل میشه و دست یه کاربر واقعیه. این میشه داده میدانی.
کدوم مهمه؟ راستش، هر دو!
-
داده آزمایشگاهی برای عیبیابی و دیباگ کردن عالیه. بهت میگه تو شرایط ایدهآل مشکل کجاست.
-
اما داده میدانی (که از طریق کاربرهای واقعی تو جمع میشه) همون چیزیه که گوگل واقعاً برای رتبهبندی بهش نگاه میکنه. این «حقیقت» تجربه کاربر توئه.
آموزش گام به گام کار با Google PageSpeed Insights (PSI)
این معروفترین و دمدستیترین ابزاره. کار باهاش هم مثل آب خوردنه:
۱. وارد سایت PageSpeed Insights شو.
۲. آدرس صفحهای که میخوای تست کنی رو وارد کن و «Analyze» رو بزن.
۳. چند ثانیه صبر کن.
حالا چی میبینی؟ اینجاست که خیلیا اشتباه میکنن.
-
گزارش بالایی (Field Data): اولین چیزی که PSI بهت نشون میده (اگه سایتت ترافیک کافی داشته باشه) گزارش «Discover what your real users are experiencing» هست. این همون داده میدانیه! این گزارش نمره کلی نداره، فقط وضعیت سه معیار LCP, INP, CLS رو در ۲۸ روز گذشته نشون میده. این مهمترین بخش برای گوگله.
-
گزارش پایینی (Lab Data): بعدش میرسی به «Diagnose performance issues» که یه نمره از ۱۰۰ بهت میده. این همون داده آزمایشگاهیه.
نصیحت من: به اون نمره ۰ تا ۱۰۰ پایینی وسواس نشون نده! اون فقط یه راهنماست. تمرکزت روی قرمز یا زرد بودن سه معیار اصلی CWV هم در بخش Field (اگه داری) و هم در بخش Lab باشه. پایینتر هم کلی «پیشنهاد» (Opportunities) برای بهبود بهت میده.
نحوه خواندن گزارش Core Web Vitals در گوگل سرچ کنسول (Search Console)
این یکی ابزار تست نیست؛ «گزارشه». و راستش رو بخوای، برای من به عنوان استراتژیست، «نقشه گنج» محسوب میشه.
-
کجا پیداش کنی؟ توی منوی سرچ کنسول، زیر بخش «Experience» یه گزینه هست به اسم «Core Web Vitals».
-
چطور بخونیش؟ این گزارش فقط و فقط دادههای میدانی (Field Data) رو بهت میده. یعنی دقیقاً میگه کاربرهای واقعیت دارن چی میبینن.
سرچ کنسول نمیاد به یه صفحه نمره بده؛ میاد URL های سایتت رو به سه دسته تقسیم میکنه:
-
Good (خوب): URL هایی که هر سه معیار رو پاس کردن. (سبز)
-
Need improvement (نیاز به بهبود): URL هایی که حداقل یکی از معیارهاشون زرده.
-
Poor (ضعیف): URL هایی که حداقل یکی از معیارهاشون قرمزه.
بهترین ویژگیش اینه که وقتی روی گزارش «Poor» کلیک میکنی، بهت میگه مشکل دقیقاً چی بوده (مثلاً «LCP issue: longer than 2.5s») و کدوم گروه از صفحات (مثلاً ۵۰ تا از صفحات بلاگت) این مشکل رو دارن. این یعنی دقیقاً میدونی باید کجا رو تعمیر کنی.
تحلیل پیشرفته و فنی با Google Lighthouse و Chrome DevTools
اینجا دیگه میخوایم آچار فرانسه دستمون بگیریم و فنیتر بشیم.
-
Google Lighthouse: این همون موتوریه که PageSpeed Insights تو بخش Lab ازش استفاده میکنه. اما تو میتونی مستقیم توی مرورگر کروم خودت اجراش کنی.
-
چطوری؟ توی صفحهات کلیک راست کن، «Inspect» رو بزن و برو به تب «Lighthouse». بعد «Analyze page load» رو بزن.
-
-
Chrome DevTools (تب Performance): این دیگه آخرشه! وقتی Lighthouse میگه «فلان چیز لود رو طولانی کرده» و تو نمیدونی دقیقاً چیه، میای اینجا.
-
تجربه من: من وقتی میخوام «مچِ» اون فایل جاوااسکریپت یا اون عکسی که داره لود رو مختل میکنه بگیرم، میام توی تب «Performance» و یه رکورد میگیرم. بهم یه نمودار آبشاری (Waterfall) میده که فریم به فریم نشون میده چی، کِی، و در چند صدم ثانیه لود شده. این برای عیبیابی فنی عالیه.
-
معرفی ابزارهای جانبی معتبر (GTmetrix و WebPageTest)
گوگل تنها ابزار این شهر نیست! دو تا ابزار فوقالعاده دیگه هم هستن که من همیشه به عنوان «نظر دوم» ازشون استفاده میکنم:
-
GTmetrix: خیلیها عاشقشن چون قبلاً رابط کاربری سادهتری داشت. الان دیگه اونم از موتور Lighthouse گوگل استفاده میکنه. چیزی که من در مورد GTmetrix دوست دارم، نمودار آبشاری (Waterfall) خیلی تمیز و قابل فهمشه. خیلی قشنگ نشونت میده کدوم فایلها دارن جلوی لود بقیه رو میگیرن.
-
WebPageTest: این ابزار، پیرمرد باتجربه و حرفهای این بازاره. به شدت قدرتمنده. بهت اجازه میده تست رو از لوکیشنهای مختلف دنیا (مثلاً از آلمان) و با سرعتهای اینترنت مختلف (مثلاً 3G) شبیهسازی کنی. اگه کارت خیلی فنیه یا کاربر خارج از کشور داری، این ابزار حیاتیه.
راهنمای عملی بهینهسازی و بهبود نمرات Core Web Vitals
تکنیکهای کلیدی برای بهبود LCP (بهینهسازی تصاویر، Caching سرور، فشردهسازی)
یادتونه گفتیم LCP یعنی چقدر طول میکشه تا اون «اصل مطلب» (معمولاً بزرگترین عکس صفحه) لود بشه؟ خب، ۹۰ درصد مواقع، مشکل دقیقاً خودِ همون عکس گنده است!
- بهینهسازی تصاویر (این قاتل شماره یکه!):
من همیشه به بچههای تیم میگم: «چرا باید عکسی که قراره ۵۰۰ پیکسل نمایش داده بشه رو با عرض ۴۰۰۰ پیکسل آپلود کنید؟» این مثل اینه که بخوای یه لیوان آب رو با تانکر پر کنی!
-
راه حل ساده: قبل از آپلود، سایز عکسهات رو دقیقاً هماندازهی جایی کن که قراره نمایش داده بشه.
-
فرمت جادویی (تجربه من): تا جایی که میتونی از فرمت WebP استفاده کن. هم کیفیتش عالیه، هم حجمش فوقالعاده کمه.
-
- فشردهسازی (Gzip/Brotli):
این مثل اینه که قبل از فرستادن یه فایل بزرگ، اول زیپش کنی. مطمئن شو هاستت (سرورت) فشردهسازی Gzip یا (بهتر از اون) Brotli رو فعال کرده باشه. این کار حجم متنها، کدها و فایلها رو قبل از ارسال برای کاربر، درجا کم میکنه.
- Caching سرور (حافظه پنهان):
این دیگه معجزه میکنه. به جای اینکه سرور مجبور باشه برای هر بازدیدکننده، کل صفحه رو از اول تا آخر بسازه، یه نسخه آمادهشده و حاضر از صفحه رو نگه میداره و همونو به همه تحویل میده. انگار یه غذای آماده داشته باشی بهجای اینکه هر بار از اول شروع به پختن کنی. (پلاگینهای کش وردپرس مثل WP Rocket این کار رو عالی انجام میدن).
چالشبرانگیزترین بخش: بهینهسازی FID و INP (کاهش اجرای JavaScript، بهینهسازی Third-party)
آخ… رسیدیم به همونجایی که من بهش میگم «باتلاق جاوااسکریپت». راستش رو بخوای، LCP معمولاً راحتتر درست میشه. اما INP (و FID سابق) جاییه که بیشتر تیمهای فنی گیر میکنن.
مشکل اینه که مرورگر کاربر مثل یه کارگر تکنفره است (توی یه نخ اصلی). وقتی تو یه فایل جاوااسکریپت سنگین رو میدی دستش که اجرا کنه، اون کارگر مشغول میشه و دیگه به هیچچیز دیگهای (مثل کلیکهای کاربر) نمیتونه جواب بده. کاربر کلیک میکنه، اما کارگرمون سرش شلوغه!
- کاهش اجرای JavaScript:
ببین، واقعاً به همهی این کدهای خفن و انیمیشنها نیاز داری؟
-
تجربه من: ما همیشه اول میپرسیم: «کدوم اسکریپت حیاتی نیست؟» خیلی وقتها میبینیم یه اسکریپت مربوط به یه پاپآپ قدیمی یا یه افکت انیمیشنی که دیگه مهم نیست، داره کل سایت رو قفل میکنه.
-
راهحل فنیتر: از تیم فنیت بخواه کدهای جاوااسکریپت رو «Defer» یا «Delay» کنن. یعنی به مرورگر بگن: «اول صفحه رو کامل لود کن، به کلیکهای کاربر جواب بده، بعد که سرت خلوت شد برو سراغ اجرای این فایل جاوااسکریپت سنگینه.»
-
- بهینهسازی Third-party (کدهای شخص ثالث):
اینها کدهایی هستن که مال تو نیستن ولی روی سایتت داریشون. مثل چی؟ کد گوگل آنالیتیکس، پیکسل فیسبوک، ابزارهای چت آنلاین (مثل رایچت).
-
چالش: اینها مثل مهمونهایی هستن که نمیتونی کنترلشون کنی. گاهی سرورِ اون ابزار چت کُنده و کل سایت تو رو معطل خودش میکنه.
-
راه حل: تا جایی که میتونی اینها رو کم کن. واقعاً به سه تا ابزار آمارگیری همزمان نیاز داری؟ اگه بهشون نیاز داری، سعی کن لود شدنشون رو تا جای ممکن به تأخیر بندازی (Delay).
-
استراتژیهای مؤثر برای کاهش CLS (تعیین ابعاد دقیق تصاویر و تبلیغات)
خب، رسیدیم به آرامش بصری! این یکی برعکس INP، معمولاً راهحلهای خیلی ساده و مستقیمی داره. CLS همون پرشهای اعصابخردکن صفحه است.
دلیلش چیه؟ اینه که تو به مرورگر نگفتی جای هرچیزی دقیقاً کجاست. مثل اینه که مهمونها بیان و تو براشون صندلی نچیده باشی. هرکی از راه میرسه، بقیه رو هُل میده تا یه جا برای خودش باز کنه و همهچی به هم میریزه.
- تعیین ابعاد دقیق تصاویر (Width & Height):
این مهمترین قانونه. وقتی یه عکس توی مقالهات میذاری، همیشه توی تگ <img>، عرض (width) و ارتفاع (height) رو مشخص کن.
-
چرا؟ چون اینجوری مرورگر، قبل از اینکه خود عکس لود بشه، میدونه باید چقدر فضا براش خالی نگه داره. اینجوری وقتی عکس لود میشه، دقیقاً میشینه سر جای خودش و متنهای پایین رو هُل نمیده.
-
- فضا دادن به تبلیغات و Iframe ها:
این همون سناریوی کلیک اشتباهیه که قبلاً گفتم. اگه تو سایتت تبلیغات داری (مثل بنرهای گوگل ادز) یا از Iframe (مثل ویدئوی آپارات) استفاده میکنی، حتماً باید یه جای مشخص و با ابعاد ثابت براشون در نظر بگیری.
-
تجربه من: ما همیشه یه
<div>با ارتفاع و عرض مشخص (مثلاً ارتفاع ۲۵۰ پیکسل) دور جایگاه تبلیغ میذاریم. اینجوری، حتی اگه تبلیغ دیر لود بشه یا اصلاً لود نشه، اون فضا براش رزرو شده و بقیه صفحه جابهجا نمیشه.
-
فراتر از Core Web Vitals: معیارهای سرعتی که همچنان باید پایش شوند
اهمیت TTFB (Time to First Byte) و نقش کلیدی هاستینگ
TTFB به زبون خیلی ساده: چقدر طول میکشه تا بعد از اینکه کاربر آدرس سایت تو رو زد و Enter کرد، سرور (هاست) تو اولین بایت اطلاعات رو براش بفرسته؟
بذار یه مثال بزنم که همیشه تو تیم خودمون استفاده میکنم:
تصور کن به یه رستوران زنگ میزنی تا غذا سفارش بدی.
-
TTFB: مدت زمانیه که طول میکشه تا یکی گوشی رو برداره و بگه «بفرمایید!»
-
LCP: مدت زمانیه که طول میکشه تا پیتزات آماده بشه و دم در خونه تحویل بگیری.
حالا اگه ۱۰ دقیقه طول بکشه تا اصلاً یکی اون گوشی لعنتی رو برداره (TTFB بالا)، دیگه چه فرقی میکنه آشپزت چقدر سریعه؟ تو همون اول اعصابت خرد شده!
نقش کلیدی هاستینگ: این معیار، ۹۹٪ مواقع، داد میزنه که «هاستت ضعیفه!»
اگه TTFB سایتت بالاست (مثلاً بالای ۶۰۰ میلیثانیه)، یعنی سرورت کُنده. انگار یه کارمند تنبل اون پشت نشسته که دیر جواب تلفنها رو میده. تو این حالت، تو هرچقدر هم عکسهات رو بهینه کنی یا کدهای جاوااسکریپت رو کم کنی، فایده نداره. تو اول باید اون کارمند (هاست) رو عوض کنی! TTFB بد، ریشهی همهی کندیهای بعدیه.
FCP (First Contentful Paint) و درک اولین برداشت کاربر
FCP به زبون ساده: چقدر طول میکشه تا اولین چیز قابل مشاهده (مثل لوگوی سایت، یه تیکه متن، یا منوی بالای صفحه) روی مانیتور کاربر نقاشی بشه؟
برگردیم به مثال تلفن رستوران:
-
TTFB این بود که یکی بگه «بفرمایید!».
-
FCP اینه که طرف بگه «رستوران… لطفاً چند لحظه گوشی…»
دیدی؟ هنوز سفارشت رو نگرفته (LCP)، اما حداقل میدونی که خط وصله و یکی اون پشته!
چرا FCP مهمه؟ چون مستقیم با «حس» کاربر کار داره.
هیچچیزی بدتر از زل زدن به یه صفحهی کاملاً سفید نیست. کاربر فکر میکنه سایت خرابه یا اینترنتش قطع شده. FCP اون لحظهایه که اولین نشونهی حیات رو به کاربر میدی. بهش میگی: «دارم لود میشم! فقط یه کم دیگه صبر کن…»
این معیار به ما کمک میکنه «سرعت درکشده» (Perceived Speed) رو بسنجیم. حتی اگه لود شدن اون عکس بزرگه (LCP) یه کم طول بکشه، اگه FCP سریع باشه، کاربر حس بهتری داره و احتمالاً صفحه رو نمیبنده.
سوالات متداول (FAQ) درباره سرعت سایت
آیا برای رتبه گرفتن باید نمره سرعت ۱۰۰ بگیریم؟
بذار همین اول کار خیالت رو راحت کنم: نه! مطلقاً نه.
میدونم، همهی ما عاشق نمره ۱۰۰ هستیم. حس کمالگراییمون رو قلقلک میده. اما راستش رو بخوای، وسواس برای رسیدن به نمره ۱۰۰، بیشتر وقتا اتلاف وقت و انرژیه.
ببین، گوگل یه ربات کمالگرا نیست؛ یه شبیهساز کاربره. گوگل از تو نمیخواد «کامل» باشی، ازت میخواد «بهاندازه کافی خوب» باشی. برای گوگل چی مهمه؟ اینکه نمرات Core Web Vitals تو توی اون محدوده سبز (Good) قرار بگیره.
-
تجربه من: من سایتهایی رو دیدم که نمرهشون ۹۵ بوده اما رتبهی عالی داشتن، و سایتهایی که ۱۰۰ بودن اما محتوای خوبی نداشتن و اصلاً دیده نمیشدن.
-
حقیقت ماجرا: سرعت یکی از فاکتورهاست. مهم هم هست. اما وقتی از یه حدی (همون مرز سبز) عبور میکنی، گوگل میگه «آفرین! تو قبولی.» و میره سراغ بقیه فاکتورها: محتوای عالی، E-E-A-T، بکلینکها و…
پس به جای جنگیدن برای اون ۵ نمرهی آخر، مطمئن شو که کاربرت «احساس» سرعت میکنه و نمراتت سبزه. همین کافیه.
تفاوت نمره موبایل و دسکتاپ در PageSpeed Insights چیست؟
این یکی از گیجکنندهترین بخشها برای خیلیاست. میزنن تست میگیرن، نمره دسکتاپ مثلاً ۹۰ میشه (خوشحال میشن)، بعد میرن رو تب موبایل و نمره ۴۰ رو میبینن (ناامید میشن)!
تفاوت اصلی اینجاست: PageSpeed Insights داره دو تا سناریوی کاملاً متفاوت رو شبیهسازی میکنه:
-
تست دسکتاپ: فرض میکنه کاربرت پشت یه کامپیوتر قوی، با اینترنت Wi-Fi پرسرعت نشسته. خب معلومه همهچیز سریع لود میشه.
-
تست موبایل: فرض میکنه کاربرت با یه گوشی موبایل میانرده (نه پرچمدار!) و با یه اینترنت 4G نهچندان قوی داره سایتت رو باز میکنه.
کدوم مهمه؟ موبایل. موبایل. و باز هم موبایل.
ما سالهاست که توی عصر «Mobile-First Indexing» زندگی میکنیم. یعنی گوگل، سایت تو رو اول با دید یه کاربر موبایل بررسی میکنه و بر همون اساس بهت رتبه میده. اون نمره دسکتاپ خوبه، اما نمرهی تعیینکننده و حیاتی، همون نمرهی موبایله.
پس اگه نمره موبایلت قرمزه، یعنی زنگ خطر اصلی به صدا در اومده. تمام تمرکزت رو بذار روی سبز کردن نمره موبایل.
هر چند وقت یکبار باید سرعت سایت را بررسی و بهینهسازی کنیم؟
سرعت سایت یه پروژه نیست که یه بار انجامش بدی، تیک بزنی و تموم بشه. سرعت مثل «سلامت» سایته. یه چیز کاملاً پویاست.
-
تجربه من: سرعت یه موجود زنده است که با هر تغییر کوچیک، حالش عوض میشه.
-
یه برنامه پیشنهادی:
-
بعد از هر تغییر بزرگ: این قانون طلایی منه. پلاگین جدید نصب کردی؟ قالب رو عوض کردی؟ یه اسکریپت چت آنلاین اضافه کردی؟ بلافاصله باید سرعت رو چک کنی. ۹۰ درصد خرابکاریها همینجا اتفاق میفته.
-
بررسی روتین (مثلاً ماهانه): حتماً ماهی یه بار به گزارش Core Web Vitals توی سرچ کنسولت سر بزن. اون گزارش «داده میدانی» (Field Data) بهت میگه که تو ۲۸ روز گذشته حال واقعی کاربرهات چطور بوده.
-
بهینهسازی فصلی: اگه تغییر بزرگی هم ندادی، خوبه که هر فصل یه بار با PageSpeed Insights یه چکاپ کامل انجام بدی. شاید یه عکس بهینهنشده جایی آپلود شده باشه یا یه کد نیاز به بازبینی داشته باشه.
-
سرعت یه کارهی دائمیه، اما اگه روتین داشته باشی، هیچوقت به یه بحران تبدیل نمیشه.
جمعبندی: سرعت، فنی نیست؛ «احترامه»!
خب، دیدی؟ اصلاً هم ترسناک نبود! از LCP و عکسهای گنده گفتیم تا INP و اون کلیکهای بیجواب و CLS و اون پرشهای اعصابخردکن.
ته همهی این داستانهای فنی و عددهای PageSpeed، فقط یه حقیقت ساده وجود داره: سرعت، فنیترین راه برای نشون دادن «احترام» به کاربره.
وقتی تو برای وقت کاربرت ارزش قائل میشی، بهش احترام میذاری که سریع به جواب برسه و کلافه نشه، گوگل هم متوجه این احترام میشه و بهت پاداش میده. سرعت سایت، دیگه یه بخش «فنی» مجزا نیست؛ این دقیقاً قلب تپندهی «تجربه کاربری» (UX) و «اعتماد» (Trust) سایته.
حالا نوبت توئه: بعد از خوندن این راهنما، اولین کاری که برای بهتر کردن حال سایتت میکنی چیه؟ اگه یه سوال هم ذهنت رو درگیر کرده، همینجا برام بنویس.
