PageSpeed Insights چیست؟ آموزش تحلیل سرعت سایت

PageSpeed Insights یا به اختصار PSI یکی از ابزارهای اصلی Google برای ارزیابی Performance صفحات وب است. این ابزار می تواند هم داده کاربران واقعی را نشان دهد و هم با اجرای Lighthouse در یک محیط آزمایشگاهی، مشکلات و فرصت های بهبود صفحه را تحلیل کند.

اما PSI را نباید با یک «نمره سرعت» ساده اشتباه گرفت.

عدد Performance که در گزارش Lighthouse می بینید فقط بخشی از تصویر است. ممکن است صفحه در Lab Score خوب باشد اما کاربران واقعی همچنان تجربه ضعیفی داشته باشند، یا برعکس، تست آزمایشگاهی نتیجه متوسطی نشان دهد ولی Field Data کاربران واقعی وضعیت مناسبی داشته باشد.

برای استفاده حرفه ای از PageSpeed Insights باید سه چیز را از هم جدا کنیم:

تجربه واقعی کاربران یا Field Data
تست شبیه سازی شده یا Lab Data
پیشنهادهای تشخیصی Lighthouse

وقتی این سه لایه را درست بخوانیم، PSI از یک ابزار «گرفتن نمره» به ابزاری برای تشخیص مسئله، پیدا کردن Bottleneck و اولویت بندی اصلاحات Performance تبدیل می شود.

برای دیدن جایگاه این ابزار در کنار سایر گزینه‌ها و انتخاب Tool Stack مناسب، راهنمای ابزارهای سئو دید مقایسه‌ای کامل‌تری ارائه می‌دهد.

PageSpeed Insights چیست؟

PageSpeed Insights سرویس Google برای بررسی عملکرد صفحات وب در Mobile و Desktop است.

Google در مستندات رسمی PSI توضیح می دهد که این ابزار دو نوع داده ارائه می کند:

Field Data برای مشاهده تجربه کاربران واقعی

و:

Lab Data برای تحلیل و Debug کردن صفحه در یک محیط شبیه سازی شده.

خود ابزار را می توانید از اینجا باز کنید:

PageSpeed Insights

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

داده تجربه کاربران واقعی
تشخیص های Lighthouse

این دو بخش هدف متفاوتی دارند.

تفاوت Field Data و Lab Data چیست؟

این تفاوت پایه تحلیل PageSpeed Insights است.

Field Data

Field Data از تجربه واقعی کاربران Chrome می آید.

PSI این اطلاعات را از Chrome User Experience Report یا CrUX دریافت می کند و در حال حاضر داده هایی مانند:

را برای بازه تاریخی اخیر کاربران نمایش می دهد. Google توضیح می دهد این داده نماینده تجربه واقعی کاربران روی Deviceها و Networkهای مختلف است.

یعنی Field Data به این سؤال پاسخ می دهد:

کاربران واقعی این صفحه یا Origin در دنیای واقعی چه تجربه ای داشته اند؟

Lab Data

Lab Data با Lighthouse تولید می شود.

در این حالت صفحه در شرایط شبیه سازی شده Load می شود و Metricهای Performance همراه با Diagnostics و پیشنهادهای فنی جمع آوری می شوند.

Lab Data بیشتر به این سؤال کمک می کند:

در این اجرای مشخص، چه چیزی باعث کندی یا مشکل Performance شده است؟

پس:

Field Data برای مشاهده Reality

و:

Lab Data برای Debugging

مناسب تر است.

چرا Field Data و Lab Data با هم فرق دارند؟

این اختلاف کاملاً طبیعی است.

Field Data حاصل تجربه کاربران واقعی است؛ کاربران ممکن است:

گوشی های ضعیف یا قوی داشته باشند؛
Networkهای متفاوتی استفاده کنند؛
از Locationهای مختلف وارد شوند؛
Cache متفاوت داشته باشند؛
و شرایط واقعی مرورگر متفاوتی تجربه کنند.

اما Lab Data تحت یک مجموعه شرایط کنترل شده اجرا می شود.

Google صراحتاً توضیح می دهد که Field Data گزارش تاریخی کاربران واقعی است، در حالی که Lab Data نتیجه یک بار Load شبیه سازی شده روی Device و Network مشخص است. به همین دلیل دو نتیجه می توانند متفاوت باشند.

