چرا سرعت سایتم پایینه و دیر لود میشه؟ (7 دلیل پنهان)

«چرا سرعت سایتم پایینه؟» اگر این سوال ذهن شما را درگیر کرده، احتمالا راه های رایج مثل ارتقای هاست و فشرده سازی عکس را امتحان کرده اید و هنوز نتیجه نگرفته اید. دلیلش ساده است: این کارها مثل یک مسکن برای یک بیماری جدی عمل می کنند. علائم را موقتا آرام می کنند، اما ریشه مشکل که در معماری کد و زیربنای فنی سایت شماست، دست نخورده باقی می ماند.

من به عنوان یک برنامه نویس با ۲۵ سال تجربه می نویسم که عادت دارم مستقیم به سراغ موتور اصلی سایت بروم. هدفم دادن راه حل نیست؛ بلکه دادن «قدرت تشخیص» است. در ادامه 7 دلیل پنهان و فنی را برایتان روشن می کنم تا دقیقا بفهمید مشکل واقعی کجاست و چرا راه حل های سطحی هرگز کافی نخواهند بود.

برای مطالعه بیشتر بخوانید: افزایش سرعت وب سایت با 14 تکنیک تضمینی

بخش اول: دلایل رایجی که همه می دانند (اما کافی نیستند)

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

۱. هاستینگ نامناسب: موتوری که نمی کشد

هاست شما، موتور سایت شماست. اگر یک سایت فروشگاهی سنگین را روی یک هاست اشتراکی ارزان قیمت گذاشته اید، مثل این است که انتظار داشته باشید یک موتور پراید، یک کامیون را در سربالایی بکشد، خب غیرممکن است. هاست اشتراکی یعنی منابع سرور (مثل قدرت پردازش و حافظه) بین ده ها یا صدها سایت دیگر تقسیم می شود. در اولین ترافیک سنگین، سایت شما به نفس نفس می افتد.

۲. تصاویر بهینه نشده: باری که حمل می کنید

هر تصویری که روی سایت آپلود می کنید، یک بار است که کاربر باید آن را دانلود کند. وقتی شما یک عکس ۵ مگابایتی را بدون فشرده سازی و تغییر سایز در صفحه محصول می گذارید، مثل این است که مشتری را مجبور کنید قبل از ورود به فروشگاه، یک کیسه سیمان ۵۰ کیلویی را روی دوشش بگیرد. واضح است که خسته می شود و برمی گردد. حجم بالای تصاویر مستقیما حجم کل صفحه (Page Weight) را بالا می برد و زمان لود را نابود می کند.

۳. عدم استفاده از سیستم کش: حافظه ای که وجود ندارد

وب سایت شما برای نمایش هر صفحه، باید کدهای زیادی را پردازش کند و اطلاعاتی را از دیتابیس فراخوانی کند. این کار انرژی و زمان می برد. سیستم کش (Cache) مثل یک حافظه کوتاه مدت برای سرور عمل می کند. یک نسخه آماده و «عکس برداری شده» از صفحه را نگه می دارد و به بازدیدکنندگان بعدی، همان نسخه آماده را نشان می دهد. بدون کش، سرور شما مجبور است برای هر بازدیدکننده، از صفر شروع به ساختن صفحه کند. این یعنی اتلاف منابع و زمان خالص.

برای مطالعه بیشتر حتما بخوانید: کشینگ (Caching) چیست و چگونه سرعت سایت را افزایش می دهد؟

بخش دوم: دلایل پنهان و ساختاری؛ چرا سایت شما واقعا کند است؟

خب، شما بنزین را چک کردید (هاست)، بار اضافه را خالی کردید (تصاویر) و حافظه کوتاه مدت را هم به کار انداختید (کش). اما ماشین هنوز راه نمی رود.

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

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

۱. بدهی فنی (Technical Debt): بدهی پنهانی که سرعت شما را می بلعد

«بدهی فنی» یکی از مهم ترین مفاهیم در دنیای برنامه نویسی است که مدیران کسب وکار باید آن را درک کنند.

تصور کنید می خواهید یک ساختمان اداری بسازید. برای اینکه سریع تر و ارزان تر تمام شود، به جای فونداسیون بتنی عمیق، از یک پی ریزی سطحی و مصالح درجه دو استفاده می کنید. ساختمان در ماه اول سرپاست و کار می کند. اما شش ماه بعد، وقتی می خواهید طبقه دوم را اضافه کنید، مهندس به شما می گوید این فونداسیون تحمل بار اضافه را ندارد. حالا چه کار باید بکنید؟ باید کل ساختمان را تخریب کنید و از اول با یک فونداسیون درست بسازید. هزینه ای که الان باید بپردازید، ده ها برابر بیشتر از صرفه جویی اولیه شماست. آن هزینه اضافه، «بدهی فنی» شماست.

