Преработка на WooCommerce магазин в headless, как протича

# ЕтикетиWooCommerceHeadlessМестене

Екипът на WPhost11 окт 202613 мин четене

Магазинът Ви на WooCommerce се зарежда бавно, PageSpeed Insights показва червени числа, а при всяка кампания сървърът едва издържа. Преработката на WooCommerce магазин в headless сменя витрината, която виждат купувачите, а продуктите, поръчките и админ панелът остават същите.

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

Накратко

Преработката започва с одит и с измерване в PageSpeed Insights на началната страница, на категория и на продукт.
Продуктите, поръчките, профилите на клиентите и админ панелът остават в WooCommerce. Сменя се витрината, която става приложение на Next.js.
Страницата за поръчка предлага Еконт, Спиди и наложен платеж. Опашка пази поръчките, когато WooCommerce не отговаря, а Kubernetes добавя капацитет при пикове.
Всеки сменен адрес се пренасочва постоянно, а работата минава през Git и staging и се пуска с план за връщане назад.
При предаването получавате отчет от PageSpeed Insights с 90+ за скорост на мобилни.

Как започва преработката на WooCommerce магазин в headless

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

Не всеки бавен магазин има нужда от преработка. Понякога причината е в един тежък плъгин, в хостинга или в снимките и се оправя без нова витрина. Ако одитът покаже такава причина, по-разумно е първо да се оправи тя. Най-честите причини са описани в ръководството Бавен WooCommerce магазин, 7 причини и как да ги оправите.

После мерим скоростта в PageSpeed Insights за мобилни устройства на три страници: началната, страница на категория и страница на продукт. Те носят най-много посещения и всяка се зарежда по различен начин. Лабораторният тест дава малко по-различен резултат при всяко пускане, затова го пускаме няколко пъти. Ако магазинът има достатъчно посещения, PageSpeed Insights показва и данни от реални посетители за последните 28 дни. Тези числа са отправната точка, с която сравняваме при предаването. Как да ги проверите и сами, обясняваме в ръководството Как да измерите скоростта на сайта с PageSpeed Insights.

Какво остава в WooCommerce

Продуктите, поръчките и профилите на клиентите остават в WooCommerce. Управлявате магазина от същия админ панел, добавяте продукти, сменяте цени и наличности и обработвате поръчките както досега. Не се налага да учите нова система и екипът Ви продължава да работи по същия начин.

Това е голямата разлика от преместването на магазина на друга платформа. Данните не се пренасят в нова система, затова отпада рискът, който носи всяко такова пренасяне. Сменя се начинът, по който купувачите виждат магазина.

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

Как изглежда новият магазин отвътре

Купувачите отварят витрина, направена с Next.js. Тя взима продуктите, категориите и цените през API на WooCommerce. Страниците се подготвят предварително и се обновяват на заден план, така че купувачът не чака WooCommerce при всяко отваряне.

Готовите страници се пазят в кеш и се раздават през CDN, мрежа от сървъри, които държат копия близо до посетителите. Според web.dev така заявката не стига до основния сървър и времето до първия байт може да намалее значително. Разглеждането на продукти и категории не натоварва WooCommerce. Той се включва, когато витрината има нужда от данни, които не може да подготви предварително, например при поръчка.

За купувачите това означава бърз магазин. За Вас означава, че WooCommerce поема много по-малко работа, отколкото когато обслужваше всяко посещение сам.

Поръчката с Еконт, Спиди и наложен платеж

Страницата за поръчка е част от витрината. Изборът на офис на Еконт или Спиди е направо в нея, с данни от API на двата куриера. Те публикуват списъците на офисите и градовете си, както и услуги за пратки, затова купувачът избира офис, без да напуска поръчката.

Наложеният платеж, с който купувачите в България са свикнали, остава. Той е вграден в WooCommerce и не изисква връзка с банка, затова поръчката с наложен платеж влиза в WooCommerce както досега, а куриерът събира сумата при доставка. Според документацията на WooCommerce такива поръчки стоят в статус Processing, докато парите не бъдат събрани.

