Headless WordPress с Next.js, кога си струва и кога не

Чували сте, че headless WordPress с Next.js прави сайта много по-бърз, или вече имате оферта за такъв сайт. Звучи добре, но не е ясно какво точно купувате, колко по-сложна ще е поддръжката и дали изобщо Ви трябва.

В това ръководство обясняваме с прости думи как работи такъв сайт, какво печелите и какво плащате за това. После минаваме през случаите, в които headless си струва, и през тези, в които класическият WordPress е по-добрият избор. Накрая има чеклист, с който да прецените своя случай.

Какво е headless WordPress с Next.js?

Класическият WordPress върши две неща наведнъж. В админ панела пишете текстовете и качвате снимките, а темата сглобява от тях страниците, които посетителите виждат. Всяко отваряне на страница, която не е в кеша, минава през PHP и базата данни.

Headless означава „без глава“. Главата е публичната част на сайта и при този подход тя е отделена от WordPress. Екипът Ви продължава да пише и редактира в познатия админ панел, с редактора и медийната библиотека. Сайтът, който виждат посетителите, е отделно приложение, направено с Next.js. Това е рамка за уеб сайтове и приложения, изградена върху React.

Двете части си говорят през API, тоест през адреси, от които една програма чете данните на друга. WordPress има вграден REST API, който връща публикациите, страниците и медиите като JSON, прост текстов формат за данни. Друг вариант е WPGraphQL, безплатен плъгин, с който сайтът на Next.js иска от WordPress точно полетата, които са му нужни.

Можете да видите тези данни и на собствения си сайт. Отворете в браузъра https://primer.bg/wp-json/wp/v2/posts, като смените primer.bg с Вашия домейн. Ще видите последните публикации като текст с данни, без никакъв дизайн. Ако вместо това излезе грешка, вероятно плъгин за сигурност ограничава достъпа до REST API.

Как Next.js чете публикациите от WordPress

За да стане по-ясно, ето кратък пример, направен по документацията на Next.js. Примерът е само илюстрация и не е готова настройка. Файлът е страница в проект на Next.js с App Router и показва списък с най-новите публикации от WordPress, всяка с връзка към своя адрес.

// app/blog/page.js в проект на Next.js (App Router)
export const revalidate = 3600; // обновява се най-много веднъж на час

export default async function Page() {
  const res = await fetch(
    "https://primer.bg/wp-json/wp/v2/posts?_fields=id,slug,title"
  );
  const posts = await res.json();

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>
          {/* WordPress връща заглавието като HTML */}
          <a
            href={`/blog/${post.slug}`}
            dangerouslySetInnerHTML={{ __html: post.title.rendered }}
          />
        </li>
      ))}
    </ul>
  );
}

Параметърът _fields казва на WordPress да върне само номера, краткото име в адреса (slug) и заглавието на всяка публикация вместо всичките ѝ полета. Заглавието идва като HTML, защото WordPress форматира текста и може да замени кавичките и апострофите в него с HTML кодове. Затова примерът го вмъква като HTML.

При изграждането на сайта Next.js взима публикациите и подготвя готова HTML страница. Посетителите я получават, без WordPress да участва. Когато мине един час, следващият посетител все още получава запазената версия, а Next.js подготвя нова на заден план и я подменя, щом е готова. Ако WordPress не отговори в този момент, според документацията на Next.js продължава да се показва последната успешно подготвена версия.

За да стане от това истински сайт, трябват още много неща: отделна страница за всяка публикация, снимките, заглавията и мета описанията за Google, картата на сайта, страница за грешка и преглед на чернови. Всичко това се програмира, докато при класическия WordPress темата и плъгините го дават наготово.

Кога промените се виждат на сайта

Това е първият въпрос на редакторите, които минават към headless. В примера по-горе нова публикация се появява в списъка до един час след като е публикувана, защото страницата се обновява най-много веднъж на час.

Обновяването може да се свърже и с публикуването. Next.js има функция revalidatePath, която обявява запазената версия на дадена страница за остаряла, а малко код в WordPress може да я задейства всеки път, когато редакторът публикува или запази промяна. Тогава следващият посетител вече получава новата версия. Колко бързо трябва да се появяват промените, решете още при поръчката на сайта, защото от това зависят и изработката, и натоварването на WordPress.