پس اگر PSI یک عدد در Field و عدد دیگری در Lab نشان داد، نتیجه نگیرید:

«یکی از آنها اشتباه است.»

آنها دو سؤال متفاوت را جواب می دهند.

برای SEO کدام مهم‌تر است: Field یا Lab؟

اگر مسئله تجربه کاربران واقعی است، Field Data اهمیت بیشتری دارد.

Core Web Vitals اساساً Field Metric هستند و هدفشان اندازه گیری تجربه واقعی کاربران است.

اما اگر می خواهید علت مشکل را پیدا و Fix کنید، Lab Data اغلب کاربرد عملی بیشتری دارد.

یک Workflow منطقی:

Field Data نشان می دهد مشکل واقعی وجود دارد.
Lab Data و DevTools برای پیدا کردن علت استفاده می شوند.
اصلاح انجام می شود.
دوباره Lab Test می گیریم.
بعد از جمع شدن داده واقعی جدید، Field Data را بررسی می کنیم.

نباید انتظار داشته باشید تغییر امروز، همان لحظه Field Data تاریخی را عوض کند.

Core Web Vitals چیست؟

Core Web Vitals مجموعه ای از Metricهای تجربه کاربر است که روی سه محور اصلی تمرکز دارد:

سرعت نمایش محتوای اصلی
Responsiveness
Visual Stability

در مجموعه فعلی Core Web Vitals سه Metric اصلی وجود دارد:

Google و web.dev این سه Metric را برای سنجش Loading، Interactivity و Visual Stability معرفی می کنند.

LCP چیست؟

Largest Contentful Paint یا LCP زمان نمایش بزرگ ترین عنصر محتوایی قابل مشاهده در Viewport را اندازه می گیرد.

به زبان ساده، LCP می خواهد بفهمد:

محتوای اصلی صفحه تقریباً چه زمانی برای کاربر ظاهر شد؟

طبق Threshold فعلی Core Web Vitals:

خوب: حداکثر ۲.۵ ثانیه
نیازمند بهبود: بین ۲.۵ تا ۴ ثانیه
ضعیف: بیشتر از ۴ ثانیه

این ارزیابی بر اساس Percentile 75 انجام می شود.

چه چیزهایی معمولاً LCP را خراب می‌کنند؟

بسته به صفحه، علت می تواند متفاوت باشد، اما موارد رایج شامل:

Server Response کند
Hero Image سنگین
CSS یا JavaScript مسدودکننده Render
Font Load نامناسب
CDN نامناسب
Priority اشتباه Resource
DOM یا Layout سنگین

است.

نکته مهم این است که «تصویر بزرگ» همیشه علت LCP ضعیف نیست.

باید ببینید LCP Element واقعاً چیست و Bottleneck در کدام مرحله رخ داده است.

INP چیست؟

Interaction to Next Paint یا INP Responsiveness صفحه را اندازه می گیرد.

یعنی وقتی کاربر با صفحه تعامل می کند، Browser با چه سرعتی Feedback بصری بعدی را نمایش می دهد.

نمونه Interaction:

Click
Tap
Keyboard Input

Threshold فعلی:

خوب: حداکثر ۲۰۰ میلی ثانیه
نیازمند بهبود: ۲۰۰ تا ۵۰۰ میلی ثانیه
ضعیف: بیشتر از ۵۰۰ میلی ثانیه

INP ضعیف اغلب به Main Thread شلوغ مربوط می شود.

مثلاً:

JavaScript سنگین
Long Task
Event Handler پرهزینه
Rendering زیاد
Third-party Script

می توانند Responsiveness را ضعیف کنند.

CLS چیست؟

Cumulative Layout Shift میزان جابه جایی ناخواسته Layout را اندازه می گیرد.

مثلاً کاربر می خواهد روی یک دکمه کلیک کند، اما ناگهان Banner یا تصویر Load می شود و دکمه جابه جا می شود.

Threshold فعلی:

خوب: حداکثر ۰.۱
نیازمند بهبود: ۰.۱ تا ۰.۲۵
ضعیف: بیشتر از ۰.۲۵

علت های رایج CLS:

Image بدون Width و Height
Ad Slot بدون فضای رزروشده
Font Swap نامناسب
Dynamic Content که بالای محتوای موجود Inject می شود
Banner یا Notification ناگهانی

