میزبانی و عملکرد
چگونه WordPress را سریع میکنیم: LiteSpeed Enterprise، LSCache و Redis اختصاصی برای هر سایت
سریعترین درخواست WordPress درخواستی است که هرگز اجرا نمیشود — در اینجا نحوه پاسخگویی پشتهی ما به بیشتر بازدیدها از طریق حافظه پنهان پیش از فراخوانی PHP یا MySQL و معنای آن برای Core Web Vitals آورده شده است.
سریعترین درخواست، درخواستی است که هرگز اجرا نمیشود
یک درخواست استاندارد WordPress پرهزینه است. وبسرور کار را به PHP واگذار میکند، PHP سیستم WordPress را راهاندازی میکند، افزونهها را اجرا مینماید، دهها بار دیتابیس MySQL را استعلام میکند، HTML را سرهم میکند و تنها پس از آن بایتها را بازمیگرداند. در یک سایت شلوغ، این فرایند کامل برای هر بازدیدکننده تکرار میشود و این همان جایی است که تقریباً تمام زمان تا دریافت اولین بایت (time-to-first-byte) شما صرف آن میشود.
پاسخ ما این است که مطمئن شویم برای بیشتر بازدیدها، هیچکدام از اینها اصلاً اتفاق نیفتد. در سراسر وبسایتهایی که میزبانی میکنیم — بیش از ۱۰۰,۰۰۰ سایت PBN به همراه WordPress مدیریتشدهی استاندارد — اکثریت قاطع بازدیدهای صفحات فرانتاند به صورت یک صفحهی کامل از پیشرندر شده مستقیماً از کش ارائه میشوند، بدون اینکه PHP فراخوانی شود یا پایگاه داده لمس گردد. بقیهی این پست دربارهی نحوهی قرار گرفتن لایههایی است که این موضوع را ممکن میسازند و این که هر کدام چگونه جایگاه خود را به دست میآورند.
چهارچوب مهم این است که اینها کشهای رقیبی نیستند که یکی را انتخاب کنید. کش تمام صفحه، کش شیء و لبه CDN هر کدام دسته متفاوتی از درخواستها را پوشش میدهند و ارزش واقعی در نحوهٔ انتقال آنها به یکدیگر است.
LiteSpeed Enterprise + LSCache: لایه صفحه کامل
هر سایت روی LiteSpeed Enterprise با LSCache در سطح سرور اجرا میشود. هنگامی که پاسخ فرانتاند قابل کش باشد، وبسرور آن را با کنترل کش و هدرهای تگ LiteSpeed نشانهگذاری میکند و LiteSpeed صفحه کامل را مستقیماً در درخواست بعدی ارائه میدهد؛ هیچ فرآیند PHP ایجاد نمیشود و هیچ پرسوجوی MySQL اجرا نمیگردد. این بزرگترین اهرم منفرد روی TTFB در WordPress است، زیرا کل فرآیند راهاندازی اپلیکیشن را از مسیر اصلی حذف میکند.
از آنجا که LSCache به جای یک افزونه PHP در داخل وبسرور قرار دارد، کار خود را زودتر در چرخه حیات درخواست آغاز میکند و صفحات را به شکلی نگه میدارد که سرور بتواند فوراً آنها را ارسال کند. یک خزنده کش، صفحات محبوب را آماده نگه میدارد، بنابراین اولین بازدیدکننده پس از پاکسازی کش، کسی نیست که هزینه بازسازی صفحه را بپردازد. نتیجه، TTFB بهطور چشمگیری پایینتر و پایدارتر از یک کش صرفاً افزونهای است که روی یک استک عمومی نصب شده است، جایی که کش همچنان پشت PHP قرار دارد.
پلاگین کش سطح مخزن اختصاصی ما روی تمامی سایتها به صورت پیشفرض نصب شده و خودکار بهروزرسانی میشود و WordPress را از همان ابتدا به درستی به LSCache متصل میکند. روی یک مبدأ غیر از LiteSpeed، این پلاگین صرفاً هیچ هدر تمامصفحهای صادر نمیکند و کنار میرود، در حالی که کش شیء و قوانین استثنا به کار خود ادامه میدهند؛ بنابراین یک سایت مهاجرتکرده هرگز در وضعیتی معیوب و نیمهپیکربندیشده رها نمیشود.
حفظ سرعت بدون ارائه محتوای قدیمی: ESI و پاکسازی خودکار هوشمند
کشکردن تهاجمی تمام صفحات دارای دو حالت خرابی کلاسیک است: ارائه صفحه دیگران به کاربر واردشده به سیستم، و ارائه صفحهای که باید تغییر میکرده به هر کسی. هر دو مورد بهجای کاهش کشکردن، در لایه کش حل میشوند.
ESI (Edge Side Includes) به ما امکان میدهد صفحه را کش کنیم در حالی که برای بخشهایی که باید به صورت زنده بمانند حفره ایجاد میکنیم. در یک فروشگاه WooCommerce صفحات کاتالوگ، محصول و دستهبندی به صورت کش تمامصفحه برای سریعترین TTFB ممکن ارائه میشوند، در حالی که ESI قطعه سبد خرید، مجموع مینیسبد خرید و وضعیت حساب را به ازای هر درخواست رندر میکند. سبد خرید، پرداخت، حساب من و هر صفحه نانس یا نشستی به طور پیشفرض مستثنی میشوند. خریداران همیشه سبد خرید خود و یک صفحه پرداخت فعال را میبینند؛ همه افراد همچنان فروشگاه را از طریق کش دریافت میکنند.
تازگی محتوا توسط پاکسازی خودکار هوشمند مدیریت میشود. هوکهای پاکسازی بهطور خودکار هنگام تغییر محتوا، محصولات، قیمتها یا سفارشها فعال میشوند، بنابراین صفحات کششده مربوطه بهجای اتکا به تایمر، بلافاصله بهروز میشوند و همچنین میتوانید پاکسازی را بهصورت دستی از داشبورد یا داخل WordPress انجام دهید. پاکسازی مبتنیبر برچسب به این معنی است که ویرایش یک نوشته، همان نوشته و آرشیوهای آن را پاک میکند — نه کل کش — بنابراین یک ویرایش تکی باعث راهاندازی مجدد و سرد کل سایت نمیشود.
کشپد شیء Redis برای هر وبسایت: برای مواردی که نمیتوانند یک صفحه کامل باشند
همه درخواستها نمیتوانند یک صفحه کامل ایستا باشند. نشستهای کاربران واردشده، بخش مدیریت WordPress، سبدهای خرید WooCommerce، جستجو و قطعات پویایی که ESI باقی میگذارد، همگی باید PHP را اجرا کنند. برای آنها، هدف از «گذر از برنامه» به «گذر از پایگاه داده» تغییر میکند.
هر سایت کش شیء اختصاصی Redis خود را دریافت میکند. WordPress نتایج خوانشهای مکرر پایگاه داده — گزینهها، ترانزینتها، جستوجوی نوشتهها و دستهبندیها، دادههای محصول و نشست WooCommerce — را در حافظه کش میکند تا همان پرسوجو در هر بازدید روی MySQL اجرا نشود. این تأثیر دقیقا در جایی که کش تمامصفحه نمیتواند کمک کند بیشتر نمایان میشود: پیشخوانهای سریعتر، سبدهای خرید سریعتر و بار پایگاه داده بسیار کمتر در هنگام ترافیک.
کش اجسام برای هر سایت بهصورت مجزا است و اشتراکی ندارد، که این موضوع هم برای عملکرد و هم برای جداسازی اهمیت دارد. همراه با محدودسازی پایگاه داده برای هر سایت، درخواستهای سنگین یا ناایمن یک سایت نمیتواند منابع پایگاه داده را برای سایتهای همسایه دچار کمبود کند. شما میتوانید اطلاعات بیشتر درباره نحوه کارکرد این ساختار چندلایه را در صفحه ویژگیهای کش ما، و درباره مرزهای بین تننتها تحت جداسازی مطالعه کنید.
لبه و انتقال زیرین
حافظهای که روی سرور مبدأ قرار دارد، همچنان باید از شبکه عبور کند. لبه CDN در جلوی سرور قرار میگیرد تا داراییهای ثابت و صفحات قابل کش از یک نقطه حضور نزدیک به بازدیدکننده ارائه شوند و سرور مبدأ حتی زیر بار ترافیک نیز آرام بماند. برای سرویس میزبانی بدون فوتپرینت ما، همین لبه یک استخر multi-CDN توزیعشده بین چند ارائهدهنده است که علاوه بر عملکرد، هدف فوتپرینت را نیز برآورده میکند؛ در WordPress معمولی، این لبه صرفاً یک لایه سریع و با رفتار مناسب است که سرورهای مبدأ را بیکار نگه میدارد.
در زیر، از اصول اولیه چشمپوشی نشده است. سایتها روی فضای ذخیرهسازی NVMe با HTTP/3 اجرا میشوند، بنابراین بایتهایی که کش ارسال میکند از طریق یک انتقال مدرن و چندمفصلهای به همراه ذخیرهسازی سریع برای هر بار گم شدن کش میرسند. هیچیک از این لایهها یک افزودنی نیستند: LiteSpeed، LSCache، ردیس (per-site Redis)، NVMe و HTTP/3 پایه و اساس در هر طرح هستند، نه یک سطح ارتقای فروش.
عوامل واقعی تاثیرگذار بر Core Web Vitals
دقت در این زمینه بسیار اهمیت دارد، زیرا غالباً ادعاهای اغراقآمیزی درباره Core Web Vitals در حوزه میزبانی وب مطرح میشود. پارامتر TTFB بخشی از معادله است که سرور مسئول آن است و استشته کشینگ (caching stack) لایههای بالاتر باعث کاهش آن میشود؛ یک صفحه کامل کششده که از طریق HTTP/3 از لبه شبکه (edge) ارائه میشود، کمترین میزان ممکن برای TTFB را رقم میزند. از آنجا که TTFB آغازینترین بخش Largest Contentful Paint است، یک مبدأ (origin) سریع به تمام معیارهای پاییندستی مزیتی اولیه میدهد که در غیر این صورت به هیچوجه قابل دستیابی نیست.
اما معیارهای LCP، CLS و INP بیشتر در مرورگر و توسط خود صفحه تعیین میشوند: یک تصویر اصلی بهینهنشده، کدهای CSS و JavaScript مسدودکننده رندر، پوستهای که با بارگذاری فونتها و تبلیغات جابهجا میشود، و پردازش سنگین در ترد اصلی توسط افزونهها. هیچ میزان کش سروری نمیتواند یک تصویر اصلی ۲ مگابایتی یا پوستهای را که مگابایتها کد JavaScript ارسال میکند، اصلاح کند. میزبانی صادقانه، سهم سرور را عملاً رایگان و پایدار میسازد، و سپس این وظیفه سایت است که بخش فرانتاند را سبک نگه دارد.
این تقسیم کار همان مدل ذهنی مفید است. ما تضمین میکنیم که درخواست بهسرعت به مرورگر برسد و تحت بار ترافیک سریع باقی بماند؛ شما نیز حجم داده را کوچک و پایدار نگه میدارید. نقطهی تلاقی این دو — پیشگرمسازی حافظه پنهان (cache warm-up)، تحویل در لبه شبکه (edge delivery)، و پاسخگو نگه داشتن پایگاه داده تا صفحات پویا دچار وقفه نشوند — دقیقاً همان جایی است که زیرساخت ما برای آن تنظیم شده است، و همین ویژگی باعث میشود WordPress مدیریتشده روی این پلتفرم، سریعتر از همان سایت روی یک میزبانی عمومی باشد.
سوالات متداول
آیا هنوز به یک افزونه کش مانند WP Rocket نیاز دارم؟
خیر. کش تمامصفحه در وبسرور توسط LSCache در LiteSpeed مدیریت میشود و افزونه کش اختصاصی ما — که از قبل نصب شده و بهطور خودکار بهروزرسانی میشود — وردپرس (WordPress) را به درستی به آن متصل میکند، در حالی که یک کش شیء Redis مختص هر سایت در پشت آن قرار دارد. انباشتن یک افزونه کش تمامصفحه دوم روی آن معمولاً به جای کمک کردن، با کش سطح سرور تداخل پیدا میکند؛ بنابراین نیازی به آن نیست و توصیه نمیشود.
آیا کش کردن، سبد خرید WooCommerce یا صفحات کاربر واردشده را دچار مشکل میکند؟
خیر. سبد خرید، تسویهحساب، حساب من و هرگونه صفحه دارای nonce یا نشست به طور پیشفرض از کش مستثنی میشوند، و ESI قطعه سبد خرید و مجموعها را در صفحات دیگری که کش شدهاند به صورت زنده نگه میدارد. خریداران همیشه سبد خرید خود و یک تسویهحساب فعال را میبینند، در حالی که فروشگاه همچنان از روی کش بارگذاری میشود.
وقتی مطلبی را منتشر میکنم یا ویرایش میکنم، حافظه پنهان چگونه بهروز میماند؟
پاکسازی خودکار هوشمند روی قلابهای مربوط به WordPress اجرا میشود، بنابراین انتشار، ویرایش محتوا، یا تغییر یک محصول، قیمت یا سفارش، فقط همان صفحات آسیبپدید و آرشیوهای آنها را پاک میکند — نه کل کش را — و یک خزنده دوباره آنها را گرم میکند. همچنین میتوانید بر اساس تقاضا از داشبورد یا از داخل WordPress پاکسازی را انجام دهید.
آیا صرفِ هاستینگ میتواند Core Web Vitals بینقص را به من بدهد؟
این بهترین TTFB ممکن را به شما میدهد که سهم سرور است و امتیازی اولیه برای Largest Contentful Paint محسوب میشود. اما LCP، CLS و INP عمدتاً توسط خود صفحه تعیین میشوند — اندازههای تصویر، داراییهای مسدودکننده رندر، پایداری چیدمان و جاوا اسکریپت رشته اصلی. استک ما سهم سرور را سریع و پایدار میسازد؛ حفظ سبکی بار فرانتاند همان چیزی است که بقیه شکاف را پر میکند.
مرتبط
۱۴ روز رایگان امتحان کنید
اولین سایتهای خود را به مدت ۱۴ روز رایگان راه بیندازید — بدون نیاز به کارت. شبکهای موجود را منتقل میکنید؟ اولین مهاجرت با ما.
شروع رایگان