Защо headless сайтът е по-бърз

При класическия WordPress страницата се сглобява, когато посетителят я поиска. Плъгинът за кеш пази готови копия и това помага много, но страниците, които са различни за всеки посетител, като количката в магазин, остават извън кеша и всеки път минават през PHP и базата данни.

При headless сайт страниците се подготвят предварително и се зареждат от кеш, без да чакат PHP и базата данни. Могат да се раздават и през CDN, мрежа от сървъри, които пазят копия на страниците и файловете по-близо до посетителите. Според web.dev така заявката не стига до основния сървър и времето до първия байт може да намалее значително.

Има полза и за търсачките. В документацията си за JavaScript сайтовете Google препоръчва страниците да се изобразяват на сървъра или предварително, защото тогава се зареждат по-бързо и за хората, и за ботовете, а някои ботове изобщо не изпълняват JavaScript. Next.js работи точно така и търсачките получават готов HTML.

Самият подход не гарантира скорост. Тежки снимки, много шрифтове и външни скриптове забавят и сайт на Next.js, а рекламни пиксели и чатове, добавени по-късно, свалят резултата. Затова мерете преди и след всяка голяма промяна. Как се чете резултатът, обясняваме в ръководството Как да измерите скоростта на сайта с PageSpeed Insights.

Какво се променя за сигурността

При класическия WordPress формата за вход, плъгините и темата са на същия адрес като сайта. Ботове обикалят интернет постоянно и търсят wp-login.php, слаби пароли и плъгини с известни уязвимости.

При headless посетителите говорят само със сайта на Next.js. WordPress трябва да е достъпен за него, но не и за целия интернет, затова админ панелът може да е скрит, например да се отваря само от определени адреси. Тогава формата за вход и плъгините на WordPress не са изложени на ботовете.

Това намалява възможностите за атака, но не ги премахва. Сайтът на Next.js има свои зависимости, които също трябва да се обновяват. WordPress продължава да има нужда от обновявания и проверки за уязвимости, дори когато е скрит, защото уязвим плъгин си остава уязвим. Подробно разглеждаме темата в ръководството Headless WordPress и сигурността, какво всъщност се променя.

Повече свобода в дизайна

Темата на WordPress определя много неща, от структурата на страниците до това кои стилове и скриптове се зареждат. Промени извън нейните рамки често означават надграждане върху чужд код, а всеки плъгин добавя свои файлове към страницата.

При headless публичната част се прави от нулата за Вашия сайт. Дизайнерът не зависи от тема или конструктор. Програмистът решава какво да се зареди на всяка страница. Така е по-лесно сайтът да изглежда точно както сте го замислили и в същото време да е бърз.

За редакторите работата остава позната. Страниците се сглобяват от готови блокове, направени за Вашия дизайн, които се подреждат в WordPress без програмист. Блоковете обаче са толкова, колкото са направени. Нов вид секция, за която няма блок, се добавя в кода.

Какво струва headless

Предимствата имат цена, която е добре да знаете, преди да подпишете.

• Две системи вместо една. WordPress и сайтът на Next.js се изграждат, хостват и обновяват поотделно. Когато нещо спре, причината може да е в едната част, в другата или във връзката между тях.
• Плъгините за публичната част отпадат. Всичко, което плъгин добавя към страниците за посетителите, се прави наново в Next.js. Това важи за слайдерите, формите, банера за бисквитките и оптимизацията на скоростта. Някои плъгини дават данните си през API. Yoast SEO например връща метаданните и структурираните данни на всяка страница, но ги показва сайтът на Next.js.
• Конструкторите на страници не работят. Elementor, Divi и подобните подреждат страниците през темата, а при headless темата не участва. Ако сега ползвате Elementor и сайтът е бавен, вижте първо защо Elementor забавя сайта.
• Прегледът на чернови иска допълнителна работа. Бутонът „Преглед“ в WordPress показва страницата през темата. В headless сайт прегледът минава през режима Draft Mode на Next.js, който заобикаля кеша само за редактора, а WordPress трябва да се настрои да отваря правилния адрес.
• Изработката струва повече. Програмират се публичната част, връзката с WordPress, SEO данните и прегледът, които при класическия WordPress идват наготово. Колко точно, зависи от сайта и се вижда в офертата.