Плащането с карта не е част от стандартния модел. Ако Ви трябва, уговаряме го за конкретния проект, защото зависи от банката или платежния доставчик и изисква собствена връзка с него. Затова кажете още при първия разговор, ако приемате плащане с карта, за да бъде то в офертата.

Какво става, ако WooCommerce не отговаря

При класическия магазин поръчката зависи от сървъра в момента, в който купувачът натисне бутона. Ако WooCommerce е претоварен или временно спрян, купувачът вижда грешка и поръчката може да се изгуби, а често и самият купувач.

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

За Вас това означава, че кратко спиране на WooCommerce не струва поръчки. Те се появяват в админ панела, щом WooCommerce отговори.

Как Kubernetes поема пиковете в трафика

Витрината работи в Kubernetes, система, която управлява приложенията на няколко сървъра. Посетителите се разпределят между няколко еднакви копия на витрината.

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

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

Карта на адресите и пренасочвания 301

Магазинът има позиции в Google, натрупани с времето, и те са свързани с адресите на страниците. Затова преди пускането правим карта на адресите, тоест списък, в който всеки стар адрес има свой нов. Основа за нея са картата на сайта, продуктите и категориите в WooCommerce и страниците, които носят посещения според отчета Performance в Google Search Console.

Най-добре е адресите да не се сменят. Витрината може да запази структурата, която WooCommerce ползва по подразбиране, например /product/ за продуктите и /product-category/ за категориите. Там, където адрес все пак се сменя, старият се пренасочва постоянно към новия.

Постоянното пренасочване е с код 301 или 308. Google третира двата кода по един и същ начин и приема новия адрес за основен. Next.js например връща 308 при постоянно пренасочване, така че не се притеснявайте, ако проверка покаже този код.

Google съветва пренасочванията да останат колкото може по-дълго, обикновено поне година, а временното колебание в позициите по време на смяната според него е нормално. Заедно с адресите във витрината се пренасят мета описанията, структурираните данни, canonical адресите, картата на сайта и hreflang за езиците. Подробно как се сменя сайт, без да се губят позиции, описваме в ръководството Как да смените сайта, без да загубите позициите си в Google.

Изработка и тестове в Git и staging

Всичко се прави в Git и в staging. Git е система, която пази всяка промяна в кода и позволява връщане към предишна версия, а staging е тестова среда, отделна от истинския магазин. Нищо не се пробва първо на живия магазин, затова купувачите не виждат недовършена работа.

Вие виждате новия магазин в staging и го одобрявате, преди да стане публичен. Разгледайте го като купувач, на телефон и на компютър, и минете през целия път от продукта до поръчката.

Преди пускането проверяваме най-важното:

Тестови поръчки с всеки начин на доставка и с наложен платеж стигат до WooCommerce с правилните данни.
Всеки адрес от картата води към правилната нова страница.
Заглавията, мета описанията, структурираните данни и картата на сайта са на място.
Скоростта на началната страница, на категория и на продукт е измерена в PageSpeed Insights.

Пускането и планът за връщане назад

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

Тук моделът дава едно предимство. Продуктите, поръчките и профилите на клиентите не се местят от WooCommerce, затова връщането засяга само витрината. Данните остават там, където са били, а поръчките от новата витрина се записват в същия WooCommerce.

Отчетът при предаването

В деня на предаването мерим отново в PageSpeed Insights на мобилни, на същите страници като при одита, и Ви даваме отчета. Резултатът за скорост е 90+, а за SEO се стремим към 100. Така имате числата преди и след, измерени по един и същ начин.

Данните от реални посетители в горната част на отчета се събират за 28 дни, затова там подобрението се появява постепенно. Лабораторният тест показва новия резултат веднага.

Резултатът зависи и от това, което се добави по-късно. Рекламни пиксели, чатове и други външни скриптове го свалят, затова е добре да ги проверим заедно, преди да влязат в магазина.