در دنیای وب، استفاده از قالب های آماده وردپرس و نصب پشت سر هم افزونه ها برای اضافه کردن هر قابلیت کوچک، دقیقا مثل ساختن ساختمان با فونداسیون ضعیف است. در ابتدا سریع و آسان به نظر می رسد. اما هر افزونه، با خودش مجموعه ای از کدهای CSS و jаvascript، کوئری های دیتابیس و ساختارهای ناشناس را به سایت شما تحمیل می کند. شما فقط یک دکمه ی اشتراک گذاری می خواستید، اما در واقع کل کتابخانه کدنویسی یک توسعه دهنده دیگر را به سایتتان اضافه کرده اید.

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

۲. کوئری های دیتابیس: وقتی پایگاه داده شما نفس کم می آورد

پایگاه داده (Database) سایت شما، انبار اطلاعات شماست. تمام محصولات، نوشته ها، نظرات کاربران، اطلاعات سفارش ها، همه چیز آنجا ذخیره شده است. وقتی یک بازدیدکننده صفحه ای از سایت شما را باز می کند، سایت باید اطلاعات مورد نیاز آن صفحه را از این انبار درخواست کند. به هر کدام از این درخواست ها می گوییم یک کوئری (Query).

حالا یک سناریوی ساده را تصور کنید:

شما وارد یک انبار بزرگ می شوید و به انباردار می گویید: «لطفا محصول شماره ۱۲، رنگ آبی، سایز مدیوم را به من بدهید.» انباردار دقیقا می داند کجاست، می رود و در عرض ۱۰ ثانیه آن را برای شما می آورد. این یک کوئری بهینه است.

حالا همین سناریو در یک سایت وردپرسی پر از افزونه:

شما وارد انبار می شوید و به انباردار ۱۰ برگه درخواست مختلف می دهید که هر کدام توسط یک نفر دیگر نوشته شده و هیچ هماهنگی با هم ندارند:

• برگه اول: «هرچی محصول آبی داریم بیار.»
• برگه دوم: «لیست تمام کالاهای سایز مدیوم رو بده.»
• برگه سوم: «ببین محصول شماره ۱۲ اصلا موجوده؟»
• و هزاران درخواست پراکنده دیگر...

انباردار بیچاره باید برای هر درخواست، کل انبار را بگردد، لیست ها را با هم مقایسه کند و در نهایت، بعد از ۱۰ دقیقه تقلا، همان محصول شماره ۱۲ آبی مدیوم را به شما تحویل دهد.

این دقیقا کاری است که افزونه ها با دیتابیس شما می کنند. هر افزونه ای که نصب می کنید (اسلایدر، فرم تماس، پاپ آپ)، برای کار کردن نیاز به اطلاعاتی از دیتابیس دارد و شروع به ارسال کوئری های خودش می کند. این کوئری ها اغلب بهینه نیستند و برای یک کار ساده، کل دیتابیس را شخم می زنند. حالا تصور کنید ۱۰ افزونه همزمان در حال ارسال ۱۰ مدل کوئری مختلف باشند. دیتابیس شما به سرعت دچار تنگنای منابع (Bottleneck) می شود، نفس کم می آورد و سرعت لود کل سایت را با خودش پایین می کشد.

این مشکل، به خصوص در سایت های فروشگاهی که اطلاعات محصولات، موجودی و قیمت ها دائم در حال تغییر است، یکی از دلایل اصلی کندی های فاجعه بار در زمان ترافیک بالاست. مشکل از هاست شما نیست؛ مشکل از انبارداری است که آنقدر سرش شلوغ شده که دیگر توان پاسخگویی ندارد.

برای مطالعه بیشتر بخوانید: وردپرس یا کد نویسی اختصاصی: چرا کد نویسی بهتر است؟

۳. صفحه سازها (مثل المنتور): آیا راحتی Drag-and-Drop ارزش این همه کندی را دارد؟

بیایید صادق باشیم. صفحه سازها (Page Builders) مثل المنتور، ویژوال کامپوزر و ...، به یک دلیل مشخص محبوب شدند: آن ها به شما اجازه می دهند بدون یک خط کدنویسی، صفحات وب را به صورت بصری و با کشیدن و رها کردن (Drag-and-Drop) طراحی کنید. این قابلیت برای شروع کار، فوق العاده وسوسه انگیز است. اما این راحتی، یک هزینه پنهان و بسیار سنگین دارد: سرعت.

استفاده از یک صفحه ساز را اینطور تصور کنید:

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

صفحه سازها دقیقا همین کار را با سایت شما می کنند. آن ها باید با هر قالبی و هر افزونه ای سازگار باشند، بنابراین کتابخانه ی عظیمی از کدها را برای هر قابلیت قابل تصوری (اسلایدر، آکاردئون، گالری عکس، شمارنده متحرک) همیشه و در تمام صفحات بارگذاری می کنند؛ حتی اگر شما در یک صفحه فقط از یک تیتر ساده و یک پاراگراف متن استفاده کرده باشید.

این فاجعه به دو شکل خودش را نشان می دهد:

کد خروجی سنگین و کثیف (Bloated Code): برای ساختن یک تیتر ساده که در کدنویسی تمیز فقط یک خط است (<h2>My Title</h2>)، المنتور ممکن است ۷ لایه کد تودرتو (div) با ده ها کلاس مختلف تولید کند. این کد اضافی، حجم HTML صفحه را به شدت بالا می برد.

درخواست های HTTP متعدد: هر ویجت (Widget) در صفحه ساز، معمولا فایل های CSS و jаvascript مخصوص به خودش را بارگذاری می کند. صفحه ای که با ۱۰ ویجت مختلف ساخته شده، می تواند ۲۰ یا ۳۰ درخواست اضافه به سرور ارسال کند. این یعنی رفت وآمدهای متعدد و غیرضروری که سرور و مرورگر کاربر را خسته می کند.

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

۴. معماری ناکارآمد فرانت اند: کدهای JS و CSS که جلوی بارگذاری را می گیرند

فرانت اند (Front-end) یعنی هر چیزی که مرورگر کاربر شما باید آن را «نقاشی» کند تا سایت نمایش داده شود: ساختار (HTML)، ظاهر و استایل (CSS) و قابلیت های تعاملی (jаvascript). سرعت سایت شما به شدت به ترتیب و نحوه این نقاشی بستگی دارد.

سناریوی زیر را در نظر بگیرید:

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

این دقیقا کاری است که منابع Render-Blocking (مسدودکننده نمایش) با سایت شما می کنند.

به زبان ساده، وقتی مرورگر شروع به خواندن کد سایت شما می کند، به محض رسیدن به یک فایل CSS یا jаvascript بزرگ در بالای صفحه، کار اصلی خود یعنی «نقاشی کردن محتوای قابل مشاهده» را متوقف می کند. مرورگر می گوید:«صبر کن! اول باید تمام این فایل استایل و تمام این دستورات جاوا اسکریپت را دانلود و پردازش کنم، بعدا بهت نشان می دهم سایت چه شکلی است.»

مشکل اینجاست که قالب های آماده و افزونه ها، اغلب فایل های CSS و JS بسیار سنگینی را که برای قابلیت های غیرضروری (مثل انیمیشن های یک بخشی که در پایین صفحه قرار دارد) لازم است، همان اول کار بارگذاری می کنند. در نتیجه، کاربر شما برای چند ثانیه با یک صفحه کاملا سفید روبرو می شود، چون مرورگر در پس زمینه مشغول دانلود و پردازش کدهایی است که برای نمایش بخش اولیه سایت اصلا به آن ها نیازی نیست.

در یک معماری فرانت اند اصولی که ما در کدنویسی اختصاصی پیاده می کنیم، ترتیب کار کاملا متفاوت است. ما به مرورگر دستور می دهیم: «اول فقط کدهای CSS حیاتی برای رنگ کردن بخش بالایی صفحه را بارگذاری کن (تا کاربر فورا محتوا را ببیند). بقیه فایل های CSS و jаvascript سنگین را بعدا و در پس زمینه (Asynchronously) دانلود کن.» این یعنی نقاش شما اول دیوار اصلی را رنگ می کند و بعدا سر فرصت به سراغ خرید رنگ اتاق خواب ها می رود.

۵. اسکریپت های خارجی: آیا ابزارهای شما سرعت تان را قربانی می کنند؟

