How to Use WebPageTest to Test Website Performance

اگر تا به حال برای کشف دقیق مشکلات سرعت سایت تان به ابزارهای عمومی متکی بوده اید، می دانید که نتایج گاهی گنگ و زمان بر می شوند. WebPageTest، با قابلیت های پیشرفته و تست های چند‑مرحله ای، امکان مشاهده جزئیات واقعی زمان بارگذاری را به صورت آنلاین فراهم می کند. در ادامه، هر مرحله از راه اندازی تست تا تفسیر نتایج را به صورت گام به گام، با نکات عملی و نکات کلیدی که توسط متخصصین توصیه شده، بررسی می کنیم. تحلیل های عمقی که از نمودارهای waterfall، زمان تا اولین بایت و معیارهای Core Web Vitals استخراج می شوند، به شما کمک می کند تا دقیقاً بفهمید کدام منابع یا تنظیمات باعث کاهش کارایی می شوند. با دنبال کردن این راهنمای جامع، می توانید به سرعت بهینه سازی های هدفمند را اعمال کرده و تجربه کاربری سایت تان را به سطحی قابل اعتماد ارتقا دهید.

فهرست مطالب

پیکربندی تست برای موقعیت جغرافیایی

یکی از عوامل کلیدی که بر زمان بارگذاری صفحات تأثیر می گذارد، فاصله فیزیکی کاربر از سرور است. اگر سروری در دیتاسنترهای آسیایی داشته باشید ولی کاربران عمده تان در اروپا باشند، زمان رفت وآمد (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 (کاهش شده)1500.8
4G LTE505
Wi‑Fi متوسط3015
فیبر نوری (پیشرفته)5100

یک مثال عملی: اگر فروشگاه آنلاین شما در مناطق روستایی ایران با پوشش 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 PaintSpeed Indexزمان کل (ms)
First View (بدون کش)2.8 ثانیه4,200 ms6,500 ms
Repeat View (کش فعال)1.4 ثانیه2,300 ms3,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 دارید، خوشحال می شوم آن را با هم بررسی کنیم.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *