Хостинг и производителност
Как правим WordPress бърз: LiteSpeed Enterprise, LSCache и Redis за всеки сайт
Най-бързата WordPress заявка е тази, която никога не се изпълнява — ето как нашият стек обслужва повечето посещения от кеша, преди изобщо да бъдат извикани PHP или MySQL, и какво означава това за Core Web Vitals.
Най-бързата заявка е тази, която никога не се изпълнява
Стандартната заявка към WordPress е ресурсноелементна и скъпа. Уеб сървърът предава заявката на PHP, PHP зарежда WordPress, изпълнява разширенията, прави няколко десетки заявки към MySQL, генерира HTML и едва тогава изпраща обратно байтове. При натоварен сайт целият този процес се изпълнява за всеки посетител и именно там отива почти цялото Ви време до първия байт.
Нашият отговор е да се уверим, че при повечето посещения нищо от това изобщо не се случва. В сайтовете, които хостваме — над 100 000 PBN сайта плюс стандартен управляван WordPress — огромната част от прегледите на страници в потребителския интерфейс се обслужват като предварително рендирана цяла страница директно от кеша, без да се задейства PHP или да се засяга базата данни. Останалата част от тази публикация е посветена на това как слоевете, които правят това възможно, си пасват и къде всеки един от тях заслужава своето място.
Важното уточнение е, че това не са конкуриращи се кешове, между които да избирате. Кешът за цели страници, кешът за обекти и CDN edge улавят различен клас заявки, а стойността се състои в начина, по който те си предават заявките един на друг.
LiteSpeed Enterprise + LSCache: слоят за пълно странициране
Всеки сайт работи на LiteSpeed Enterprise със сървърно ниво LSCache. Когато отговорът на фронтенда може да бъде кеширан, уеб сървърът го маркира със заглавки за LiteSpeed cache-control и тагове, а LiteSpeed доставя цялата страница директно при следващото посещение — не се стартира PHP процес, не се отправя MySQL заявка. Това е най-големият фактор за WordPress TTFB, тъй като премахва изцяло зареждането на приложението от критичния път.
Тъй като LSCache работи директно в уеб сървъра, а не в PHP плъгин, той се задейства по-рано в жизнения цикъл на заявката и съхранява страниците във вид, позволяващ на сървъра незабавното им изчистване. Обхождащ модул (crawler) за кеша поддържа популярните страници заредени, така че първият посетител след изчистване не е този, който понася забавянето при повторното им генериране. Резултатът е значително по-ниско и по-стабилно TTFB в сравнение с кеш, базиран единствено на плъгин и добавен към стандартна среда, където кешът продължава да функционира зад PHP.
Нашият собствен плъгин за кеширане от ниво хранилище се предоставя предварително инсталиран и с автоматично обновяване на всеки сайт, свързвайки правилно WordPress с LSCache още от самото начало. На източник, различен от LiteSpeed, той просто не излъчва заглавки за цели страници и не пречи на работата, докато обектният кеш и правилата за изключения продължават да функционират — така че мигрираният сайт никога не остава в счупено, полуконфигурирано състояние.
Поддържане на висока скорост без сервиране на остаряло съдържание: ESI и интелигентно автоматично изчистване
Агресивното кеширане на цели страници има два класически режима на срив: предоставяне на страницата на друг потребител на влязъл в профила си потребител и предоставяне на страница, която е трябвало да бъде променена, на когото и да било. И двата се решават на ниво кеширане, а не чрез по-малко кеширане.
ESI (Edge Side Includes) ни позволява да кешираме страницата, като същевременно оставяме отвори за частите, които трябва да останат динамични. В магазин на WooCommerce страниците на каталога, продуктите и категориите се зареждат като кеш на цялата страница за възможно най-бързо TTFB, докато ESI визуализира фрагмента на количката, междинните суми в мини количката и състоянието на акаунта за всяка заявка. Количката, поръчката, моят акаунт и всички nonce или сесийни страници са изключени по подразбиране. Купувачите винаги виждат собствената си кошница и работеща поръчка; всеки все пак получава витрината на магазина от кеша.
Актуалността се управлява чрез интелигентно автоматично изчистване. Куките за изчистване се задействат автоматично при промяна на съдържание, продукти, цени или поръчки, така че съответните кеширани страници се обновяват веднага, а не по график, като също така можете да изчиствате при поискване от таблото за управление или от WordPress. Изчистването на базата на етикети означава, че редактирането на една публикация изчиства само нея и нейните архиви — а не целия кеш — така че една редакция не рестартира на студено целия сайт.
Обектно кеширане с 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 image), блокиращи рендирането CSS и JavaScript, оформление, което се измества при зареждане на шрифтове и реклами, и тежка работа в основната нишка (main-thread) от плъгини. Никакво кеширане на сървъра не може да поправи водещо изображение от 2 MB или тема, която зарежда мегабайти JavaScript. Коректният хостинг прави приноса на сървъра практически минимален и постоянен, след което задължението на сайта е да поддържа потребителския интерфейс лек.
Това разделение на труда е полезният мисловен модел. Ние гарантираме, че заявката достига бързо до браузъра и остава бърза при натоварен трафик; Вие поддържате обема на данните малък и стабилен. Точно там, където двете се срещат — подгряване на кеша, доставка от мрежовата периферия (edge delivery) и поддържане на базата данни отзивчива, така че динамичните страници да не забавят работата си — нашата система е прецизно оптимизирана, и именно това прави управлявания WordPress на тази платформа по-бърз от същия сайт на стандартен хостинг.
Често задавани въпроси
Все още ли ми е необходима приставка за кеширане като WP Rocket?
Не. Кеширането на цели страници се обработва на уеб сървъра от LSCache на LiteSpeed, а нашият собствен плъгин за кеширане — предварително инсталиран и автоматично обновяван — свързва WordPress правилно с него, подкрепен от Redis кеш на обекти за всеки сайт. Добавянето на втори плъгин за кеширане на цели страници обикновено си пречи с кеша на ниво сървър, вместо да помага, така че не е необходимо и не се препоръчва.
Кеширането ще повреди ли моята количка в WooCommerce или страниците за влезли потребители?
Не. Количката, плащането, my-account и всички страници с nonce или сесии са изключени от кеша по подразбиране, а ESI поддържа фрагмента на количката и общите суми актуални на иначе кешираните страници. Купувачите винаги виждат собствената си кошница и работеща страница за плащане, докато витрината на магазина все още се зарежда от кеша.
Как кешът остава актуален, когато публикувам или редактирам?
Интелигентното автоматично изчистване се задейства при съответните WordPress куки, така че публикуването, редактирането на съдържание или промяната на продукт, цена или поръчка изчиства само засегнатите страници и техните архиви — не целия кеш — а робот ги подготвя отново. Можете също така да изчиствате при поискване от контролния панел или от вътрешността на WordPress.
Може ли само хостингът да ми осигури перфектни Core Web Vitals?
Това Ви дава възможно най-добрия TTFB, което е приносът на сървъра и начално предимство за Largest Contentful Paint. Но LCP, CLS и INP до голяма степен се определят от самата страница — размери на изображенията, блокиращи рендирането ресурси, стабилност на оформлението и JavaScript в основната нишка. Нашият стек прави приноса на сървъра бърз и постоянен; поддържането на лек преден панел е това, което покрива останалата част от разликата.
Свързани
Опитайте безплатно за 14 дни
Стартирайте първите си сайтове безплатно за 14 дни — без изискване за карта. Премествате съществуваща мрежа? Миграциите са безплатни и без ограничение.
Започнете безплатно