است.

چرا Percentile 75 مهم است؟

Google Thresholdهای Core Web Vitals را بر اساس 75th percentile تجربه کاربران ارزیابی می کند.

هدف این است که Performance فقط برای میانگین کاربران خوب نباشد، بلکه برای بخش بزرگی از کاربران—even کاربران با شرایط ضعیف تر—تجربه قابل قبولی ایجاد شود.

مثلاً اگر ۷۵ درصد Loadهای صفحه LCP مناسب داشته باشند، وضعیت Metric می تواند در محدوده Good قرار بگیرد.

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

PageSpeed Insights از چه داده واقعی استفاده می‌کند؟

Field Data PSI از Chrome User Experience Report یا CrUX می آید.

Google توضیح می دهد PSI تجربه کاربران واقعی را برای بازه ۲۸ روزه اخیر گزارش می کند.

این نکته چند نتیجه مهم دارد.

تغییر امروز فوراً دیده نمی‌شود

اگر امروز Performance را Fix کنید، Field Data همان لحظه سبز نمی شود.

چون Dataset شامل تجربه کاربران در بازه گذشته است.

Traffic کم می‌تواند باعث نبود Field Data شود

همه URLها داده CrUX کافی ندارند.

اگر Sample کافی وجود نداشته باشد ممکن است PSI نتواند Field Data مستقل آن URL را نمایش دهد.

Page Data و Origin Data یکسان نیستند

گاهی ابزار داده URL مشخص را دارد.

گاهی به دلیل نبود Sample کافی ممکن است داده گسترده تری از Origin اهمیت پیدا کند.

نباید این دو Scope را اشتباه گرفت.

اگر Field Data نداشته باشیم چه کنیم؟

نبود Field Data به معنی خوب یا بد بودن Performance نیست.

فقط یعنی Dataset واقعی کافی برای گزارش آن Context وجود ندارد.

در این وضعیت:

Lab Test
Chrome DevTools
Real User Monitoring داخلی
CrUX در Scopeهای دیگر

می توانند اطلاعات مکمل بدهند.

مهم این است که نبود داده را با «Pass شدن» اشتباه نگیریم.

Performance Score در PageSpeed Insights چیست؟

بخش Lab معمولاً یک عدد بین ۰ تا ۱۰۰ نمایش می دهد.

این عدد توسط Lighthouse ساخته می شود.

در مستندات فعلی Lighthouse:

۹۰ تا ۱۰۰: Good
۵۰ تا ۸۹: Needs Improvement
۰ تا ۴۹: Poor

در نظر گرفته می شود.

اما این Score باید درست تفسیر شود.

آیا Performance Score همان Core Web Vitals است؟

نه.

این دو را جدا کنید.

Lighthouse Score از چند Metric آزمایشگاهی با Weight مشخص ساخته می شود.

Core Web Vitals وضعیت Field Metrics مهم تجربه واقعی کاربران است.

ممکن است:

Lighthouse Score = ۹۵
ولی Field Core Web Vitals ضعیف باشد

یا برعکس.

پس عدد ۹۵ به معنی Pass قطعی Core Web Vitals نیست.

آیا Score صد هدف مناسبی است؟

معمولاً نه.

Lighthouse خودش توضیح می دهد گرفتن Score کامل ۱۰۰ بسیار دشوار است و حتی افزایش Score از ۹۹ به ۱۰۰ می تواند هزینه بهبود زیادی داشته باشد. همچنین Performance را بهتر است به صورت Distribution و تجربه واقعی دید، نه یک عدد ثابت.

هدف حرفه ای این نیست:

هر صفحه باید ۱۰۰ بگیرد.

هدف بهتر:

مشکلات مهمی را اصلاح کنیم که تجربه واقعی کاربر را محدود می کنند.

اگر صفحه ای Score ۹۲ دارد و مشکل Business-critical دیگری وجود دارد، تلاش چندروزه برای رسیدن به ۱۰۰ ممکن است ROI بسیار کمی داشته باشد.

Lighthouse Score چگونه ساخته می‌شود؟

Lighthouse Performance Score یک Weighted Average از Metricهای Performance است.

در مستند فعلی Lighthouse، Metricهایی مانند:

