How to Use WebPageTest to Test Website Performance
اگر تا به حال برای کشف دقیق مشکلات سرعت سایت تان به ابزارهای عمومی متکی بوده اید، می دانید که نتایج گاهی گنگ و زمان بر می شوند. WebPageTest، با قابلیت های پیشرفته و تست های چند‑مرحله ای، امکان مشاهده جزئیات واقعی زمان بارگذاری را به صورت آنلاین فراهم می کند. در ادامه، هر مرحله از راه اندازی تست تا تفسیر نتایج را به صورت گام به گام، با نکات عملی و نکات کلیدی که توسط متخصصین توصیه شده، بررسی می کنیم. تحلیل های عمقی که از نمودارهای waterfall، زمان تا اولین بایت و معیارهای Core Web Vitals استخراج می شوند، به شما کمک می کند تا دقیقاً بفهمید کدام منابع یا تنظیمات باعث کاهش کارایی می شوند. با دنبال کردن این راهنمای جامع، می توانید به سرعت بهینه سازی های هدفمند را اعمال کرده و تجربه کاربری سایت تان را به سطحی قابل اعتماد ارتقا دهید.
فهرست مطالب
- آشنایی اولیه با WebPageTest
- پیکربندی تست برای موقعیت جغرافیایی
- انتخاب مرورگر و سرعت اتصال
- تنظیمات پیشرفته برای بهینه سازی
- تحلیل نتایج زمان بارگذاری
- شناسایی و رفع گلوگاه ها
- استفاده از waterfall برای بهبود
- تکرار تست برای اعتبارسنجی
- سوالات متداول
پیکربندی تست برای موقعیت جغرافیایی
یکی از عوامل کلیدی که بر زمان بارگذاری صفحات تأثیر می گذارد، فاصله فیزیکی کاربر از سرور است. اگر سروری در دیتاسنترهای آسیایی داشته باشید ولی کاربران عمده تان در اروپا باشند، زمان رفت وآمد (latency) به صورت چشمگیری افزایش می یابد. WebPageTest این امکان را فراهم می کند که تست های سرعت را از مکان های جغرافیایی مختلف اجرا کنید تا ببینید عملکرد سایت تان برای هر بخش از بازار چطور است.
برای تنظیم مکان آزمایش، ابتدا به صفحهٔ اصلی WebPageTest بروید و در قسمت «Location» فهرستی از شهرها و ارائه دهندگان اینترنت (ISP) پیش تعریف شده ظاهر می شود. به سادگی می توانید یک شهر مانند «Tehran, Iran – ICLON (Fiber)» یا «London, United Kingdom – BT (Cable)» را انتخاب کنید. پس از انتخاب مکان، نوع اتصال (مثلاً 4G, 3G یا 5 Mbps DSL) را از منوی «Connection» تنظیم کنید؛ این تنظیمات ترکیبی از سرعت دانلود، آپلود و تأخیر (latency) را شبیه سازی می کند.
اگر نیاز به تست از مکانی ندارید که در فهرست پیش فرض باشد، می توانید از گزینهٔ «Custom Location» استفاده کنید. برای این کار به یک سرور آزمون (test agent) در آن منطقه دسترسی داشته باشید یا از سرویس های private instance WebPageTest بهره ببرید. به عنوان مثال، برای بررسی عملکرد سایت در یک ISP محلی در ترکیه، می توانید یک سرور کوچک با دسترسی SSH راه اندازی کنید، کلید API مربوطه را در پنل تنظیمات اضافه کنید و سپس نام دلخواه مثل «Istanbul – Turkcell (Fiber)» را به فهرست مکان ها اضافه کنید.
| موقعیت جغرافیایی | ISP پیشنهادی | اتصال شبیه سازی شده | پیشنهاد عملی |
|---|---|---|---|
| تهران، ایران | ICLON (Fiber) | 5 Mbps ↓ 1 Mbps ↑ 30 ms | بررسی تأثیر CDN داخلی |
| لندن، بریتانیا | BT (Cable) | 10 Mbps ↓ 5 Mbps ↑ 20 ms | تست پس از فعال سازی HTTP/2 |
| نویارک، آمریکا | Verizon (4G) | 4 Mbps ↓ 2 Mbps ↑ 50 ms | بررسی زمان لود برای کاربران موبایلی |
نکتهٔ مهم: برای به دست آوردن نتایج قابل اعتماد، تست را حداقل سه بار از همان مکان اجرا کنید و مقادیر متوسط زمان اولین بایت (TTFB) و بارگذاری کامل صفحه را مقایسه کنید. این کار به ویژه وقتی مفید است که می خواهید اثر بهینه سازی های جدید (مانند به کارگیری Edge Cache) را در نقاط مختلف جهان سنجیده و تصمیم گیری دقیق تری برای گسترش زیرساخت های CDN بگیرید.
انتخاب مرورگر و سرعت اتصال
در WebPageTest، انتخاب مرورگر و تنظیم سرعت اتصال دو عامل کلیدی هستند که نتایج تست را تحت تأثیر مستقیم قرار می دهند. مرورگرهای مختلف به دلایل متفاوتی مانند موتور رندر (مثلاً Blink در Chrome یا Gecko در Firefox) رفتارهای متفاوتی نسبت به پردازش CSS، جاوااسکریپت و بهینه سازی منابع نشان می دهند. بنابراین، برای ارزیابی واقعی عملکرد سایت تان در محیط های واقعی، باید مرورگری را انتخاب کنید که بیش ترین بازدیدکنندگان شما از آن استفاده می کنند.
WebPageTest از چند مرورگر اصلی پشتیبانی می کند: Chrome (نسخه های ثابت و جدید)، Firefox (نسخه های پایدار)، Edge (بر پایه Chromium) و در برخی نقاط دسترسی Safari (در سرورهای macOS). اگر سایت شما به خصوص برای کاربران iOS یا macOS بهینه سازی شده است، تست با Safari می تواند نکات مخفی مربوط به CSS‑prefixed یا WebKit‑specific bugs را آشکار کند. برای اکثر پروژه های عمومی، شروع با Chrome به عنوان مرورگر پیش فرض مناسب است، اما افزودن یک تست تکمیلی با Firefox به دست آوردن دید گسترده تری از زمان بارگذاری می دهد.
سرعت اتصال شبکه نیز باید به دقت تنظیم شود؛ WebPageTest پیش فرض اش شامل پروفایل های مختلفی است که شبیه سازی ۳G، ۴G، فیبر نوری و Wi‑Fi می شوند. در جدول زیر، مقادیر تخمینی تاخیر (latency) و پهنای باند (bandwidth) برای هر پروفایل آورده شده است:
| پروفایل اتصال | تاخیر (ms) | پهنای باند (Mbps) |
|---|---|---|
| 3G (کاهش شده) | 150 | 0.8 |
| 4G LTE | 50 | 5 |
| Wi‑Fi متوسط | 30 | 15 |
| فیبر نوری (پیشرفته) | 5 | 100 |
یک مثال عملی: اگر فروشگاه آنلاین شما در مناطق روستایی ایران با پوشش 3G بیشتر بازدید می شود، اجرای تست با پروفایل «3G (کاهش شده)» و مرورگر Chrome می تواند نقاط ضعف مانند تصاویر بزرگ یا اسکریپت های سنگین را نشان دهد. سپس می توانید با بهینه سازی اندازه تصویر یا بارگذاری تنبل (lazy‑load)، زمان اولین بایت (TTFB) را برای این کاربران به طور قابل توجهی کاهش دهید.
در نهایت، ترکیب چند مرورگر و چند پروفایل سرعت به شما امکان می دهد تا یک ماتریس جامع از عملکرد سایت تان بسازید. این داده ها نه تنها برای بهبود تجربه کاربری مفید هستند، بلکه برای گزارش به تیم توسعه یا ارائه به مشتریان، شفافیت لازم را فراهم می آورند.
تنظیمات پیشرفته برای بهینه سازی
WebPageTest امکانات پیشرفته ای دارد که می توانند جزئیات عمیق تری از عملکرد صفحه تان را آشکار کنند. استفاده هوشمندانه از این تنظیمات به شما این امکان را می دهد که دقیقاً بفهمید کدام بخش ها باعث کندی می شوند و چه بهینه سازی هایی می توانند تأثیر بیشتری داشته باشند. در ادامه مهم ترین گزینه های پیشرفته را بررسی می کنیم و نحوه به کارگیری آن ها را نشان می دهیم.
تنظیمات کلیدی پیشرفته عبارتند از:
- محل آزمون (Location) – انتخاب سروری نزدیک به کاربران هدف، تا زمان تاخیر شبکه واقعی تری اندازه گیری شود.
- سرعت اتصال (Connection) – شبیه سازی انواع پهنای باند (3G، 4G، DSL) برای درک تأثیر شبکه بر زمان بارگذاری.
- حالت کش (Cache) – مقایسهٔ First View (بدون کش) و Repeat View (کش فعال) برای ارزیابی بهره وری کش مرورگر.
- اسکریپت های سفارشی (Custom Script) – افزودن دستورات JavaScript قبل یا بعد از بارگذاری صفحه، مثلاً شبیه سازی کلیک کاربر یا حذف کوکی ها.
- متریک های سفارشی (Custom Metrics) – تعریف نقاط شروع/پایان دلخواه با
window.performance.markبرای اندازه گیری دقیق زمان های خاص.
به عنوان مثال، یک فروشگاه آنلاین می خواهد بفهمد آیا فعال سازی کش برای تصاویر به طور قابل توجهی سرعت نمایش اولین تصویر (First Contentful Paint) را بهبود می بخشد یا خیر. در نتایج زیر دو آزمون مقایسه ای آورده شده است؛ یکی با کش غیرفعال (First View) و دیگری با کش فعال (Repeat View).
| آزمون | First Contentful Paint | Speed Index | زمان کل (ms) |
|---|---|---|---|
| First View (بدون کش) | 2.8 ثانیه | 4,200 ms | 6,500 ms |
| Repeat View (کش فعال) | 1.4 ثانیه | 2,300 ms | 3,200 ms |
از نتایج می توان دریافت که فعال سازی کش تقریباً زمان بارگذاری اولیه را نصف می کند. برای استخراج چنین اطلاعاتی، به نمای Waterfall نگاه کنید؛ ستون های زمان‑بندی درخواست ها نشان می دهند کدام منابع بیشترین تاخیر را دارند. همچنین می توانید از Filmstrip برای مشاهدهٔ فریم‑به‑فریم رندر صفحه استفاده کنید. نکتهٔ کاربردی: همیشه یک آزمون Median (میانه) و یک آزمون Repeat View را به صورت همزمان اجرا کنید تا بتوانید تاثیر کش را به صورت عددی مقایسه کنید.
تحلیل نتایج زمان بارگذاری
وب پیج تست یک نمای دقیق از زمان های مختلف بارگذاری صفحه ارائه می دهد که می توانید با تجزیه وتحلیل این مقادیر، گلوگاه های عملکردی را شناسایی کنید. زمان اولین بایت (Time to First Byte) نشان می دهد که سرور چقدر سریع پاسخ می دهد، در حالی که زمان شروع رندر (Start Render) به سرعتی که مرورگر محتوا را نمایش می دهد می پردازد. معیارهای دیگری چون سرعت نمای شاخص (Speed Index) و زمان بارگذاری کامل (Fully Loaded) نیز برای ارزیابی تجربه کاربر اساسی هستند.
| متریک | شرح مختصر | محدودیت پیشنهادی |
|---|---|---|
| Time to First Byte (TTFB) | مدت زمان بین ارسال درخواست و دریافت اولین بایت از سرور | < 0.8 ثانیه |
| Start Render | زمانی که مرورگر شروع به رندر اولین بخش قابل مشاهده می کند | < 1.5 ثانیه |
| Speed Index | معیاری برای سنجش سرعت پرشدن صفحه با محتوای قابل مشاهده | < 1,200 میلی ثانیه |
| Fully Loaded | زمانی که تمام منابع صفحه (از جمله تبلیغات و اسکریپت های پس زمینه) بارگذاری می شوند | < 3 ثانیه |
وقتی نتایج را مرور می کنید، به مقایسه مقادیر کلیدی با محدودیت های پیشنهادی توجه کنید. به عنوان مثال، اگر TTFB شما 1.2 ثانیه باشد اما سایر معیارها نزدیک به حد مطلوب باشند، ممکن است مشکل اصلی در پیکربندی سرور یا استفاده از CDN باشد. در مقابل، اگر Speed Index بسیار بالا (مثلاً 2,500 ms) باشد، معمولاً به دلیل اسکریپت های بلاک کننده رندر یا تصاویر بزرگ بدون بهینه سازی است.
برای بهبود این اعداد، ابتدا به بهینه سازی سرور بپردازید: فعال سازی فشرده سازی gzip، استفاده از کش سرور و تنظیمات مناسب HTTP/2 می تواند TTFB را به طور قابل توجهی کاهش دهد. سپس، فایل های CSS و JavaScript را ترکیب و مینیمایز کنید و به جای آن ها از بارگذاری تنبل (lazy loading) برای تصاویر استفاده کنید. در نهایت، از ابزار «Waterfall» وب پیج تست برای شناسایی دقیق درخواست های طولانی مدت و حذف یا به تعویق انداختن آن ها بهره ببرید.
- بررسی TTFB و اطمینان از زیر 0.8 ثانیه.
- کاهش زمان Start Render با حذف CSS بلاک کننده.
- بهینه سازی تصاویر و فعال سازی lazy loading.
- استفاده از CDN برای توزیع سریع تر محتوا.
شناسایی و رفع گلوگاه ها
در تست های WebPageTest، گلوگاه ها نقاطی هستند که بارگذاری صفحه را به طور نامتناسب طولانی می کنند. یافتن این نقاط، اولین قدم برای بهبود سرعت است چون هر میلی ثانیه ی اضافه می تواند نرخ ریزش کاربران را بالا ببرد. WebPageTest یک نمای «waterfall» (آبشاری) ارائه می دهد که تمام درخواست ها را به ترتیب زمانی نشان می دهد؛ از این نما می توانید بفهمید کدام درخواست ها بیشترین زمان را اشغال کرده اند.
برای شناسایی گلوگاه ها به صورت سیستماتیک می توانید مراحل زیر را دنبال کنید:
- زمان تا اولین بایت (TTFB) بالا: اگر زمان پاسخ سرور بیش از 200 ms باشد، ممکن است نیاز به بهبود پیکربندی سرور یا استفاده از CDN داشته باشید.
- بارگذاری منابع بزرگ مانند تصاویر یا ویدیوهای بدون فشرده سازی؛ این موارد معمولاً در نوار «waterfall» به صورت نوارهای طولانی ظاهر می شوند.
- کدهای JavaScript یا CSS مسدودکننده رندر: اگر این فایل ها در بالای صفحه قرار دارند و زمان بارگذاری آن ها بیش از 1 s است، رندر صفحه متوقف می شود.
- تعداد درخواست های HTTP زیاد؛ هر درخواست یک هزینه ی شبکه ای دارد که در موبایل یا اتصال های ضعیف می تواند مشکل ساز شود.
- تاخیرهای شبکه ای (latency) در درخواست های سمت سوم (third‑party) مانند سرویس های تجزیه و تحلیل یا تبلیغات.
پس از شناسایی، رفع گلوگاه ها معمولاً شامل بهینه سازی منابع یا تغییر پیکربندی سرور می شود. مهم ترین اقدامات عبارتند از:
- فشرده سازی و تغییر اندازه تصاویر با ابزارهایی مثل
ImageOptimیا سرویس های CDN با قابلیت automatic image optimization. - ترکیب و مینیفای کردن (minify) فایل های CSS/JS؛ می توانید از
webpackیا افزونه های وردپرس مانند «Autoptimize» استفاده کنید. - انتقال اسکریپت های مسدودکننده به انتهای
یا بارگذاری آن ها به صورت آسنکرون (async/defer). - استفاده از کش مرورگر (Cache‑Control) و تنظیم هدرهای
ETagبرای کاهش درخواست های تکراری. - کاهش تعداد درخواست های سوم شخص یا جایگزینی سرویس های سنگین با گزینه های سبک تر.
مثال عملی: یک وب سایت بلاگ تازه راه اندازی شده، تصویر بنر اصلی به صورت ۲ MB بدون فشرده سازی بارگذاری می شد. در گزارش WebPageTest، این تصویر ۲.۴ s زمان صرف کرد و در بخش «waterfall» به عنوان گلوگاه اصلی نشان داده شد. با فشرده سازی تصویر به ۳۰۰ KB و فعال سازی سرویس CDN برای توزیع جغرافیایی، زمان بارگذاری بنر به ۰.۴ s کاهش یافت و امتیاز Speed Index تست به طور قابل توجهی ارتقا یافت.
| نوع گلوگاه | راه حل پیشنهادی |
|---|---|
| TTFB بالا | بهبود پیکربندی سرور، استفاده از CDN، فعال سازی HTTP/2 |
| منابع بزرگ | فشرده سازی تصویر/ویدیو، استفاده از فرمت های مدرن مثل WebP |
| JS/CSS مسدودکننده | بارگذاری آسنکرون، مینیفای کردن، ترکیب فایل ها |
| درخواست های متعدد | استفاده از اسپریت سازی، ترکیب CSS/JS، کاهش پلاگین های جانبی |
استفاده از waterfall برای بهبود
نمای آبشاری (Waterfall) در WebPageTest تصویری گرافیکی از تمام درخواست های HTTP که مرورگر برای بارگذاری صفحه انجام می دهد، ارائه می کند. هر میله افقی نمایانگر یک درخواست است و طول آن نشان دهنده زمان صرف شده برای دریافت پاسخ است. با نگاه دقیق به این نما می توانید نقاط گلوگاه-مانند زمان طولانی DNS lookup، انتظار برای TCP handshake یا بارگذاری منابع مسدودکننده-را شناسایی کنید و برنامه ریزی دقیقی برای بهینه سازی داشته باشید.
برای درک بهتر، به بخش های اصلی آبشاری دقت کنید:
| بخش | هدف | مدت زمان معمول (ثانیه) |
|---|---|---|
| DNS Lookup | تبدیل نام دامنه به IP | ۰.۰۲-۰.۱ |
| TCP Handshake | برقراری اتصال TCP | ۰.۰۵-۰.۲ |
| SSL Negotiation | مستندسازی ارتباط ایمن | ۰.۰۲-۰.۱۵ |
| Request/Response | دریافت محتوا (HTML, CSS, JS, …) | ۰.۱-۲ |
| First Paint / Fully Loaded | رندر اولین پیکسل ها و تکمیل بارگذاری | ۰.۳-۳ |
پس از شناسایی زمان های طولانی، اقدامات زیر می تواند به سرعت سازی کمک کند:
- ترکیب و فشرده سازی فایل ها: چند فایل CSS یا JavaScript را در یک فایل ادغام کنید و از gzip یا brotli برای فشرده سازی استفاده کنید.
- بارگذاری تنبل (Lazy Load) برای تصاویر: تا زمانی که کاربر به بخش مربوطه اسکرول نکند، تصویرها درخواست نشوند.
- کاهش منابع مسدودکننده رندر: اسکریپت های سنگین را با
asyncیاdeferبارگذاری کنید تا رندر اولیه تحت تأثیر قرار نگیرد. - استفاده از CDN: فایل های ایستاتیک را از یک شبکه تحویل محتوا (Content Delivery Network) سرو کنید تا فاصله فیزیکی به کاربر کاهش یابد.
- بهینه سازی کش مرورگر: هدرهای
Cache-ControlوExpiresرا تنظیم کنید تا درخواست های تکراری حذف شوند.
به عنوان مثال، در یک تست آبشاری برای یک صفحه فروشگاهی، می بینید که فایل CSS اصلی ۲۲۲ KB است و زمان دریافت آن ۱.۷ ثانیه طول می کشد. با تقسیم این فایل به دو بخش (یک بخش برای استایل های پایه و یک بخش برای استایل های مخصوص صفحه) و افزودن media="print" برای بخش دوم، می توانید زمان دریافت را به حدود ۰.۹ ثانیه برسانید. پس از به روزرسانی، نمودار آبشاری نشان می دهد که زمان کلی بارگذاری صفحه از ۳.۲ ثانیه به زیر ۲ ثانیه کاهش یافته است، که به وضوح بهبود عملکرد را نشان می دهد.
تکرار تست برای اعتبارسنجی
در WebPageTest، اجرای یک تست تنها برای یک بار ممکن است نتایج ناپایداری ایجاد کند؛ شبکه، کش مرورگر و حتی بار سرور می توانند در هر بار متفاوت باشند. برای اینکه اطمینان حاصل کنید معیارهای کلیدی مثل Time to First Byte (TTFB) و First Contentful Paint (FCP) واقعی هستند، توصیه می شود همان سناریو را حداقل ۳ تا ۵ بار تکرار کنید و سپس میانگین یا میانه مقادیر را محاسبه کنید.
هنگام تکرار تست، به خصوص در زمان های مختلف روز (مثلاً صبح، ظهر و عصر) سعی کنید بار شبکه و سرور را تغییر دهید. این کار به شما کمک می کند تا عملکرد سایت را تحت شرایط مختلف بارگذاری ببینید و نقاط ضعف را بهتر شناسایی کنید. اگر در یک بازه زمانی خاص نتایج به طور واضحی پایین تر هستند، می توانید به سرعت مشکل مربوط به تراکم ترافیک یا تنظیمات سرور را بررسی کنید.
| تعداد اجرا | متریک های پیشنهادی برای میانگین گیری | روش ترکیب نتایج |
|---|---|---|
| ۳ بار | TTFB, FCP, Speed Index | میانه (Median) |
| ۵ بار | تمامی متریک های کلیدی | میانگین وزن دار (Weighted Avg.) |
| ۱۰ بار | برای تست های بحرانی یا بهینه سازی عمیق | میانه + حذف مقادیر خارج از بازه ۹۰٪ |
به عنوان مثال، اگر در یک تست پنج باره، مقدار FCP در چهار بار حدود ۲۲۰ میلی ثانیه و در یک بار دیگر ۴۵۰ میلی ثانیه باشد، حذف این خروجی ناهماهنگ (آوتلایر) و استفاده از میانه می تواند نمای دقیق تری از عملکرد واقعی کاربران ارائه دهد. این رویکرد به خصوص برای سایت های فروشگاهی که سرعت بارگذاری مستقیماً بر نرخ تبدیل تأثیر دارد، حیاتی است.
در نهایت، برای مستندسازی نتایج، یک گزارش ساده شامل تعداد اجراها، زمان های اجرا، مقادیر میانه یا میانگین و هر نکته مشهود (مانند افزایش ناگهانی زمان پاسخ) تهیه کنید. این گزارش نه تنها به تیم فنی کمک می کند تا تغییرات را پیگیری کند، بلکه در جلسات استراتژیک می تواند به عنوان مبنای تصمیم گیری برای بهبود زیرساخت یا بهینه سازی کد استفاده شود.
سوالات متداول
چگونه می توان تست سرعت صفحه را با تنظیمات مختلف انجام داد؟
ابتدا به وب سایت WebPageTest.org وارد شوید. در بخش Settings گزینه های مختلفی مثل اتصال 3G/4G، کش مرورگر و تعداد تکرار را انتخاب کنید. سپس URL موردنظر را وارد کرده و روی Start Test کلیک کنید. نتایج در پنل Summary و Details به شما نمایش داده می شود.
آیا می توان تست را برای مرورگرهای موبایل شبیه سازی کرد؟
بله، در بخش Settings می توانید Device را روی iPhone یا Android انتخاب کنید. همچنین می توانید سرعت شبکه را به 3G یا 4G محدود کنید تا شرایط واقعی موبایل شبیه شود. پس از تنظیمات، تست همانند دسکتاپ اجرا می شود.
چرا زمان First Contentful Paint در نتایج متفاوت است؟
این زمان به عوامل مختلفی چون اندازه CSS، زمان بارگذاری جاوااسکریپت و کش مرورگر وابسته است. هر بار اجرای تست با شرایط شبکه یا کش متفاوت ممکن است مقدار FCP را تغییر دهد. برای مقایسه دقیق، تست ها را با حالت Disable cache و یکسان سازی سرعت شبکه انجام دهید.
چگونه می توان گزارش waterfall را برای بهبود رندر تجزیه و تحلیل کرد؟
در گزارش waterfall هر ردیف نشان دهنده یک درخواست است؛ زمان های DNS, Connect, SSL و Transfer را بررسی کنید. درخواست های بلوک کننده رندر مانند CSS بالا را به صورت async یا inline کنید. همچنین می توانید منابع بزرگ را فشرده یا بهینه سازی کنید تا زمان بارگذاری کلی کاهش یابد.
چک لیست سریع
- ابزار WebPageTest را باز کنید و رابط کاربری را بشناسید.
- موقعیت جغرافیایی هدف را برای تست انتخاب کنید.
- مرورگر و سرعت اتصال مناسب برای کاربران نهایی را تنظیم کنید.
- تنظیمات پیشرفته مثل تعداد تکرار و زمان سنجی را بهینه کنید.
- نتایج زمان بارگذاری را بررسی و نقاط ضعف را شناسایی کنید.
- گلوگاه های منابع یا درخواست های سنگین را بر پایه نمودار waterfall رفع کنید.
- تست را چندین بار اجرا کنید تا نتایج معتبر شوند.
با اجرای گام به‑گام تست ها، می توانید نقاط ضعف سرعت بارگذاری سایت را دقیقاً pinpoint کنید و بهینه سازی های هدفمند انجام دهید. تکرار تست ها و مقایسه نتایج، اطمینان می دهد که تغییرات واقعی در عملکرد به دست آمده اند. اگر تجربه یا سؤال خاصی در استفاده از WebPageTest دارید، خوشحال می شوم آن را با هم بررسی کنیم.