سه ثانیه. بعد از آن، مشتری رفته است.

بهینه‌سازی سرعت سایت یعنی چه و چرا مهم است

بخش بزرگی از بازدیدکننده‌های یک سایت ایرانی با گوشی می‌آیند؛ با اینترنتی که همیشه پرسرعت نیست و گوشی‌ای که همیشه نو نیست. برای این آدم، «سرعت سایت» یک عدد فنی نیست؛ همان چند ثانیه‌ای است که به صفحه‌ی سفید نگاه می‌کند و تصمیم می‌گیرد بماند یا برگردد. هر بار که برگردد، پول تبلیغی که برای آوردنش داده‌اید، وقتی که برای نوشتن محتوا گذاشته‌اید و فرصت فروش، با هم از دست رفته است.

بهینه‌سازی سرعت سایت کار جادویی نیست. صفحه‌ی وب از تعدادی فایل ساخته شده است: یک فایل HTML که اسکلت صفحه است، فایل‌های CSS که ظاهر را می‌سازند، فایل‌های جاوااسکریپت که صفحه را زنده و تعاملی می‌کنند، عکس‌ها و فونت‌ها. سرور هم باید این فایل‌ها را بسازد و بفرستد. هر کدام از این‌ها اگر سنگین‌تر یا کندتر از لازم باشد، چند صدم ثانیه به انتظار اضافه می‌کند و جمع این صدم‌ها همان چند ثانیه‌ای می‌شود که مشتری را فراری می‌دهد. کار ما در بهینه‌سازی این است که این زمان را تکه‌تکه پس بگیریم.

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

Core Web Vitals به زبان ساده: سرعت را با چه عددهایی می‌سنجند

گوگل برای اینکه «سریع» یک تعریف مشترک داشته باشد، سه عدد را به نام Core Web Vitals (معیارهای اصلی تجربه‌ی صفحه) معرفی کرده است. طبق راهنمای web.dev، صفحه‌ای خوب حساب می‌شود که این سه شرط را داشته باشد:

• LCP (نمایش بزرگ‌ترین محتوا): لحظه‌ای که بزرگ‌ترین بخش صفحه، مثلا عکس اصلی یا تیتر بزرگ، دیده می‌شود. باید ۲٫۵ ثانیه یا کمتر باشد. این همان لحظه‌ای است که بازدیدکننده حس می‌کند صفحه باز شد.
• INP (پاسخ به تعامل): از لحظه‌ای که کاربر روی چیزی می‌زند تا وقتی صفحه واکنش نشان می‌دهد. باید ۲۰۰ میلی‌ثانیه یا کمتر باشد.
• CLS (ثبات چیدمان): اینکه صفحه هنگام باز شدن چقدر جابه‌جا می‌شود. باید ۰٫۱ یا کمتر باشد. پرش صفحه همان چیزی است که باعث می‌شود انگشت روی دکمه‌ی اشتباه بنشیند.

نکته‌ی مهمی که همان راهنما می‌گوید این است که این عددها باید برای بیشتر بازدیدکننده‌ها برقرار باشند، نه فقط برای یک تست روی کامپیوتر شما؛ گوگل صدک ۷۵ را می‌سنجد، یعنی دست‌کم سه‌چهارم بازدیدها باید از این مرزها بهتر باشند، و موبایل و دسکتاپ را جدا حساب می‌کند.

این سه عدد هنوز برای بیشتر سایت‌های دنیا سخت است. طبق فصل کارایی Web Almanac ۲۰۲۵، فقط ۴۸ درصد سایت‌ها روی موبایل هر سه معیار را قبول شده‌اند؛ یعنی اگر سایت شما قبول نیست، تنها نیستید، و اگر قبول شود، از بیش از نیمی از سایت‌ها جلوترید.

امتیاز PageSpeed از کجا می‌آید

وقتی سایت را در PageSpeed یا ابزارهای مشابه تست می‌کنید، یک امتیاز از ۱۰۰ می‌گیرید. این امتیاز را Lighthouse می‌دهد، موتور سنجشی که خود گوگل ساخته است. طبق مستندات Lighthouse، امتیاز از پنج عدد ساخته می‌شود: زمان مسدود شدن صفحه (TBT) ۳۰ درصد، LCP ۲۵ درصد، CLS ۲۵ درصد، و اولین نمایش محتوا و سرعت پر شدن صفحه هر کدام ۱۰ درصد. امتیاز ۹۰ تا ۱۰۰ سبز است، ۵۰ تا ۸۹ نارنجی و زیر ۵۰ قرمز.

