Хостинг и производителност
Как правим WordPress бърз: LiteSpeed Enterprise, LSCache и per-site Redis
Най-бързата заявка към WordPress е тази, която никога не се изпълнява – ето как нашият стек обслужва повечето посещения от кеша, преди изобщо да бъдат извикани PHP или MySQL, и какво означава това за Core Web Vitals.
Най-бързата заявка е тази, която никога не се изпълнява
Една стандартна заявка към WordPress е тежка. Уеб сървърът предава задачата на PHP, PHP зарежда WordPress, стартира плъгините, прави десетки заявки към MySQL, сглобява HTML и едва тогава изпраща данните обратно. При нает сайт цялото това изпълнение се повтаря за всеки посетител и именно там отива почти цялото време до първи байт (time-to-first-byte).
Нашият отговор е да гарантираме, че при повечето посещения нищо от това изобщо не се случва. В сайтовете, които хостваме — над 100 000 PBN сайта плюс обичайният управляван WordPress — огромното мнозинство от показванията на страници в челния интерфейс се обслужват като предварително рендирана цяла страница директно от кеша, без да се извиква PHP или да се докосва базата данни. Останалата част от тази публикация е за това как слоевете, които правят това възможно, си пасват и къде всеки от тях заслужава мястото си.
Важната рамка е, че това не са конкуриращи се кешове, между които да избирате. Кеширането на цели страници, обектовият кеш и CDN edge кешът прихващат различни класове заявки и стойността се крие в начина, по който те си прехвърлят работата един на друг.
LiteSpeed Enterprise + LSCache: слой за пълни страници
Всички сайтове работят на LiteSpeed Enterprise със сървърен LSCache. Когато отговорът на фронтенда може да бъде кеширан, уеб сървърът го маркира със заглавки cache-control и tag на LiteSpeed, а LiteSpeed обслужва цялата страница директно при следващото заявлено посещение — без стартиране на PHP процес и без изпълнение на MySQL заявка. Това е най-мощният лост за WordPress TTFB, тъй като премахва цялото зареждане на приложението от критичния път.
Тъй като LSCache работи вътре в уеб сървъра, а не в PHP плъгин, той започва да функционира по-рано в жизнения цикъл на заявката и съхранява страниците във формат, който сървърът може да изведе незабавно. Обхождащото устройство за кеш поддържа популярните страници заредени, така че първият посетител след изчистване на кеша да не е този, който плаща цената за регенерирането на страницата. Резултатът е осезаемо по-нисък и по-постоянен TTFB в сравнение с кеш, базиран единствено на плъгин и добавен към общ стек, където кешът все още се намира зад PHP.
Нашият кеш плъгин от репозиторен клас се доставя предварително инсталиран и с автоматични актуализации на всеки сайт, като свързва WordPress към LSCache правилно още от първия ден. При източник, който не е LiteSpeed, той просто не извежда хедъри за цялата страница и се оттегля, докато обектовият кеш и правилата за изключения продължават да си вършат работата — така че мигрираният сайт никога не остава в счупено, полуконфигурирано състояние.
Оставате бързи, без да сервирате старо съдържание: ESI и интелигентно автоматично изчистване
Агресивното кеширане на цяла страница има два класически режима на повреда: показване на страницата на някой друг на потребител, който е влязъл в системата, и показване на всекиго на страница, която е трябвало да се промени. И двата проблема се решават на ниво кеширане, а не чрез намаляване на кеширането.
ESI (Edge Side Includes) ни позволява да кешираме страницата, докато правим изключения за частите, които трябва да останат динамични. В магазин с WooCommerce страниците на каталога, продуктите и категориите се обслужват като цялостен кеш за възможно най-бърз TTFB, докато ESI рендира фрагмента на количката, общите суми на мини количката и състоянието на акаунта за всяка заявка. Количката, плащането, моят акаунт и всички страници с nonce или сесия се изключват по подразбиране. Купувачите винаги виждат собствената си кошница и работещо плащане, като същевременно всички получават витрината от кеша.
Свежестта се управлява от интелигентно автоматично изчистване. Хуковете за изчистване се задействат автоматично при промяна на съдържание, продукти, цени или поръчки, така че съответните кеширани страници се опресняват незабавно, а не по таймер, и можете също да извършвате ръчно изчистване от таблото за управление или от WordPress. Базираното на тагове изчистване означава, че редактирането на една публикация изчиства нея и нейните архиви — а не целия кеш — така че една единствена корекция не нулира кеша на целия сайт.
Обектен кеш Redis за отделен сайт: за това, което не може да бъде цяла страница
Не всяка заявка може да бъде статична цяла страница. Влезлите в системата сесии, администраторският панел на WordPress, количките в WooCommerce, търсенето и динамичните фрагменти, оставени от ESI, трябва да изпълняват PHP. За тях целта се променя от „пропускане на приложението“ на „пропускане на базата данни“.
Всеки сайт получава собствен посветен Redis обектен кеш. WordPress кешира резултатите от повтарящи се четения от базата данни — опции, transient записи, справки за публикации и термини, WooCommerce продуктови и сесийни данни — в паметта, така че същата заявка да не се изпълнява към MySQL при всяко зареждане. Ефектът е най-видим точно там, където кеширането на цяла страница не може да помогне: по-бързи контролни панели, по-бързи колички и значително по-ниско натоварване на базата данни при трафик.
Кеширането на обекти е за отделни сайтове, а не споделено, което е от значение както за производителността, така и за изолацията. В комбинация с ограничаването на заявките към базата данни за всеки сайт поотделно, тежките или лошо написани заявки на един сайт не могат да лишат съседните сайтове от ресурс на базата данни. Можете да прочетете повече за това как цялата многослойна настройка работи заедно на нашата страница с функции за кеширане, както и за границите между наемателите при изолацията.
Ръбът и транспортът под него
Кешът, който се намира на оригиналния сървър, все още трябва да пресече мрежата. Пред сървъра е разположен CDN edge, така че статичните ресурси и кешираните страници се обслужват от точка на присъствие близо до посетителя, а оригиналният сървър остава тих дори при натоварване. За нашата линия хостинг без следи същият edge представлява мулти-CDN пул, разпределен между няколко доставчици, който обслужва цел, свързана със SEO следите, както и с производителността; при масовия WordPress той е просто бърз, добре работещ слой, който поддържа оригиналните сървъри неактивни.
Под тях основните компоненти не са пренебрегнати. Сайтовете работят върху NVMe памет с HTTP/3, така че байтовете, които кешът изпраща, пристигат чрез модерен, мултиплексен транспорт с бързо съхранение зад всеки пропуск в кеша. Нито един от тези слоеве не е допълнение: LiteSpeed, LSCache, Redis за всеки сайт, NVMe и HTTP/3 са базовото ниво във всеки план, а не надграждащо стъпало.
Какво всъщност движи Core Web Vitals
Заслужава си да бъдем прецизни, тъй като хостингът често се предлага с преувеличени обещания относно Core Web Vitals. TTFB е частта от уравнението, която е отговорност на сървъра, а кеширащият стек отгоре е това, което го намалява – кеширана пълна страница, доставена през HTTP/3 от ръба (edge), е приблизително толкова ниска, колкото може да бъде стойността на TTFB. Тъй като TTFB е водещият компонент на Largest Contentful Paint, бързият източник дава на всеки следващ метричен показател преднина, която иначе не би могъл да има.
Но LCP, CLS и INP се определят най-вече в браузъра, от самите страници: неоптимизирано основно изображение, блокиращ рендерирането CSS и JavaScript, оформление, което се измества при зареждане на шрифтове и реклами, и тежка работа на основния поток от плъгини. Никакъв сървърен кеш няма да оправи 2 MB основно изображение или тема, която зарежда мегабайти JavaScript. Коректният хостинг прави приноса на сървъра практически свободен и постоянен, а след това от самия сайт зависи да поддържа фронтенда лек.
Това разделение на труда е полезен ментален модел. Ние гарантираме, че заявката достига до браузъра бързо и остава бърза при натоварване; вие поддържате полезния товар малък и стабилен. Мястото, където двете се срещат — загряване на кеша, доставка от edge сървъри и поддържане на базата данни отзивчива, така че динамичните страници да не забавят — е точно там, където нашият стек е оптимизиран, и именно това прави управлявания WordPress на тази платформа по-бърз в сравнение със същия сайт при стандартен хост.
Често задавани въпроси
Все още ли ми е необходим кеширащ плъгин като WP Rocket?
Не. Кеширането на цялата страница се управлява на уеб сървъра от LSCache на LiteSpeed, а нашият собствен софтуерен кеш модул – предварително инсталиран и автоматично обновяван – свързва правилно WordPress с него, като зад него работи обектен кеш с Redis за всеки сайт. Добавянето на втори софтуерен кеш модул за цялата страница обикновено си противоречи с кеша на ниво сървър, вместо да помага, затова то не е необходимо и не се препоръчва.
Ще спре ли кеширането да работи моята WooCommerce кошница или страници за влезли потребители?
Не. Количката, страницата за плащане, потребителският профил и всички страници с nonce или сесии се изключват от кеша по подразбиране, а ESI поддържа фрагмента на количката и общите суми актуални на страници, които иначе се кешират. Потребителите винаги виждат собствената си количка и работеща страница за плащане, докато витрината продължава да се зарежда от кеша.
Как се поддържа кешът актуален, когато публикувам или реферирам?
Интелигентното автоматично изчистване се задейства при съответните хукове на WordPress, така че публикуването, редактирането на съдържание или промяната на продукт, цена или поръчка изчиства само засегнатите страници и техните архиви – а не целия кеш – и обхождащ робот ги загрява отново. Можете също така да изчиствате при поискване от таблото за управление или отвътре в WordPress.
Самоят хостинг ли може да ми осигури перфектни Core Web Vitals?
Тя ви дава възможно възможно най-добър TTFB, който е делът на сървъра и преднина за Largest Contentful Paint. Но LCP, CLS и INP се определят в голяма степен от самите страници — размери на изображенията, блокиращи рендирането ресурси, стабилност на оформлението и JavaScript на главния нишки. Нашият стек прави приноса на сървъра бърз и постоянен; поддържането на фронтенд полезния товар лек е това, което затваря останалата част от разликата.
Свързани
Пробвайте безплатно за 14 дни
Стартирайте първите си сайтове безплатно за 14 дни — без карта. Премествате съществуваща мрежа? Първата ви миграция е за наша сметка.
Започни безплатно