First Contentful Paint
Speed Index
Largest Contentful Paint
Total Blocking Time
Cumulative Layout Shift

در Score نقش دارند و Weight آنها یکسان نیست.

این Weightها نیز در طول زمان می توانند تغییر کنند.

بنابراین Score یک مدل تشخیصی است، نه یک Standard ثابت جهانی.

چرا Score هر بار تغییر می‌کند؟

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

Lighthouse توضیح می دهد Variability می تواند از عوامل مختلفی ایجاد شود، از جمله:

تغییر Network
A/B Test
Ads
Scriptهای متغیر
Device Condition
Extension
Routing
Resource Timing

بنابراین اختلاف چند امتیازی بین دو Run همیشه به معنی تغییر واقعی سایت نیست.

روش بهتر این است که:

چند Run بگیرید؛
Trend را ببینید؛
Metricهای خام را مقایسه کنید؛
و روی یک عدد منفرد وسواس نداشته باشید.

Mobile و Desktop چرا متفاوت اند؟

PSI برای Mobile و Desktop شرایط متفاوتی را شبیه سازی می کند.

در مستندات فعلی Google، Mobile Lab Test در شرایط Device و Network محدودتر اجرا می شود، در حالی که Desktop سناریوی متفاوتی دارد.

پس اینکه:

Mobile = ۵۸

Desktop = ۹۴

الزاماً عجیب نیست.

Mobile معمولاً محدودیت بیشتری در:

CPU
Network
Viewport

دارد.

برای سایت هایی که بخش بزرگی از کاربرانشان Mobile هستند، نباید فقط Score Desktop را گزارش کرد.

First Contentful Paint چیست؟

FCP زمانی را اندازه می گیرد که Browser اولین Content قابل مشاهده را Render می کند.

این Content می تواند:

Text
Image
SVG
Canvas

باشد.

FCP شروع دیده شدن محتواست، نه لزوماً نمایش محتوای اصلی صفحه.

به همین دلیل FCP را با LCP اشتباه نگیرید.

صفحه ممکن است FCP خوبی داشته باشد ولی Hero اصلی بسیار دیر Load شود و LCP ضعیف باشد.

Total Blocking Time چیست؟

Total Blocking Time یا TBT یک Metric آزمایشگاهی است که زمان Block شدن Main Thread توسط Long Taskها را اندازه می گیرد.

این Metric در Lab برای Debug کردن Responsiveness مفید است.

TBT Core Web Vital نیست.

اما می تواند برای پیدا کردن مشکلاتی که بعداً روی تجربه تعامل کاربران اثر می گذارند بسیار مفید باشد.

در واقع یکی از کاربردهای خوب Lighthouse همین است:

برای چیزی که Field Data می گوید مشکل Responsiveness داریم، سرنخ فنی پیدا کنیم.

Speed Index چیست؟

Speed Index سرعت پر شدن بصری صفحه را در طول Load اندازه می گیرد.

یعنی به جای تمرکز روی یک Element مشخص، بررسی می کند محتوای Visible صفحه با چه سرعتی ظاهر می شود.

این Metric برای Lab Analysis مفید است اما Core Web Vital نیست.

پس اگر Speed Index نارنجی است نباید آن را به عنوان «SEO Error» معرفی کنیم.

Opportunities و Diagnostics چه هستند؟

در گزارش Lighthouse مجموعه ای از Auditها و پیشنهادها دیده می شود.

اینها می توانند مواردی مثل:

Optimize Images
Reduce JavaScript
Remove Render-blocking Resources
Improve Cache Policy
Reduce Main-thread Work
Avoid Large Layout Shift
Improve Font Loading

را نشان دهند.

اما یک نکته مهم:

هر Opportunity الزاماً Priority نیست.

مثلاً PSI ممکن است بگوید با Compress کردن چند Image می توانید ۱۰۰ KB ذخیره کنید.

اما اگر Bottleneck اصلی Server Response یا JavaScript سنگین باشد، آن ۱۰۰ KB شاید اثر چندانی روی تجربه اصلی نداشته باشد.

باید Recommendationها را بر اساس Impact واقعی Metric تحلیل کرد.

پس از دیدن گزارش PSI از کجا شروع کنیم؟

یک Workflow منطقی:

۱. اول Field Data را ببینید

آیا کاربران واقعی مشکل دارند؟

کدام Metric:

ضعیف است؟

۲. Scope را مشخص کنید

مشکل فقط یک URL است یا Template؟

اگر چند صفحه مشابه رفتار مشابه دارند، احتمالاً Issue ساختاری است.

۳. Lab Data را باز کنید

ببینید در Run آزمایشگاهی چه اتفاقی افتاده است.

۴. Metric مشکل دار را به علت فنی وصل کنید

مثلاً:

LCP ضعیف → LCP Element و Resource Timing

INP ضعیف → Main Thread / JS / Interaction

CLS ضعیف → Layout Shift Source

۵. Diagnostics مرتبط را اولویت بندی کنید

نه تمام Recommendationها.

۶. Fix کنید و Lab را دوباره Test کنید

آیا Metric بهتر شد؟

۷. Field Data را در طول زمان Monitor کنید

آیا تجربه واقعی کاربران نیز بهتر شده است؟

این Workflow بهتر از این است که صرفاً بگوییم:

«Score را از ۶۷ به ۹۰ برسانیم.»

اگر LCP ضعیف باشد چه چیزی را بررسی کنیم؟

اول مشخص کنید LCP Element چیست.

ممکن است:

تصویر Hero
Heading بزرگ
Banner
Background Image
Block متن

باشد.

بعد زنجیره Load را بررسی کنید.

چند سؤال:

Resource دیر Discover می شود؟
Server Response کند است؟
Image بیش از حد بزرگ است؟
Priority پایین دارد؟
JavaScript مانع Render شده؟
CSS دیر می رسد؟
Font باعث Delay شده؟

LCP Optimization یعنی پیدا کردن دلیل دیر دیده شدن محتوای اصلی، نه فقط Compress کردن همه تصاویر.

اگر INP ضعیف باشد چه کنیم؟

INP مسئله Interaction است.

سؤال اصلی:

چه چیزی بعد از تعامل کاربر Main Thread را مشغول نگه می دارد؟

دلایل محتمل:

JavaScript زیاد
Hydration سنگین
Event Handler پیچیده
Long Task
DOM Update سنگین
Third-party Script
Rendering پرهزینه

در این حالت Chrome DevTools معمولاً از PSI عمیق تر است.

PSI Signal می دهد؛ DevTools برای Debugging دقیق تر مناسب تر است.

Chrome DevTools در نسخه های فعلی ابزارهای Performance را برای بررسی Core Web Vitals و Runtime Performance ارائه می کند.

اگر CLS ضعیف باشد چه کنیم؟

برای CLS معمولاً باید Source جابه جایی Layout را پیدا کنید.

نمونه های رایج:

تصویر بدون Dimension

فضا از قبل رزرو نشده و بعد از Load محتوا جابه جا می شود.

تبلیغ یا Embed

فضای Placeholder وجود ندارد.

Font

Font جدید ابعاد Text را تغییر می دهد.

Banner یا Cookie Notice

عنصر بعداً بالای محتوا Inject می شود.

هدف این است که Layout از ابتدا فضای موردنیاز را بداند.

آیا PageSpeed Insights فقط درباره سرعت است؟

نام ابزار می تواند کمی گمراه کننده باشد.

PSI با Lighthouse دسته های دیگری مثل:

Accessibility
Best Practices
SEO

را نیز در Lab Analysis ارائه می کند.

اما نباید این Categoryها را با Audit تخصصی کامل آن حوزه ها یکی دانست.

مثلاً Lighthouse SEO Audit مجموعه ای محدود از Checkهای قابل Automation است.

Score سبز SEO به این معنی نیست که:

«SEO سایت کامل است.»

Lighthouse نمی تواند به تنهایی:

Search Intent
Content Quality
Internal Architecture
Backlink
Cannibalization
Business Relevance

را ارزیابی کند.

آیا امتیاز SEO در Lighthouse مهم است؟

برای Checkهای پایه مفید است.

مثلاً می تواند برخی مشکلات قابل تشخیص خودکار را نشان دهد.

اما همان طور که Performance Score رتبه شما نیست، Lighthouse SEO Score هم «امتیاز Google برای SEO سایت» نیست.

اگر عدد ۱۰۰ باشد، فقط یعنی Auditهای محدود Lighthouse در آن Run مشکلی پیدا نکرده اند.

نه اینکه صفحه برای Ranking آماده کامل است.

آیا PageSpeed Score روی رتبه Google اثر دارد؟

نباید این طور بیان کنیم.

Google Page Experience را به یک Score واحد Ranking تبدیل نکرده است.

Core Web Vitals در سیستم های Ranking استفاده می شوند، اما Google صراحتاً می گوید نباید موفقیت در Search را فقط به یک یا دو جنبه Page Experience تقلیل داد و محتوای مفید و تجربه کلی صفحه اهمیت گسترده تری دارند.

بنابراین:

Lighthouse 100 ≠ Ranking Boost تضمینی

و:

Lighthouse 60 ≠ رتبه ضعیف قطعی

اگر دو صفحه کیفیت و Relevance بسیار متفاوتی دارند، Performance Score به تنهایی تعیین کننده نیست.

آیا Core Web Vitals Ranking Factor هستند؟

Google می گوید Core Web Vitals توسط Ranking Systems استفاده می شوند، اما نتیجه خوب تضمین Ranking بالا نیست.

بهترین بیان این است:

Core Web Vitals بخشی از Page Experience هستند و می توانند در Search اهمیت داشته باشند، اما Ranking به مجموعه بسیار بزرگ تری از سیگنال ها و کیفیت صفحه بستگی دارد.

این تفاوت جلوی تبدیل Performance Optimization به بازی Score را می گیرد.

PageSpeed Insights و Search Console چه تفاوتی دارند؟

هر دو می توانند اطلاعات Core Web Vitals نشان دهند، اما Scope متفاوتی دارند.

Search Console

برای Monitoring گروه های URL در سطح سایت مناسب تر است.

PageSpeed Insights

برای بررسی یک URL مشخص و ترکیب Field Data با Lab Diagnostics مناسب تر است.

Workflow طبیعی:

Search Console → پیدا کردن گروه مشکل دار

PSI → بررسی URL نمونه

DevTools → Debug فنی عمیق

این سه ابزار جای یکدیگر را نمی گیرند.

PageSpeed Insights و Chrome DevTools چه تفاوتی دارند؟

PSI سریع و ساده است.

برای:

گرفتن Snapshot
مشاهده Field Data
دیدن Lighthouse Audit
پیدا کردن فرصت اولیه

عالی است.

DevTools برای Debug دقیق تر مناسب تر است.

مثلاً:

Network Waterfall
Performance Trace
Main Thread
Long Task
Layout Shift
Rendering
Request Timing

را می توان عمیق تر بررسی کرد.

اگر PSI می گوید JavaScript مشکل دارد، DevTools کمک می کند بفهمید کدام Script، چه زمانی و چرا.

PSI و Lighthouse آیا یک چیز هستند؟

نه دقیقاً.

Lighthouse Engine تحلیل آزمایشگاهی است.

PageSpeed Insights از Lighthouse برای Lab Diagnostics استفاده می کند، اما خودش Field Data CrUX را نیز کنار آن نمایش می دهد.

پس:

Lighthouse = Lab Audit

PSI = Field + Lab

این تفکیک ساده بسیار مهم است.

آیا باید Homepage را تست کنیم یا همه صفحات را؟

فقط Homepage کافی نیست.

Performance می تواند بر اساس Template متفاوت باشد.

مثلاً:

Homepage
Article
Product
Category
Search Result
Landing Page

ممکن است ساختار و Resourceهای متفاوتی داشته باشند.

روش بهتر این است که از هر Template مهم چند URL نماینده انتخاب کنید.

اگر تمام Productها Theme مشابه دارند، لازم نیست ده هزار Product را دستی PSI بگیرید.

باید Pattern پیدا کنید.

یک Workflow حرفه‌ای برای Audit سرعت سایت

فرض کنید می خواهیم Performance سایت را ارزیابی کنیم.

مرحله ۱: URLهای مهم را Segment کنید

مثلاً:

Homepage
Blog
Product
Category
Service

مرحله ۲: Field Data را ببینید

آیا مشکل LCP، INP یا CLS وجود دارد؟

مرحله ۳: Mobile و Desktop را جدا کنید

مشکل ممکن است فقط در یکی وجود داشته باشد.

مرحله ۴: Template Pattern پیدا کنید