TBT جای INP را در تست می‌گیرد؛ چون در یک تست خودکار کسی روی صفحه نمی‌زند، Lighthouse می‌سنجد صفحه چقدر وقت مشغول اجرای کد بوده و نمی‌توانسته به کاربر جواب بدهد. برای همین سایتی که جاوااسکریپت زیادی دارد، حتی اگر زود دیده شود، امتیاز کمی می‌گیرد.

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

بزرگ‌ترین اشتباه در افزایش سرعت سایت، شروع کار بدون عدد است. بهینه‌سازی سرعت سایت بدون اندازه‌گیری، حدس زدن است: افزونه‌ای نصب می‌شود، هاست عوض می‌شود، و هیچ‌کس نمی‌داند کدام کار اثر داشت. پیش از هر تغییری، وضعیت امروز سایت را ثبت کنید.

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

برای تست آزمایشگاهی موبایل، Lighthouse طبق مستندات خودش اینترنتی با سرعت دانلود ۱٫۶ مگابیت و تاخیر ۱۵۰ میلی‌ثانیه را شبیه‌سازی می‌کند و پردازنده را چهار برابر کند می‌کند تا به یک گوشی میان‌رده برسد. این شرایط سخت‌گیرانه عمدی است: اگر سایت در این شرایط خوب باشد، برای بیشتر مردم هم خوب است.

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

یادتان باشد امتیاز از تستی به تست دیگر چند واحد بالا و پایین می‌رود. مستندات Lighthouse هم می‌گوید بیشتر این نوسان از تغییر شرایط شبکه و سرور است و بهتر است کارایی را یک بازه ببینید، نه یک عدد. پس از یک تست نتیجه نگیرید و تغییر چند واحدی را جدی نگیرید.

چه چیزهایی سایت را کند می‌کند؟ راه کاهش زمان بارگذاری

وقتی گزارش را باز می‌کنید، فهرستی از مشکل‌ها می‌بینید. بیشترشان در شش دسته جا می‌گیرند.

عکس‌های سنگین

عکس‌ها بیشترین حجم بیشتر صفحه‌ها را می‌سازند. طبق فصل حجم صفحه‌ی Web Almanac ۲۰۲۵، صفحه‌ی اصلی میانه روی موبایل ۹۱۱ کیلوبایت عکس دارد، بیشتر از هر نوع فایل دیگر. همان منبع در فصل کارایی نشان می‌دهد در ۷۶ درصد صفحه‌های موبایل، بزرگ‌ترین محتوای صفحه یک عکس است؛ یعنی عدد LCP بیشتر سایت‌ها در عمل یعنی «عکس اصلی چقدر زود می‌رسد». مشکل‌های رایج: عکسی که با کیفیت دوربین آپلود شده، عکس دوهزار پیکسلی که در کادر چهارصد پیکسلی نمایش داده می‌شود، و فرمت قدیمی به جای WebP یا AVIF که با همان کیفیت حجم کمتری دارند.

جاوااسکریپت زیاد

جاوااسکریپت کدی است که صفحه را تعاملی می‌کند: منو، اسلایدر، سبد خرید، ابزار چت. طبق Web Almanac ۲۰۲۵، صفحه‌ی اصلی میانه روی موبایل ۶۳۲ کیلوبایت جاوااسکریپت دارد. مشکل فقط حجم نیست؛ web.dev توضیح می‌دهد که جاوااسکریپت برای مرورگر از عکس یا فونتی با همان حجم گران‌تر است، چون باید خوانده، ترجمه و اجرا شود و در همین مدت صفحه نمی‌تواند به لمس کاربر جواب بدهد. قالب‌های همه‌کاره و صفحه‌سازهای کشیدنی، اسلایدرهایی که فقط در یک صفحه استفاده می‌شوند و کتابخانه‌هایی که دو بار بارگذاری می‌شوند، دلیل‌های همیشگی‌اند.

CSS و فونت

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

سرور کند

پیش از همه‌ی این‌ها، سرور باید جواب اول را بدهد. زمان رسیدن اولین بایت پاسخ را TTFB می‌گویند و طبق web.dev خوب یعنی ۰٫۸ ثانیه یا کمتر. Web Almanac ۲۰۲۵ نشان می‌دهد فقط ۴۴ درصد صفحه‌های موبایل TTFB خوب دارند. دلیل‌های رایج: هاست اشتراکی شلوغ، نبود کش صفحه، دیتابیسی که با سال‌ها داده‌ی اضافه سنگین شده، نسخه‌ی قدیمی PHP، و سروری که از کاربر خیلی دور است.

کدهای شخص ثالث