Поддръжката след пускането

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

При активна поддръжка всеки ден сверяваме плъгините, темата и WordPress с базите данни за известни уязвимости (CVE) и ги обновяваме навреме, след тест в staging. Какво включват пакетите, е описано в месечната поддръжка.

Чеклист

Имате измерване в PageSpeed Insights на началната страница, на категория и на продукт отпреди преработката.
Знаете кои плъгини остават в WooCommerce и кои функции се правят наново във витрината.
Ако приемате плащане с карта, то е уговорено в офертата.
Картата на адресите е готова и всеки сменен адрес има постоянно пренасочване.
Видели сте магазина в staging и сте го одобрили.
Тестовите поръчки с Еконт, Спиди и наложен платеж са стигнали до WooCommerce.
Знаете какво пише в плана за връщане назад и кой го изпълнява.
Получили сте отчета от измерването в деня на предаването.
Знаете кой обновява WordPress, WooCommerce и витрината след пускането.

Трябва ли да минавате през всичко това сами?

Ако магазинът Ви е малък и работи бързо, класическият WooCommerce е достатъчен и преработка не Ви трябва. Как да прецените, обясняваме в ръководството Класически WooCommerce или headless магазин, как да изберете. Ако магазинът Ви е бавен и расте, на страницата за преработка на WooCommerce магазин е описано как го правим по нашия headless модел. Купувачите виждат бърз магазин на Next.js, а Вие работите както досега.

Често задавани въпроси

Какво е headless преработка на магазин с WooCommerce?

При headless преработка витрината, която купувачите виждат, се сменя с приложение на Next.js, а продуктите, поръчките, клиентските акаунти и админът остават в WooCommerce. Данните не се прехвърлят в нова система, така че отпада рискът, който носи всяко такова прехвърляне. Вие и екипът Ви работите в същия админ както досега.

Всеки бавен магазин с WooCommerce ли има нужда от headless преработка?

Не. Понякога причината за бавния магазин е един тежък плъгин, хостингът или изображенията и тя се оправя без нова витрина. Затова преработката започва с одит, а ако той намери такава причина, по-разумно е първо тя да се поправи.

Ще трябва ли да уча нова система след headless преработката?

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

Има ли Еконт, Спиди и наложен платеж в headless магазин?

Да. Изборът на офис на Еконт или Спиди става направо в страницата за поръчка с данни от API на двата куриера, така че купувачът не напуска поръчката. Наложеният платеж е вграден в WooCommerce и не иска връзка с банка, така че поръчката с него влиза в WooCommerce както преди. Плащането с карта не е част от стандартния модел и зависи от банката или доставчика, затова го споменете още в първия разговор.

Какво става с поръчките, ако WooCommerce не отговаря?

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

Как headless магазинът издържа на пикове в трафика?

Витрината работи на Kubernetes и посетителите се разпределят между няколко еднакви копия. При кампании и разпродажби Kubernetes пуска още копия, а когато трафикът спадне, спира излишните, като най-малкият и най-големият брой копия се задават предварително. Разглеждането на продуктите минава през кеша и CDN и не натоварва WooCommerce.

Ще загуби ли магазинът позициите си в Google след преработката?

Преди пускането се прави карта на адресите, която свързва всеки стар адрес с новия, а най-добре е адресите изобщо да не се сменят. Където адрес се смени, старият се пренасочва постоянно с код 301 или 308, които Google третира еднакво, а мета описанията, структурираните данни, sitemap и hreflang също минават във витрината. Google казва, че временни колебания в позициите при преместване са нормални, и съветва пренасочванията да се пазят поне година.

Какво получавам при предаването на headless магазина?

В деня на предаването скоростта се мери отново в PageSpeed Insights на мобилно, на същите страници като при одита, и получавате отчета с оценка 90+ за скорост. Данните от реалните посетители се събират за 28 дни, така че подобрението се появява там постепенно. Рекламни пиксели, чат прозорци и други външни скриптове, добавени по-късно, свалят резултата.

Източници