چرا سایت من کند است؟ علت‌ها و راه‌حل‌ها

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

نمی‌توانید چیزی را که اندازه نگرفته‌اید رفع کنید، و 'کند به نظر می‌رسد' یک تشخیص نیست. PageSpeed Insights (pagespeed.web.dev) را باز کنید، URL خود را وارد کنید، و دو چیز را بخوانید: Core Web Vitals و متریک‌های آزمایشگاهی. روی تب موبایل تمرکز کنید، چون بیشتر بازدیدکنندگان روی تلفن هستند. سپس TTFB (Time To First Byte) را اندازه بگیرید — اینکه سرور شما چقدر طول می‌کشد تا اولین بایت را بفرستد — چون یک مشکل سرور را از یک مشکل تحویل جدا می‌کند.

اهداف سالم عبارت‌اند از LCP زیر ۲٫۵ ثانیه، INP زیر ۲۰۰ میلی‌ثانیه، CLS زیر ۰٫۱، و TTFB زیر حدود ۲۰۰ میلی‌ثانیه. اگر TTFB بالا باشد، گلوگاه سمت سرور است: هاستینگ، PHP یا دیتابیس. اگر TTFB خوب اما LCP بالا باشد، گلوگاه خود صفحه است — معمولاً تصاویر بزرگ و اینکه چقدر تا بازدیدکننده سفر می‌کنند. همین یک اندازه‌گیری به شما می‌گوید از کدام راه‌حل‌های زیر شروع کنید.

علت‌های واقعی یک سایت کند

بیشتر سایت‌های کند در چند علت مشترک‌اند. یک سرور کند یا هاستینگ اشتراکی شلوغ TTFB را پیش از بارگذاری حتی یک تصویر بالا می‌برد. صفحات سنگین بعد می‌آیند — تصاویر بزرگ‌بیش‌ازحد (معمولاً بزرگ‌ترین چیز روی یک صفحه)، قالب‌های پرحجم و page builderهایی که ده‌ها شیت استایل و اسکریپت عرضه می‌کنند. اسکریپت‌های شخص‌ثالث بیش از حد (ویجت‌های چت، heatmapها، ردیاب‌ها، فونت‌های اضافی) هرکدام یک درخواست اضافه و مانع رندر می‌شوند.

CSS و JavaScript مسدودکننده رندر اولین ترسیم را حتی وقتی سرور سریع است به تأخیر می‌اندازند. و فاصله مهم است: یک سرور واحد دور از بسیاری از بازدیدکنندگان شما به همه‌چیز تأخیر می‌افزاید، و یک هجوم ترافیک می‌تواند آن را از پا درآورد. تقریباً هر سایت کند ترکیبی از این‌هاست — کار تکراری سرور، دارایی‌های سنگین، اسکریپت‌های مسدودکننده و فاصله فیزیکی.

درک Core Web Vitals

Google تا حدی بر اساس Core Web Vitals رتبه می‌دهد، پس دانستن اینکه هرکدام چه چیزی را اندازه می‌گیرند کمک می‌کند. LCP (Largest Contentful Paint) یعنی محتوای اصلی — اغلب تصویر hero — چقدر طول می‌کشد تا ظاهر شود؛ بیشتر از همه از سرورهای کند و تصاویر سنگین و دور آسیب می‌بیند. INP (Interaction to Next Paint) یعنی صفحه چقدر سریع پاسخ می‌دهد وقتی بازدیدکننده‌ای ضربه می‌زند یا کلیک می‌کند؛ از JavaScript سنگینی که thread اصلی را مسدود می‌کند آسیب می‌بیند.

CLS (Cumulative Layout Shift) یعنی چیدمان هنگام بارگذاری چقدر جابه‌جا می‌شود؛ از تصاویر و تبلیغات بدون فضای رزروشده و از فونت‌هایی که دیر بار می‌شوند آسیب می‌بیند. رفع علت‌های بالا — تحویل سریع‌تر، تصاویر سبک‌تر، JavaScript کمتر و فضای رزروشده برای رسانه — دقیقاً همان چیزی است که این سه عدد را بهبود می‌دهد.

راه‌حل‌هایی که اعداد را جابه‌جا می‌کنند

به‌ترتیب تأثیر کار کنید. Cache: یک صفحه آماده به‌جای بازسازی آن در هر بازدید سرویس دهید — بزرگ‌ترین برد واحد برای TTFB و بار سرور. تصاویر: آن‌ها را به اندازه‌ای که نمایش داده می‌شوند تغییر اندازه دهید و فرمت‌های مدرن (WebP/AVIF) سرویس دهید، که معمولاً بیشترین وزن صفحه را دارند. اسکریپت‌ها: اسکریپت‌های شخص‌ثالثی را که نیاز ندارید حذف کنید و بقیه را defer کنید تا از مسدودکردن اولین ترسیم دست بردارند.

برای تصاویر و تبلیغات فضا رزرو کنید تا چیدمان جابه‌جا نشود (CLS بهتر)، و فونت‌ها را بدون مسدودکردن رندر بار کنید. سپس فاصله‌ای را که محتوای شما طی می‌کند با یک CDN کوتاه کنید. هر راه‌حل یک علت خاص را هدف می‌گیرد، و با هم LCP، INP و CLS را یک‌جا جابه‌جا می‌کنند.

یک CDN مشکل فاصله و هجوم را حل می‌کند

حتی پس از تنظیم سرور و صفحات، یک سرور فقط می‌تواند در یک مکان باشد. یک CDN فایل‌های ثابت شما را به سرورهای edge در سراسر جهان کپی می‌کند، تا هر بازدیدکننده از نزدیک‌ترین آن‌ها سرویس بگیرد — تأخیر کمتر و LCP پایین‌تر برای افراد دور از origin شما، به‌علاوه تاب‌آوری هنگام هجوم ترافیک چون edge بار را جذب می‌کند. تحویل مدرن (فشرده‌سازی Brotli، HTTP/2) و SSL خودکار، WAF و محافظت DDoS همراه آن می‌آیند.

cdn.com.tr این کار را بدون یک بازسازی انجام می‌دهد: دامنه خود را از مسیر CDN عبور دهید و edge شروع به cache و تحویل دارایی‌های شما از مکانی نزدیک هر بازدیدکننده می‌کند. صفحات پویا همچنان به‌طور عادی کار می‌کنند، گواهی‌ها خودشان را تمدید می‌کنند، و فاصله‌ای که به LCP شما آسیب می‌زد ناپدید می‌شود.

کجا سرعت بیشترین اهمیت را دارد