ابزار آمار، چت آنلاین، پیکسل تبلیغات، نقشه، ویدیوی جاسازی‌شده و دکمه‌ی شبکه‌ی اجتماعی. هر کدام از سرور دیگری کد می‌آورد که شما کنترلی روی آن ندارید. یکی‌شان بی‌ضرر است؛ پنج‌تایشان با هم می‌توانند ثانیه‌ها به بارگذاری اضافه کنند.

پرش چیدمان

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

راهکارهای افزایش سرعت سایت، از پرفایده به کم‌فایده

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

1. عکس اصلی بالای صفحه را جدی بگیرید. web.dev در راهنمای بهبود LCP زمان LCP را به چهار تکه تقسیم می‌کند: پاسخ سرور، تاخیر پیش از شروع دانلود عکس، مدت دانلود، و تاخیر نمایش. تکه‌های «تاخیر» باید نزدیک صفر باشند. یعنی عکس اصلی باید سبک باشد، در خود HTML آمده باشد و با fetchpriority="high" به مرورگر گفته شود اول آن را بگیرد. همان راهنما صریح می‌گوید عکس LCP را هرگز با بارگذاری تنبل عقب نیندازید.
2. بقیه‌ی عکس‌ها را سبک و تنبل کنید. هر عکس به اندازه‌ای که نمایش داده می‌شود بریده شود، به WebP یا AVIF تبدیل شود و عکس‌های پایین صفحه با loading="lazy" فقط وقتی بارگذاری شوند که کاربر به آن‌ها نزدیک می‌شود. web.dev یادآوری می‌کند که عکس‌های بالای صفحه نباید تنبل باشند. برای هر عکس عرض و ارتفاع هم بنویسید تا صفحه نپرد.
3. کش صفحه را روشن کنید. وقتی صفحه یک بار ساخته و آماده نگه داشته شود، سرور برای بازدیدکننده‌ی بعدی دیگر لازم نیست از اول PHP و دیتابیس را به کار بیندازد. این معمولا بزرگ‌ترین قدم برای کوتاه کردن TTFB است. برای فایل‌های ثابت هم کش مرورگر با عمر بلند بگذارید.
4. جاوااسکریپت را سبک کنید. کدهایی که در صفحه استفاده نمی‌شوند حذف شوند، اسکریپت‌هایی که برای نمایش اول لازم نیستند با defer بعد از آماده شدن صفحه اجرا شوند، و کتابخانه‌های تکراری کنار بروند. این کار عدد TBT و INP را با هم بهتر می‌کند.
5. CSS را مرتب کنید. استایل ضروری بالای صفحه جدا و زود برسد و بقیه بدون مسدود کردن نمایش بارگذاری شود. استایل‌های بی‌استفاده پاک شوند.
6. فونت را کوچک کنید. فقط وزن‌هایی که واقعا استفاده می‌شوند، با فرمت WOFF2 و زیرمجموعه‌ی حروفی که لازم است؛ با font-display: swap تا متن پیش از رسیدن فونت دیده شود، و پیش‌بارگذاری فونت اصلی.
7. سرور را تنظیم کنید. فشرده‌سازی Brotli یا gzip، پروتکل HTTP/2 یا HTTP/3، نسخه‌ی تازه‌ی PHP، کش آبجکت برای دیتابیس و اصلاح پرسش‌های کند.
8. کدهای شخص ثالث را بچینید. آن‌هایی که دیگر استفاده نمی‌شوند حذف شوند و بقیه بعد از بارگذاری صفحه بیایند. ابزار چتی که در ثانیه‌ی اول لازم نیست، نباید در ثانیه‌ی اول بارگذاری شود.

بعد از هر مرحله دوباره تست بگیرید. اگر عددی بدتر شد، همان تغییر آخر را برگردانید. این روش کند به نظر می‌رسد، ولی تنها راهی است که مطمئن شوید چه چیزی اثر داشته است.

افزایش سرعت سایت وردپرس: آنچه فرق می‌کند

وردپرس محبوب‌ترین سیستم ساخت سایت است؛ طبق فصل CMS در Web Almanac ۲۰۲۵، حدود ۶۴ درصد سایت‌هایی که با یک سیستم مدیریت محتوا ساخته شده‌اند وردپرسی‌اند، و در همان سال ۴۵ درصد سایت‌های وردپرسی روی موبایل Core Web Vitals را قبول شده‌اند. پس وردپرس ذاتا کند نیست؛ نزدیک به نیمی از سایت‌های وردپرسی با همین سیستم سریع‌اند. چیزی که وردپرس را کند می‌کند، معمولا شیوه‌ی ساختن آن است.

چند چیز مخصوص وردپرس:

• افزونه‌ها. هر افزونه ممکن است در همه‌ی صفحه‌ها CSS و جاوااسکریپت خودش را بارگذاری کند، حتی جایی که استفاده نمی‌شود. افزونه‌ی فرم تماس که در صفحه‌ی اصلی هم کد می‌فرستد، نمونه‌ی رایج است. تعداد افزونه‌ها کمتر از رفتار آن‌ها اهمیت دارد.
• قالب و صفحه‌ساز. قالب‌های چندمنظوره و صفحه‌سازهای کشیدنی راحت‌اند، ولی معمولا کد زیادی برای امکاناتی می‌فرستند که سایت شما استفاده نمی‌کند. بیشتر وقت‌ها لازم نیست قالب را عوض کنید؛ باید بارگذاری اضافه را محدود کنید.
• نسخه‌ی PHP. وردپرس رسما توصیه می‌کند از PHP نسخه‌ی ۸٫۳ یا بالاتر استفاده شود و می‌گوید نسخه‌های قدیمی‌تر به پایان عمر رسیده‌اند. نسخه‌ی تازه هم امن‌تر است و هم معمولا سریع‌تر.
• دیتابیس. بازنویسی‌های قدیمی نوشته‌ها، داده‌ی موقتی که هیچ‌وقت پاک نشده و تنظیم‌های افزونه‌هایی که سال‌ها پیش حذف شده‌اند، دیتابیس را سنگین می‌کنند. کش آبجکت (مثلا Redis) هم پرسش‌های تکراری را از دوش دیتابیس برمی‌دارد.
• ووکامرس. فروشگاه بخش‌هایی دارد که کش شدنشان سخت است، مثل سبد خرید و حساب کاربری. تنظیم درست کش برای فروشگاه یعنی صفحه‌های محصول و دسته کش شوند و صفحه‌های شخصی نه.
• افزونه‌ی کش کافی نیست. افزونه‌ی کش برای TTFB عالی است، ولی عکس سنگین، فونت اضافه و جاوااسکریپت بی‌استفاده را درست نمی‌کند. نصب سه افزونه‌ی بهینه‌سازی با هم هم معمولا کار را بدتر می‌کند، چون کار همدیگر را تکرار یا خراب می‌کنند.

اگر سایت وردپرسی شما روی هاست اشتراکی است و حتی بعد از این کارها TTFB بالا می‌ماند، احتمالا گلوگاه خود هاست است. در این حالت پیکربندی سرور وردپرس روی سرور مجازی خودتان، با کش و تنظیم مخصوص همان سایت، قدم بعدی است.

اشتباه‌های رایج در بهینه‌سازی سرعت سایت

• دنبال کردن امتیاز ۱۰۰. امتیاز وسیله است، نه هدف. هدف این است که بازدیدکننده‌ی واقعی صفحه را زود ببیند و صفحه زود جواب بدهد. صادقانه بگوییم: سایت خود تیم سفید هم در اندازه‌گیری ۹ مهر ۱۴۰۵ از سرور ایران و با ضریب کالیبره، روی موبایل بین ۷۹ تا ۸۳ گرفت، در حالی که روی یک کامپیوتر سریع ۱۰۰ است. بخشی از این فاصله کف خود ابزارهای ساخت سایت روی پردازنده‌ی کند است.
• عوض کردن هاست پیش از اندازه‌گیری. اگر صفحه چند مگابایت عکس و کد دارد، روی بهترین سرور هم کند است. اول ببینید زمان کجا می‌رود.
• تنبل کردن همه‌ی عکس‌ها. بارگذاری تنبل برای عکس‌های پایین صفحه خوب است و برای عکس اصلی بد.
• تست فقط روی دسکتاپ یا فقط روی اینترنت دفتر. بخش بزرگی از مشتری‌ها با گوشی می‌آیند. تست موبایل را معیار بگیرید.
• تست از خارج برای مشتری داخل. عدد سروری در اروپا، تجربه‌ی مشتری در شیراز یا مشهد نیست.
• فراموش کردن بعد از کار. سایتی که امروز سریع شده، با چند عکس چندمگابایتی و یک افزونه‌ی سنگین دوباره کند می‌شود. هر چند وقت یک بار تست بگیرید و قاعده‌های ساده‌ی آپلود عکس را به همه‌ی کسانی که محتوا می‌گذارند بگویید.

سرعت سایت و سئو: رابطه‌ی واقعی چیست