Кога headless си струва

Headless има смисъл там, където от скоростта при голямо натоварване зависят продажби или читатели.

• Растящ онлайн магазин. Продуктовите и категорийните страници се подготвят предварително и се зареждат бързо дори по време на кампании и разпродажби, а продуктите и поръчките остават в WooCommerce. Кога това има смисъл за един магазин, разглеждаме в ръководството Класически WooCommerce или headless магазин, как да изберете.
• Сайт със съдържание и много посетители. Това са медии, портали и големи фирмени сайтове, при които всяко посещение на класически WordPress натоварва сървъра. При headless повечето посещения изобщо не стигат до WordPress.
• Сайт на няколко езика. Всяка езикова версия е отделен набор от предварително подготвени страници, затова още един език не прави сайта по-бавен. Връзките hreflang, с които Google разбира кои страници са езикови версии на една и съща страница, се правят веднъж в кода и важат за целия сайт.

И в трите случая WordPress продължава да има нужда от добър сървър. През него минават редакторите и обновяването на страниците, а при магазина и всяка поръчка.

Кога класическият WordPress е по-добрият избор

Малък фирмен сайт с десетина страници, който се редактира два пъти в годината, не печели почти нищо от headless. Добре направен класически WordPress с лека тема, добър хостинг и кеш е бърз, а изработката и поддръжката му струват по-малко. Една система е по-проста и за обновяване.

Класическият WordPress е по-добър и когато разчитате на плъгини, които променят публичната част, или искате сами да подреждате страниците с конструктор. Ако сайтът почти не се променя, помислете дори за статичен сайт, тоест набор от готови HTML файлове без база данни. Той е бърз и при него почти няма какво да бъде атакувано.

Ако се колебаете, започнете с класически WordPress. Съдържанието, написано с редактора на WordPress, остава в базата данни и може да се показва от headless сайт по-късно. Със съдържание от конструктор на страници това е по-трудно, защото то е силно обвързано с конструктора.

Чеклист

• Знаете кой ще пише съдържанието и колко често ще се променя сайтът.
• Измерили сте сегашния сайт в PageSpeed Insights на мобилни и знаете какво го забавя.
• Имате списък с плъгините, които променят публичната част, и знаете кой ще ги направи в Next.js.
• Ако ползвате конструктор на страници, приемате, че той отпада.
• Офертата включва преглед на чернови, SEO данните, картата на сайта и пренасочване на старите адреси.
• Ясно е дали админ панелът ще е скрит от интернет и как ще влизате в него.
• Знаете кой ще обновява WordPress и сайта на Next.js след пускането.
• Сравнили сте разходите с тези за добре направен класически WordPress.

Трябва ли да решавате сами?

Ако сайтът Ви е малък и се променя рядко, headless не Ви трябва и няма нужда да мислите повече по въпроса. Ако имате магазин, който расте, или сайт с много посетители, отговорът зависи от плъгините, трафика и екипа Ви. На страницата за изработка на сайтове и онлайн магазини са трите варианта, с които работим, от сайт на класически WordPress за малкия бизнес до headless онлайн магазин и headless WordPress за големи сайтове. Разкажете ни за сайта си и ще Ви препоръчаме варианта, който му подхожда, включително по-простия, ако той е достатъчен.

Източници

• WordPress, REST API Handbook
• WordPress, REST API Reference, Posts
• WordPress, REST API Global Parameters
• WordPress, REST API Frequently Asked Questions
• WordPress, wptexturize()
• WordPress.org plugins, WPGraphQL
• Next.js, Documentation
• Next.js, Incremental Static Regeneration (ISR)
• Next.js, Caching and Revalidating
• Next.js, Draft Mode
• web.dev, Content delivery networks (CDNs)
• Google Search Central, JavaScript SEO basics
• Google Search Central, Localized versions of your pages
• Yoast, REST API