میزبانی و عملکرد
چگونه WordPress را سریع می‌کنیم: LiteSpeed Enterprise، LSCache و Redis اختصاصی برای هر سایت
سریع‌ترین درخواست WordPress درخواستی است که هرگز اجرا نمیشود — در اینجا نحوه پاسخگویی پشته ما به اکثر بازدیدها از حافظه پنهان پیش از فراخوانی PHP یا MySQL و مفهوم آن برای Core Web Vitals توضیح داده شده است.
سریع‌ترین درخواست، درخواستی است که هرگز اجرا نشود
یک درخواست استاندارد WordPress پرهزینه است. وبسرور فرایند را به PHP می‌سپارد، PHP برنامهٔ WordPress را راه‌اندازی میکند، افزونه‌ها را اجرا می‌نماید، چند ده بار از MySQL پرس‌وجو میکند، HTML را سرهم میکند و تنها پس از آن بایت‌ها را بازمی‌گرداند. در یک وب‌سایت شلوغ، کل این فرآیند برای هر بازدیدکننده رخ میدهد و تقریباً تمام زمان تا اولین بایت شما در همین مرحله صرف میشود.
پاسخ ما این است که اطمینان حاصل کنیم برای بیشتر بازدیدها، اصلاً هیچ‌یک از این اتفاقات رخ ندهد. در سرتاسر سایت‌هایی که میزبانی می‌کنیم — بیش از ۱۰۰,۰۰۰ سایت PBN به همراه WordPress مدیریت‌شده اصلی — بخش عمده‌ای از بازدیدهای صفحات فرانت‌اند به‌صورت یک صفحه کاملِ از پیش رندر شده و مستقیماً از حافظه موقت (کش) ارائه میشود، بدون اینکه PHP فراخوانی شود یا به پایگاه داده دسترسی پیدا کند. بقیه این مطلب به این موضوع می‌پردازد که لایه‌های محقق‌کننده این امر چگونه در کنار هم قرار می‌گیرند و هر یک جایگاه خود را چگونه به دست می‌آورند.
نکته کلیدی این است که این حافظه‌های پنهان رقیب یکدیگر نیستند که بخواهید از بین آنها یکی را انتخاب کنید. حافظه پنهان کامل صفحه، حافظه پنهان شیء و لبه CDN هر کدام دسته متفاوتی از درخواست‌ها را مدیریت میکنند و ارزش واقعی در نحوه واگذاری کارها از یکی به دیگری نهفته است.
LiteSpeed Enterprise + LSCache: لایه تمام‌صفحه
هر سایت بر روی LiteSpeed Enterprise همراه با LSCache در سطح سرور اجرا میشود. هنگامی که یک پاسخ فرانت‌اند قابل ذخیره در حافظه پنهان باشد، وبسرور آن را با هدرهای LiteSpeed cache-control و تگ نشانه‌گذاری میکند و LiteSpeed در بازدید بعدی، کل صفحه را مستقیماً تحویل میدهد — هیچ فرآیند PHP ایجاد نمیشود و هیچ کوئری MySQL ارسال نمی‌گردد. این بزرگ‌ترین اهرم منفرد بر روی TTFB در WordPress است، زیرا کل فرآیند راه‌اندازی برنامه را از مسیر بحرانی حذف میکند.
از آنجا که LSCache بهجای افزونه PHP درون وبسرور قرار دارد، کار خود را در مرحله‌ای زودهنگام‌تر از چرخه حیات درخواست آغاز میکند و صفحات را در قالبی نگه میدارد که سرور بتواند آنها را فوراً پاکسازی کند. یک خزنده کش (crawler) صفحات محبوب را آماده نگه میدارد، بنابراین نخستین بازدیدکننده پس از پاکسازی ناچار به پرداخت هزینه زمانی برای بازتولید صفحه نخواهد بود. نتیجه، TTFB به مراتب پایین‌تر و پایدارتری نسبت به کش صرفاً مبتنی بر افزونه است که به یک پشته عمومی اضافه شده باشد، جایی که کش همچنان پشت PHP قرار دارد.
افزونه کش سطح مخزن اختصاصی ما به‌صورت از پیش نصب‌شده و با بهروزرسانی خودکار روی هر سایت ارائه میشود و WordPress را از همان ابتدا بهدرستی به LSCache متصل میکند. در مبدأیی غیر از LiteSpeed، این افزونه به‌سادگی هیچ سرآیند صفحه کاملی ارسال نمی‌کند و مداخله‌ای انجام نمی‌دهد، در حالی که کش شیء و قوانین استثنا به کار خود ادامه می‌دهند — بنابراین یک سایت انتقال‌یافته هرگز در وضعیت خراب و نیمه‌پیکربندی‌شده باقی نمی‌ماند.
حفظ سرعت بدون ارائه محتوای قدیمی: ESI و پاکسازی خودکار هوشمند
حافظه پنهان تهاجمی تمام صفحه دو حالت خرابی کلاسیک دارد: ارائه صفحه کاربری دیگر به یک کاربر واردشده، و ارائه صفحه‌ای به هر کاربر که باید تغییر می‌کرد. هر دو مشکل در لایه حافظه پنهان حل میشوند، نه با کمتر کردن استفاده از آن.
فناوری ESI (Edge Side Includes) به ما امکان میدهد صفحه را کش کنیم و هم‌زمان بخش‌هایی را که باید زنده باقی بمانند، مستثنی نگه داریم. در یک فروشگاه WooCommerce، صفحات کاتالوگ، محصول و دسته‌بندی برای دستیابی به سریع‌ترین TTFB ممکن به‌صورت کش تمام‌صفحه ارائه میشوند، در حالی که ESI بخش سبد خرید، مجموع مینی‌کارت و وضعیت حساب کاربری را به ازای هر درخواست پردازش میکند. صفحات سبد خرید، تسویهحساب، حساب من و هرگونه صفحات nonce یا جلسه بهطور پیشفرض مستثنی هستند. خریداران همواره سبد خرید اختصاصی خود و یک فرایند تسویهحساب فعال را مشاهده میکنند؛ و همگی کماکان ویترین فروشگاه را از حافظه کش دریافت می‌نمایند.
تازه‌سازی محتوا توسط پاکسازی خودکار هوشمند مدیریت میشود. قلابهای پاکسازی با تغییر محتوا، محصولات، قیمت‌ها یا سفارش‌ها بهطور خودکار فعال میشوند، بنابراین صفحات ذخیره‌شده مرتبط در حافظه پنهان بهجای زمان‌سنج فوراً بازخوانی میشوند و شما همچنین میتوانید بر حسب تقاضا از پیشخوان یا از داخل WordPress اقدام به پاکسازی کنید. پاکسازی مبتنی بر برچسب به این معنی است که ویرایش یک نوشته فقط همان نوشته و بایگانی‌های آن را پاک میکند — نه کل حافظه پنهان را — بنابراین یک ویرایش تکی باعث راه‌اندازی سرد (cold-start) کل سایت نمیشود.
حافظه پنهان شیء Redis برای هر سایت: برای آنچه نمی‌تواند یک صفحه کامل باشد
هر درخواستی نمی‌تواند یک صفحه کامل ایستا باشد. نشست‌های واردشده، مدیریت WordPress، سبدهای خرید WooCommerce، جستجو و قطعات پویایی که ESI فعال باقی می‌گذارد، همگی باید PHP را اجرا کنند. برای آنها، هدف از «نادیده گرفتن برنامه» به «نادیده گرفتن پایگاه داده» تغییر میکند.
هر سایت حافظه پنهان اشیاء اختصاصی Redis خود را دریافت میکند. WordPress نتایج خواندن‌های مکرر پایگاه داده — گزینه‌ها، داده‌های گذرا (transients)، جستجوهای نوشته‌ها و اصطلاحات، و داده‌های محصول و نشست‌های WooCommerce — را در حافظه ذخیره میکند تا در هر بازدید، پرس‌وجوی تکراری روی MySQL اجرا نشود. اثر این ویژگی دقیقاً در جایی که کش کامل صفحه کمکی نمی‌کند به وضوح دیده میشود: پیشخوان‌های سریع‌تر، سبدهای خرید سریع‌تر و بار بسیار کمتر روی پایگاه داده هنگام ترافیک بالا.
حافظه پنهان اشیاء به ازای هر سایت مجزاست و به اشتراک گذاشته نمیشود؛ امری که هم برای کارایی و هم برای جداسازی حائز اهمیت است. در ترکیب با کنترل مصرف دیتابیس برای هر سایت، کوئری‌های سنگین یا نادرست یک سایت نمی‌تواند دیتابیس را برای همسایگان با کمبود منابع مواجه کند. میتوانید درباره نحوه هماهنگی کل این ساختار چندلایه در صفحه ویژگی‌های حافظه پنهان ما، و درباره مرزهای میان مشترکان در بخش جداسازی اطلاعات بیشتری مطالعه فرمایید.
لبه و لایه انتقال زیرین
حافظه پنهانی که روی سرور مبدا قرار دارد، همچنان باید از شبکه عبور کند. لبه شبکه توزیع محتوا (CDN) در مقابل سرور قرار می‌گیرد، بنابراین داراییهای استاتیک و صفحات قابل ذخیرهسازی از نزدیک‌ترین نقطه حضور به بازدیدکننده ارائه میشوند و سرور مبدا حتی زیر بار ترافیکی نیز آرام میماند. برای پلن‌های میزبانی بدون ردپا (footprint-free) ما، همین لبه شبکه‌ای از چندین ارائه‌دهنده CDN توزیع‌شده است که علاوه بر بهبود عملکرد، به هدف حذف ردپای سئو نیز خدمت میکند؛ در WordPress معمولی، این لایه صرفاً لایه‌ای سریع و کارآمد است که سرورهای مبدا را در حالت آماده‌باش و خلوت نگه میدارد.
در زیرساخت، در موارد اساسی کوتاهی نشده است. سایت‌ها روی فضای ذخیرهسازی NVMe با پروتکل HTTP/3 اجرا میشوند، بنابراین بایت‌هایی که حافظه پنهان ارسال میکند از طریق یک انتقال مدرن و چندگانه، به همراه حافظه ذخیرهسازی پرسرعت در صورت بروز هرگونه عدم تطابق با حافظه پنهان (cache miss)، منتقل میشوند. هیچ‌یک از این لایه‌ها یک افزونه جانبی نیستند: LiteSpeed، LSCache، قابلیت Redis اختصاصی برای هر سایت، NVMe و HTTP/3 پایه اصلی هر طرح هستند، نه یک سطح برای ارتقای فروش.
چه چیزی واقعاً Core Web Vitals را تغییر میدهد
ارزش دارد که دقیق باشیم، زیرا هاستینگ اغلب در رابطه با Core Web Vitals بیش از حد بزرگ‌نمایی میشود. TTFB بخشی از این معادله است که سرور کنترل آن را در دست دارد، و پشتهٔ کش ارائه‌شده در بالا همان چیزی است که آن را کاهش میدهد — یک صفحهٔ کاملِ کش‌شده که از طریق HTTP/3 از لبه ارائه میشود، تقریباً کمترین مقداری است که TTFB میتواند به آن برسد. از آنجا که TTFB لبهٔ آغازینِ Largest Contentful Paint است، یک مبدأ سریع به هر متریکِ بعدی یک مزیت پیشتاز میدهد که در غیر این صورت دستیابی به آن ممکن نیست.
اما LCP، CLS و INP عمدتاً در مرورگر و توسط خود صفحه تعیین میشوند: یک تصویر اصلی (hero) بهینه‌سازی‌نشده، کدهای CSS و JavaScript مسدودکننده رندر، چیدمانی که هم‌زمان با بارگذاری فونت‌ها و تبلیغات جابه‌جا میشود، و پردازش سنگین رشته اصلی (main-thread) ناشی از افزونه‌ها. هیچ مقداری از حافظه پنهان سرور (server caching) نمی‌تواند یک تصویر ۲ مگابایتی یا قالبی را که چندین مگابایت کدهای JavaScript ارسال میکند، برطرف سازد. یک میزبانی صادقانه نقش سرور را عملاً ناچیز و پایدار میکند؛ پس از آن، حفظ سبکی بخش کاربری (front end) بر عهده خود سایت است.
این تقسیم کار، الگوی ذهنی مفیدی است. ما تضمین می‌کنیم که درخواست به سرعت به مرورگر برسد و تحت بار ترافیک نیز سریع باقی بماند؛ شما حجم داده‌ها را کم و پایدار نگه می‌دارید. جایی که این دو به هم می‌رسند — گرم کردن حافظه پنهان، تحویل در لبه شبکه (Edge) و پاسخگو نگه داشتن پایگاه داده تا صفحات پویا متوقف نشوند — دقیقاً نقطه‌ای است که زیرساخت فنی ما برای آن بهینه‌سازی شده است، و همین امر باعث میشود WordPress مدیریت‌شده در این پلتفرم سریع‌تر از همان سایت در یک هاست معمولی باشد.
پرسش‌های متداول
آیا هنوز به یک افزونه کش مانند WP Rocket نیاز دارم؟
خیر. کش کامل صفحه در وبسرور توسط LSCache متعلق به LiteSpeed انجام میشود و افزونه کش اختصاصی ما — که از پیش نصب شده و بهطور خودکار بهروزرسانی میشود — WordPress را بهدرستی به آن متصل میکند و یک کش شیء Redis برای هر سایت نیز در پشت آن قرار دارد. قرار دادن یک افزونه دوم برای کش کامل صفحه معمولاً بهجای کمک کردن، با کش در سطح سرور تداخل ایجاد میکند، بنابراین نیازی به آن نیست و توصیه نمیشود.
آیا ذخیرهسازی در حافظه پنهان (کش) سبد خرید WooCommerce یا صفحات کاربران واردشده من را دچار مشکل میکند؟
خیر. سبد خرید، تسویهحساب، my-account و هرگونه صفحه دارای nonce یا نشست بهطور پیشفرض از حافظه پنهان مستثنی هستند و ESI بخشهای سبد خرید و مبالغ کل را در صفحاتی که در غیر این صورت در حافظه پنهان ذخیره میشوند، زنده نگه میدارد. خریداران همیشه سبد خرید اختصاصی خود و یک فرایند تسویهحساب فعال را مشاهده میکنند، در حالی که ویترین فروشگاه همچنان از حافظه پنهان بارگیری میشود.
هنگامی که مطلبی را منتشر یا ویرایش میکنم، حافظه پنهان چگونه بهروز میماند؟
پاکسازی خودکار هوشمند روی قلابهای مرتبط WordPress اجرا میشود، بنابراین انتشار، ویرایش محتوا، یا تغییر محصول، قیمت یا سفارش فقط صفحات متأثر و آرشیوهای آنها را پاک میکند — نه کل حافظه پنهان را — و یک خزنده دوباره آنها را گرم میکند. همچنین میتوانید بر حسب تقاضا از پیشخوان یا از درون WordPress پاکسازی را انجام دهید.
آیا هاستینگ به تنهایی میتواند Core Web Vitals بینقصی به من ارائه دهد؟
این به شما بهترین TTFB ممکن را میدهد که سهم سرور و یک مزیت اولیه برای Largest Contentful Paint است. اما LCP، CLS و INP عمدتاً توسط خود صفحه تعیین میشوند — اندازه تصاویر، داراییهای مسدودکننده رندر، ثبات چیدمان و جاوا اسکریپت رشته اصلی. مجموعه فناوری ما سهم سرور را سریع و یکنواخت میکند؛ سبک نگه داشتن بار بخش کاربری چیزی است که شکاف باقیمانده را جبران میکند.
مرتبط
به مدت ۱۴ روز رایگان امتحان کنید
اولین سایت‌های خود را به مدت ۱۴ روز رایگان راه‌اندازی کنید — بدون نیاز به کارت. قصد انتقال یک شبکه موجود را دارید؟ مهاجرت‌ها رایگان و نامحدود هستند.
رایگان شروع کنید