گوگل صریحا می‌گوید که Core Web Vitals در سیستم‌های رتبه‌بندی‌اش استفاده می‌شود؛ ولی در همان صفحه هم می‌گوید همیشه مرتبط‌ترین محتوا را نشان می‌دهد، حتی اگر تجربه‌ی صفحه ضعیف باشد. معنی ساده‌اش این است: سرعت به‌تنهایی شما را اول نمی‌کند، ولی بین دو صفحه‌ی خوب، صفحه‌ی سریع‌تر برتری دارد. اثر غیرمستقیم سرعت هم کم نیست: بازدیدکننده‌ای که می‌ماند، صفحه‌های بیشتری می‌بیند و بیشتر می‌خرد.

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

کی خودتان انجام دهید و کی به یک تیم بسپارید

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

ولی این نشانه‌ها می‌گویند بهتر است کار را به کسی بسپارید که هر روز با آن سروکار دارد:

• گزارش پر از هشدارهای جاوااسکریپت و CSS است و نمی‌دانید کدام کد مال کدام افزونه است.
• TTFB بالاست و نمی‌دانید مشکل از هاست است، از دیتابیس یا از یک افزونه.
• سایت فروشگاهی است و می‌ترسید با تغییر کش، سبد خرید کسی خراب شود.
• چند افزونه‌ی بهینه‌سازی امتحان کرده‌اید و سایت گاهی به هم ریخته است.
• وقت ندارید هر تغییر را جدا تست کنید.

تیم سفید همان تیمی است که سفید، چت‌بات هوش مصنوعی فروشگاه‌ها، را ساخته و نگه می‌دارد، و ابزار رایگان تست سرعت همین سایت را هم خودش نوشته است. در خدمت بهینه‌سازی سرعت سایت روش کار همان است که در این راهنما خواندید: روز اول از کل سایت پشتیبان می‌گیریم و عددهای امروز را با همان ابزار ثبت می‌کنیم؛ بعد عکس‌ها، فونت‌ها، CSS و جاوااسکریپت؛ بعد کش، سرور و دیتابیس؛ بعد کدهای شخص ثالث، پرش چیدمان و پاسخ به لمس؛ و در پایان، تست روی موبایل و دسکتاپ و گزارش قبل و بعد. ظاهر و امکانات سایت عوض نمی‌شود و هر کاری فقط وقتی انجام می‌شود که گزارش نشان بدهد لازم است.

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

از کجا شروع کنیم

اگر هنوز نمی‌دانید سایت‌تان چقدر کند است، از یک تست شروع کنید. سایت‌تان را رایگان از سرور تهران تست کنید؛ یکی دو دقیقه طول می‌کشد و گزارش فارسی می‌گوید زمان کجا می‌رود. با همین گزارش می‌توانید کارهای ساده را خودتان انجام دهید، یا اگر خواستید، کار را به ما بسپارید. اگر کنجکاوید سایت‌های دیگر کجا ایستاده‌اند، فهرست سریع‌ترین سایت‌های ایرانی را هم ببینید. و اگر پروژه‌ی بزرگ‌تری دارید یا سوالی که اینجا جوابش نبود، برای ما بنویسید.

پرسش‌های رایج

برای بهینه‌سازی سرعت سایت حتما باید امتیاز ۱۰۰ بگیرم؟

نه. امتیاز ۹۰ به بالا سبز است و مهم‌تر از امتیاز، این است که سه عدد Core Web Vitals در محدوده‌ی خوب باشند. فاصله‌ی ۹۲ تا ۱۰۰ را بازدیدکننده تقریبا حس نمی‌کند؛ فاصله‌ی ۴۰ تا ۹۰ را حتما حس می‌کند.

چرا هر بار که تست می‌گیرم عدد فرق می‌کند؟

چون شرایط شبکه، بار سرور سایت و بار سرور تست هر لحظه کمی فرق دارد. نوسان چند واحدی طبیعی است. چند تست بگیرید و به روند نگاه کنید، نه به یک عدد.

آیا افزایش سرعت سایت ظاهر آن را عوض می‌کند؟

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

سریع شدن سایت چقدر رتبه‌ی گوگل را بالا می‌برد؟

هیچ‌کس نمی‌تواند عدد دقیقی قول بدهد. گوگل می‌گوید Core Web Vitals در رتبه‌بندی استفاده می‌شود، ولی محتوای مرتبط مقدم است. سرعت شانس شما را بیشتر می‌کند و بازدیدکننده‌ها را نگه می‌دارد؛ جای محتوای خوب را نمی‌گیرد.

سایت من وردپرس نیست؛ این راهنما به کارم می‌آید؟

بله. عکس، جاوااسکریپت، CSS، فونت، کش و سرور در همه‌ی سایت‌ها هستند. فقط ابزارها فرق می‌کنند: در وردپرس افزونه، در سایت‌های اختصاصی تنظیم خود کد و سرور.