شما برای مدیریت بهتر کسب وکارتان، از ابزارهای مختلفی روی سایت خود استفاده می کنید: یک ابزار چت آنلاین برای پشتیبانی مشتریان (مثل رایچت)، یک سیستم آمار بازدید (Google Analytics)، یک ابزار تبلیغاتی برای ریتارگتینگ (مثلا یکتانت) و شاید یک نقشه گوگل در صفحه «تماس با ما». این ها ابزارهای فوق العاده ای هستند،

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

این موضوع را اینطور ببینید:

سایت شما، دفتر کار شماست. وقتی یک بازدیدکننده وارد دفتر شما (سایت) می شود، برای اینکه کارش راه بیفتد، شما باید سه نامه را از سه نقطه مختلف شهر توسط پیک دریافت کنید:

• پیک اول از شرکت چت آنلاین می آید.
• پیک دوم از دفتر گوگل می آید.
• پیک سوم از دفتر یکتانت.

بازدیدکننده شما در اتاق انتظار نشسته و تا زمانی که هر سه پیک نرسند و نامه ها را تحویل ندهند، کارش شروع نمی شود. حالا اگر پیک شرکت چت آنلاین در ترافیک گیر کند یا سرورهای یکتانت برای چند ثانیه کند عمل کنند، چه اتفاقی می افتد؟ بازدیدکننده شما معطل می شود. تقصیر شما یا دفتر شما نیست، اما در نهایت این مشتری شماست که تجربه بدی پیدا می کند.

هر کدام از این اسکریپت های خارجی (که به آن ها APIهای ثالث می گوییم) یک درخواست به سرورهای خارج از کنترل شما ارسال می کنند. مرورگر کاربر باید منتظر بماند تا پاسخ از آن سرورها برگردد. اگر شما ۵ ابزار خارجی روی سایت خود داشته باشید، مرورگر باید ۵ سفر رفت و برگشت به نقاط مختلف اینترنت داشته باشد. هر کدام از این سفرها می تواند با تاخیر مواجه شود و مستقیما سرعت بارگذاری سایت شما را کاهش دهد.

مشکل اینجاست که این ابزارها اغلب به صورت همزمان بارگذاری می شوند و برای منابع شبکه با هم رقابت می کنند. نتیجه این است که سایت شما ممکن است روی سرور خودتان در کسری از ثانیه لود شود، اما به خاطر منتظر ماندن برای پاسخ از سرورهای دیگران، کاربر نهایی آن را چندین ثانیه دیرتر ببیند.

۶. بی توجهی به موبایل: چرا کندی در موبایل نابودکننده سئو است؟

امروزه، اکثر بازدیدکنندگان شما (و از همه مهم تر، خودِ گوگل) سایت شما را اول با موبایل می بینند. اگر استراتژی سرعت شما فقط روی نسخه دسکتاپ متمرکز باشد، شما در حال مبارزه در یک جنگ اشتباهی هستید.

برای اینکه عمق فاجعه را درک کنید، باید با مفهوم Mobile-First Indexing آشنا شوید.

تصور کنید یک منتقد بسیار قدرتمند رستوران (گوگل) وجود دارد. این منتقد قبلا برای امتیاز دادن به رستوران شما، به سالن اصلی می آمد، روی میز می نشست و کیفیت سرویس دهی در محل (نسخه دسکتاپ) را می سنجید. اما از چند سال پیش، قانونش را عوض کرده. حالا، این منتقد فقط و فقط غذای بیرون بر (Take-out) شما را سفارش می دهد و تمام امتیازش را بر اساس همان تجربه ی بیرون بر (نسخه موبایل) ثبت می کند. دیگر برایش مهم نیست که سالن شما چقدر شیک است یا گارسون ها چقدر حرفه ای هستند. اگر غذا سرد، به هم ریخته و دیر به دستش برسد، شما یک امتیاز افتضاح می گیرید.

گوگل دقیقا همین کار را می کند. ربات های گوگل سایت شما را با یک شبیه ساز موبایل بررسی (Crawl) و رتبه بندی (Rank) می کنند. کند بودن سایت در موبایل دیگر فقط یک «تجربه کاربری بد» نیست؛ یک «سیگنال رتبه بندی منفی و مستقیم» برای سئو است.

برای مطالعه بیشتر بخوانید: مشکل نمایش سایت در موبایل (۵ دلیل اصلی + راه حل قطعی)

حالا چرا سرعت در موبایل معمولا بسیار بدتر است؟

• قدرت پردازش کمتر: پردازنده های موبایل ضعیف تر از لپ تاپ ها هستند.
• اینترنت ناپایدارتر: اینترنت سیم کارت (4G/5G) هرگز پایداری و سرعت یک اینترنت ثابت (Wi-Fi) را ندارد.