آیا تمام صفحات Article مشکل مشترک دارند؟

مرحله ۵: Lab Diagnostics

URL نماینده را عمیق بررسی کنید.

مرحله ۶: علت Root Cause را پیدا کنید

نه فقط Recommendation سطحی.

مرحله ۷: Impact را تخمین بزنید

کدام Fix بیشترین کاربر یا Page Type را تحت تأثیر قرار می دهد؟

مرحله ۸: Fix و Validation

اول Lab، بعد Field Monitoring.

این مدل Audit مقیاس پذیرتر از بهینه سازی تصادفی URLهاست.

چه چیزی را اول Fix کنیم؟

اولویت را می توان با چند سؤال تعیین کرد:

آیا مشکل در Field Data واقعی است؟

اگر بله، اهمیت بیشتر می شود.

چند کاربر و صفحه درگیرند؟

مشکل Template کل سایت از یک URL کم ترافیک مهم تر است.

Metric کدام است؟

LCP یا INP ضعیف کاربران زیادی را تحت تأثیر قرار می دهد؟

هزینه Fix چقدر است؟

گاهی Fix ساده ای Impact بالایی دارد.

Business Page است؟

صفحه Checkout یا Landing Page کلیدی می تواند اولویت بالاتری داشته باشد.

پس Severity Tool تنها معیار نیست.

آیا همه پیشنهادهای PageSpeed باید اجرا شوند؟

نه.

این یکی از مهم ترین قواعد.

PSI ممکن است پیشنهاد کند:

CSS کمتر شود
JS کمتر شود
Font تغییر کند
Image تبدیل شود
Third-party Script حذف شود

اما هر تغییر Trade-off دارد.

مثلاً Third-party Script ممکن است برای:

Analytics
Payment
Support
Experiment

ضروری باشد.

هدف این نیست که Tool را راضی کنیم.

هدف این است که تجربه کاربر را با حفظ نیاز Business بهتر کنیم.

چند اشتباه رایج در PageSpeed Insights

دنبال کردن Score 100

Score هدف نهایی نیست.

تست فقط Desktop

Mobile را فراموش نکنید.

بی‌توجهی به Field Data

Lab خوب نمی تواند تجربه واقعی ضعیف را پاک کند.

یکی دانستن Score با Ranking

Performance Score Ranking Score نیست.

اجرای تمام Recommendationها

اول Impact را بررسی کنید.

تست فقط Homepage

Templateها را Segment کنید.

مقایسه Runهای منفرد

Variability طبیعی است.

انتظار تغییر فوری Core Web Vitals

Field Data تاریخی است.

چرا گاهی Field Data خوب است ولی Lab بد؟

سناریوی محتمل:

کاربران واقعی:

Cache دارند
Deviceهای متنوع دارند
CDN نزدیک دارند
شرایط متفاوتی دارند

اما Lab Test در شرایط محدود اجرا می شود.

پس Lab می تواند Scenario سخت تری بسازد.

این الزاماً مشکل نیست.

سؤال این است:

آیا Lab مشکل واقعی قابل اقدام نشان می دهد؟

چرا گاهی Field بد است ولی Lab خوب؟

این حالت مهم تر است.

ممکن است Lab نتواند شرایط واقعی کاربران را بازتولید کند.

مثلاً:

Third-party Script فقط برای بخشی از کاربران Load می شود
Deviceهای واقعی ضعیف ترند
Network کاربران کندتر است
Interaction واقعی در Lab رخ نداده
Geo Delay وجود دارد

در این حالت Field Data را جدی بگیرید و برای Debug از RUM و DevTools کمک بگیرید.

آیا TTFB در PSI مهم است؟

Time to First Byte می تواند درباره زمان دریافت اولین Byte از Server سرنخ بدهد.

TTFB Core Web Vital نیست، اما Server Response ضعیف می تواند روی LCP و تجربه کلی اثر بگذارد.

اگر TTFB بالا باشد، ممکن است لازم باشد مواردی مثل:

Backend
Cache
CDN
Database
Hosting
Network

بررسی شوند.

ولی نباید هر LCP بدی را فقط به Hosting نسبت داد.

باید Breakdown واقعی را ببینید.

آیا تصویر WebP یا AVIF همیشه مشکل را حل می‌کند؟