تمام آن مشکلات فنی که قبلا گفتیم (بدهی فنی، کدهای کثیف صفحه ساز، کوئری های سنگین) روی سخت افزار ضعیف تر و اینترنت کندتر، تاثیر چند برابری دارند. آن کیسه سیمان ۵۰ کیلویی (تصاویر سنگین) را حالا یک کودک (پردازنده موبایل) باید از پله ها بالا ببرد، نه یک کارگر قوی هیکل.

اگر سایت شما در موبایل کند است، از نظر گوگل کل سایت شما کند است؛ تمام شد.

۷. TTFB بالا: اولین سیگنال خطر از سمت سرور و کدنویسی شما

TTFB مخفف Time to First Byte (زمان تا دریافت اولین بایت) است. این شاید فنی ترین مفهومی باشد که تا الان مطرح کرده ایم، اما یکی از حیاتی ترین شاخص ها برای تشخیص سلامت سرور و کدنویسی شماست.

اجازه دهید با یک مثال ساده توضیح دهم:

شما به یک رستوران زنگ می زنید تا غذا سفارش دهید (مرورگر شما یک درخواست به سرور می فرستد). TTFB، مدت زمانی نیست که طول می کشد تا پیک غذا را به دست شما برساند. TTFB، مدت زمانی است که طول می کشد تا آشپزخانه سفارش شما را پردازش کند، آن را بفهمد و گوشی را بردارد و بگوید: «سفارش شما ثبت شد، شروع به آماده سازی می کنیم».

این زمان «انتظار اولیه» همه چیز را مشخص می کند. اگر آشپزخانه (سرور شما) شلوغ باشد، دستور پخت ها (کدنویسی شما) پیچیده و ناکارآمد باشند، یا مواد اولیه (اطلاعات دیتابیس) در انبار پخش وپلا باشند، این زمان اولیه طولانی می شود. شما پشت خط منتظر می مانید و نمی دانید اصلا کسی آن طرف هست یا نه.

TTFB بالا یک سیگنال خطر واضح است که می گوید مشکل از سمت سرور (Server-Side) است. یعنی قبل از اینکه حتی یک پیکسل از سایت شما برای کاربر ارسال شود، سرور شما در حال تقلا کردن است. این مشکل برخلاف سرعت دانلود، ربطی به اینترنت کاربر ندارد.

دلایل اصلی TTFB بالا چیست؟

• کدنویسی بک اند ناکارآمد: کدهای PHP شما برای جمع آوری اطلاعات یک صفحه، محاسبات سنگینی انجام می دهند.
• کوئری های دیتابیس پیچیده: همان مشکل انبارداری که قبلا گفتیم. سرور منتظر می ماند تا دیتابیس پاسخ یک درخواست پیچیده را بدهد.
• منابع محدود سرور: هاست شما منابع کافی برای پردازش سریع درخواست ها را ندارد.

ابزارهایی مثل GTmetrix این عدد را به شما نشان می دهند. TTFB بالا یعنی فونداسیون سایت شما مشکل دارد. شما می توانید نمای ساختمان (فرانت اند) را رنگ کنید، اما تا وقتی فونداسیون در حال نشست کردن است، ساختمان شما امن و سریع نخواهد بود.

جمع بندی: از درمان علائم به سراغ ریشه کن کردن بیماری بروید

اگر تا اینجای مقاله با من همراه بوده اید، حالا می دانید که کندی سایت یک مشکل سطحی نیست؛ یک علامت از بیماری عمیق تری مثل معماری ضعیف، بدهی فنی و زیربنای ناکارآمد کدنویسی است. راه حل های موقتی و مسکن ها دیگر جوابگو نیستند.

این مقاله یک ابزار تشخیص بود. حالا که ریشه واقعی مشکل را می شناسید، قدم بعدی انتخاب یک مسیر اصولی است. مسیری که در آن، وب سایت شما نه یک منبع دائمی استرس، بلکه یک ماشین قدرتمند و قابل اعتماد برای رشد کسب وکارتان باشد.

معرفی نویسنده:

حمید داستانی هستم متخصص طراحی سایت و کدنویسی موبایل با بیش از 25 سال سابقه.

هدف من این است که کسب و کارها در فضای آنلاین وب سایت یا اپلیکیشنی بی نظیر داشته باشند تا بتوانند درآمد بالایی کسب کنند.