فرمت Image می تواند مهم باشد، اما فقط یکی از عوامل است.

ممکن است Image بهینه باشد ولی:

دیر Discover شود
Lazy-load اشتباه داشته باشد
اندازه Dimension بزرگ تر از Display باشد
Priority پایین باشد
CDN کند باشد

پس Optimization Image فقط «تبدیل JPG به WebP» نیست.

آیا Lazy Loading همیشه خوب است؟

برای Imageهای Below the Fold معمولاً مفید است.

اما اگر Hero Image یا LCP Element را Lazy Load کنید، ممکن است LCP بدتر شود.

پس Optimization باید Context-aware باشد.

Performance Best Practice مطلق و بدون استثنا کم داریم.

آیا حذف JavaScript همیشه راه‌حل است؟

JavaScript اضافی می تواند مشکل ایجاد کند، اما بسیاری از سایت ها به JS نیاز واقعی دارند.

مسئله بهتر این است:

چه Scriptی ضروری است؟
چه Scriptی دیر اجرا شود؟
چه Codeی Split شود؟
کدام Third-party حذف شود؟
چه Taskی Main Thread را Block می کند؟

هدف «JavaScript صفر» نیست.

هدف اجرای کارآمد JavaScript است.

PageSpeed Insights برای SEO چه ارزشی دارد؟

ارزش اصلی PSI برای SEO در سه سطح است:

تجربه کاربر

Performance بخشی از کیفیت واقعی صفحه است.

تشخیص فنی

PSI می تواند Bottleneckهای مهم را سریع تر نشان دهد.

Monitoring Core Web Vitals

با Field Data می توان وضعیت کاربران واقعی را دید.

اما PSI نباید جای موارد دیگر را بگیرد:

Content Quality
Search Intent
Crawlability
Indexability
Architecture
Internal Linking

Performance یک محور SEO است، نه تمام SEO.

یک سناریوی عملی

فرض کنید صفحه Product مهمی دارید.

PSI نشان می دهد:

Field Data:

LCP = Poor

INP = Good

CLS = Good

Lab:

LCP نیز ضعیف است.

در Diagnostics می بینید LCP Element تصویر Hero است.

Network Analysis نشان می دهد:

تصویر بسیار بزرگ است و دیر Discover می شود.

در اینجا مسئله روشن تر است.

Fix می تواند شامل:

Resize مناسب
Compression
Format بهتر
Priority مناسب
حذف Lazy Load از LCP Image

باشد.

بعد از Fix:

Lab LCP بهتر می شود.

اما Field Data ممکن است چند هفته زمان نیاز داشته باشد تا تجربه کاربران جدید در Dataset منعکس شود.

این Workflow قابل دفاع است.

حالا سناریوی دیگری:

Lighthouse Score = ۶۵

اما Field Core Web Vitals = Pass

و عمده افت Score مربوط به Scriptی است که Business-critical است.

در اینجا تصمیم حرفه ای ممکن است این باشد که به جای تعقیب Score، روی Issue مهم تری کار کنید.

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

جمع‌بندی

PageSpeed Insights ابزار Google برای بررسی Performance صفحات در Mobile و Desktop است و دو نوع داده مهم را کنار هم قرار می دهد:

Field Data برای تجربه واقعی کاربران

و:

Lab Data برای تشخیص و Debugging.

Core Web Vitals فعلی شامل:

LCP برای Loading
INP برای Responsiveness
CLS برای Visual Stability

هستند.

برای استفاده درست از PSI نباید تمام تحلیل را به عدد Performance Score تقلیل دهید.

ابتدا Field Data را ببینید.

مشخص کنید کاربران واقعی چه مشکلی دارند.

بعد از Lab و Diagnostics برای پیدا کردن Root Cause استفاده کنید.

Recommendationها را بر اساس Impact اولویت بندی کنید، نه تعداد Error.

و بعد از Fix، Lab را سریع Validate و Field Data را در طول زمان Monitor کنید.

مهم ترین اصل این است:

هدف PageSpeed Insights سبز کردن Dashboard نیست؛ بهتر کردن تجربه واقعی کاربران است.

وقتی این اصل حفظ شود، PSI از یک ابزار امتیازگیری به یکی از ابزارهای بسیار کاربردی برای Technical SEO و Performance Optimization تبدیل می شود.