Стоит ли переезжать с Wordpress на статичные сайты (Gatsby, Jekyll, Hugo) и сколько это будет стоить?

Question

[Bloodshot]

Рассматриваю вариант переезда wordpress сайта на статику (Gatsby, Jekyll, Hugo и пр.). Хочется узнать мнение работавших в этом направлении разработчиков - насколько сложно скопировать внешний вид текущего сайта и воссоздать его на статике? Речь идет об информационном сайте, публикующем статьи с текстом, фото и видео. Никаких заморочистых сервисов на сайте нет. Основная цель переезда - скорость работы сайта. Ну и по деньгам сколько примерно будет стоить такая разработка.

Comments

[Дмитрий]

можно оставить WP как админку, а фронт крутить на Gatsby
https://www.gatsbyjs.org/docs/sourcing-from-wordpress/

но перед переездом стоит учесть, что основные проблемы с производительностью сейчас на фронте (кривые шаблоны, билдеры, кривые плагины)
и даже если уйти с WP, то кривой фронт так и останется кривым
если же менять фронт, то что мешает с новым фронтом остаться на WP?

Answer 1

[zorca]

Это просто новомодная фишка. На WordPress аналогичную схему можно организовать, просто отдавая статический кеш страниц напрямую через NGINX. Почитать можно тут: https://github.com/SatelliteWP/rocket-nginx После настройки статическая страница сможет выдержать неограниченную посещаемость и передаваться посетителю неизменно быстро. Стоимость - 4 часа специалиста по настройке вебсервера + лицензия WP-Rocket.

Comments

[Bloodshot]

Мне сисадмины настроили на стороне сервера кэш + браузерный кэш на стороне клиента, сильно не помогло, так как у меня много внешних запросов (~300-400). Сервер свой, мощный. Насколько я разобрался в ситуации - нужно ковырять код, заменять часть плагинов, оптимизируя их работу. Настраивать css, правильную загрузку скриптов. Оптимизировать картинки. Боюсь, что одной установкой ракеты не обойтись.

[zorca]

Bloodshot, внимательно прочитайте ответ: "отдавая статический кеш страниц напрямую через NGINX". В этой схеме не задействуется ядро WordPress, не используется PHP. Просто донесите эту информацию до ваших админов и пусть настроят по инструкции.

[Игорь Воротнёв]

Bloodshot,

сильно не помогло, так как у меня много внешних запросов (~300-400)

тогда переход на статику вам тоже не поможет. Поможет одно из двух:
- избавиться от этих запросов
- кешировать их

[Bloodshot]

zorca, подскажите, пжл, пообщался с админами насчет внедрения SatelliteWP/rocket-nginx. Они пишут, что данный плагин минимум полтора года как неактивен (его разработка не ведётся) что может говорить о том, что то что предлагает к внедрению разработчик - технически уже мертво. В общем, не рекомендуют устанавливать. Буду признателен за ваше мнение.

[zorca]

Bloodshot, специально для тупых админов выделю текст: "Rocket-Nginx is a Nginx configuration for the WordPress cache plugin WP-Rocket." Это КОНФИГУРАЦИЯ, а не плагин. И как может работающий конфиг устареть? Проверялся лично мной месяц назад на высоконагруженном проекте. Все работает как часы.
Конфигурирование состоит их двух частей:
1) Конфигурирование NGINX
2) Отключение WP-CRON и перевод его на обычный cronjobs серверный

[Bloodshot]

zorca, написал вам в личку на Хабре по этому поводу.

Answer 2

[АртемЪ]

Если речь у вас все работает на WP и речь идет именно о переезде - не стоит.
И на WP можно добиться таких же результатов.

Вот если делать с нуля - там зачастую есть смысл подумать нужен ли вообще WP.

Comments

[jamstackerman]

true story

Answer 3

[Вова Дружаев]

Сайт на вордпресс с мембершипом просто летает. Зачем съезжать на статику - причин не вижу.

не место красит человека - можно перефразировать - дело не в движках...

Answer 4

[Dima Minka]

я так же как и @zorce считаю, что речь о новых, модных технологиях, и с static cache можно достигнуть прекрасных результатов и с WordPress.
Буквально на днях я решил подключить Gatsby к WordPress, что бы накидать несколько постов, после чего понял, что WordPress лишние звено, так как задача была через чур тривиальна, и выбор пал на Markdown, фронт на Gatsby, deploy + lighthouse check на Gatsby cloud с выводом на Netlify...
пример

вывод, для простых решений на Gatsby - WordPress не нужен
для скорости сайта на WordPress - не нужен Gatsby

Теперь о стоимости:
Для работы с Gatsby нужен человек, который хорошо разбирается в React + HTML/SASS/SCSS, то есть даже несколько человек, а дальше зависит от количества нужных компонентов... Такие разрабы стоят не дешево... Грубо говоря 5 шаблонов может занять от 50ч, скажем ценник такого специалиста от 30$ в час...
Для того, что бы оптимизировать WordPress несколько часов, и можно получить достойных результат, все остальное, как например качество Frontend части вашей Theme, зависит от желания оптимизировать все под проверки типа Google Page Speed Insights = Lighthouse, и так же может занять десятки часов...

Comments

[Bloodshot]

Мне сисадмины настроили на стороне сервера кэш + браузерный кэш на стороне клиента, сильно не помогло, так как у меня много внешних запросов (~300-400). Сервер свой, мощный. Насколько я разобрался в ситуации - нужно ковырять код, заменять часть плагинов, оптимизируя их работу. Настраивать css, правильную загрузку скриптов. Оптимизировать картинки.

[Dima Minka]

Bloodshot, конечно, такое количество запросов требует дополнительного внимания, например:
* картинки подрубить к Smart CDN - optimole например
* Настроить lazy loading для стилей/картинок
* собрать в файлы css/js и минимизировать - это рокет
* после всего я бы советовал развернуть Dev окружение и оптимизировать уже сам код, убрав лишние, допилить существующее...

Просто в ракете почти все из коробки...
я приведу живой пример купленной темы из themeforest, там из коробки примерно 200 запросов, но с правильной настройкой я смог получить ответ от севера до 100ms, и загрузку до секунды (сервер в Лондоне, для рф чуть далеко), и уменьшить количество запросов до 50 вроде...
от этого тема не стала лучше, но скорость увеличилась, и фронт оптимизирован по минимуму.
пример

[Dima Minka]

Nazar Tertyshnyi, wp-rocket.me

Answer 5

[ZoomLS]

Конечно стоит. Hugo - хороший вариант, особенно если много страниц(быстро генерирует сайт). Неплохая документация, постоянно обновляется, быстрый. Есть инструменты Hugo для бегства с Wordpress. Внешний вид сайта достаточно просто перенести. Комменты можно прикрутить сторонними сервисами(Disqus и т.д). Для чего-то ещё, тоже можно использовать микросервисы. Но в вашем случае, судя по описанию - достаточно будет функционала из коробки. Сайт будет как ракета летать, безопасность вырастет в разы - не захочется больше использовать этого неповоротливого монстра Wordpress.

Comments

[Bloodshot]

А что насчет таких функций, как поиск по сайту? Кто-то писал мне, что на статике с этим проблемы.

[Игорь Воротнёв]

Для чего-то ещё, тоже можно использовать микросервисы

А что насчет таких функций, как поиск по сайту?

Вот тут начинается реальная жизнь, а не розовые единороги. Статика катит для простых и статических по своей природе сайтов. Если нужна дополнительная функциональность (обратите внимание - не функционал) то получается еще более неповоротливый монстр из микросервисов. Вы просто переносите complexity с одной плоскости в другую, не выигрывая ровным счетом ничего. Чаще даже наоборот - усложняете вещи там, где обычный монолит на динамической CMS является идеальным решением. Кроме того, у автора по его же собственным словам там пару сотен внешних запросов, которые и являются медленными. Я в упор не понимаю как он решит проблему медленных внешних запросов переходом с WordPress на статику. Имхо, автор решает не ту проблему.

[ZoomLS]

А что насчет таких функций, как поиск по сайту? Кто-то писал мне, что на статике с этим проблемы.

Есть варианты. Можно прикрутить поиск от того же Гугла. Либо сделать свой микросервис для этого.

Вот тут начинается реальная жизнь, а не розовые единороги. Статика катит для простых и статических по своей природе сайтов.

В данном случае, будет достаточно встроить поиск от Гугла.

получается еще более неповоротливый монстр из микросервисов

Что может быть хуже Wordpress? :) С чего вырастает монстр, да ещё и неповоротливый? Если делать нормально, то такого не будет.

Статика катит для простых и статических по своей природе сайтов.

Смотря что за сайт. Множество сайтов, а уж особенно блогов - можно перенести на статику с Wordpress и выйграть от этого.

Я в упор не понимаю как он решит проблему медленных внешних запросов переходом с WordPress на статику

С переносом сайта, можно будет заодно и с этим порешить. В любом случае, даже если ничего не делать - сайт все равно будет работать шустрее, чем на Wordpress.

[Bloodshot]

Спасибо всем за комментарии, вот это мне и было интересно узнать. Разные взгляды на проблему. Игорь Воротнёв - вы отчасти правы, да мы работаем над тем, чтобы оптимизировать Wordpress. Уже удалось сократить число внешних запросов в два раза, но их все равно много. Большая часть из них - это реклама и счетчики метрики от Яндекса и Гугла. И здесь ни вордпресс, ни статика не поможет.
Также есть проблема в плагинах. Отказаться от них на 100% пока не получается, но многие из них вносят свой негативный вклад, много времени уходит на поиск и отладку. Понятно, что и на статике могут быть все эти проблемы. Пока вижу только такой оптимальный сценарий - разрабатывать проект с нуля, дабы уйти от массовых решений и создать только нужный для сайта функционал. Остается вопрос в основе. Остаться на Wordpress или рассмотреть что-то более перспективное. В Wordpress конечно же привлекает его размах, огромное кол-во готовых решений, разработчиков. Но может действительно - это его недостаток? В общем, пока в раздумьях...

[Игорь Воротнёв]

ZoomLS,

В данном случае, будет достаточно встроить поиск от Гугла.

Хм, но я (клиент, отдел маркетинга) хочу "предиктивный поиск с полем поиска fullscreen, а также чтобы результаты красиво выводились по группам - отдельно сверху 5 найденных статей, а под ними еще из глоссария и FAQ статьи, если есть по тем же поисковым словам". Это цитата из реальности. Да, если это ваш личный небольшой контент-сайт и вы разраб, то вас вполне устроит примитивный поиск. Но для типового более-менее крупного контент-проекта - не подойдет.

Что может быть хуже Wordpress? :) С чего вырастает монстр, да ещё и неповоротливый? Если делать нормально, то такого не будет.

Хуже WordPress может быть все что угодно - от статики до любого другого фреймворка, CMS, CMF или самописа на любом другом языке. Вы сами говорите - секрет в том, чтобы делать нормально. Так вот, на WordPress тоже можно делать нормально. Это всего лишь инструмент. Хейтить его уже давно дурной тон.

Смотря что за сайт. Множество сайтов, а уж особенно блогов - можно перенести на статику с Wordpress и выйграть от этого.

Совершенно не спорю. Блоги и простые контентные сайты - однозначно да, статичные по своей природе - да. Собственно, я именно об этом и написал, это и была вся суть моего комментария :)

С другой стороны, если уж вы разраб, то высокой производительности можно добиться и с помощью WP, не теряя при этом CMS и гибкость редактирования. Совершенно ничто не мешает вам отдавать сайт с помощью nginx fastcgi_cache и получить best of two worlds - удобный динамический бекенд для редакторов и быструю статику для посетителей.

С переносом сайта, можно будет заодно и с этим порешить.

Но ведь жто же можно порешать и без переноса сайта. Что так, что так код фронтенда надо ковырять. В чем профит?

В любом случае, даже если ничего не делать - сайт все равно будет работать шустрее, чем на Wordpress.

Заблуждение и миф. Во-первых, вы сравниваете х** с пальцем - статику, отдаваемую только веб-сервером и CMS на PHP, для которой веб-сервер делегирует запрос на интерпретатор, который поднимает CMS (или фремворк - суть та же), а потом еще и в базу стучится. Разумеется второе будет более медленным, всегда. Впрочем, смотрите выше - динамический сайт на WordPress вполне можно повесить на nginx fastcgi_cache и перейти в ту же лигу, что и статика. Фронт для пользователей будет летать ровно с той же скоростью, что и статика. Один в один. Но для редакторов / админов вы сохраните удобную админку. И самое главное - менять ничего не надо, цена вопроса - полчаса настройки и тестирования.

[Игорь Воротнёв]

Bloodshot,

Большая часть из них - это реклама и счетчики метрики от Яндекса и Гугла. И здесь ни вордпресс, ни статика не поможет.

Вот я о том же. Впрочем, по ним тоже есть нюансы - посмотрите тут на тостере историю моих ответов, я не так давно отвечал по поводу того как можно "ускорить" все эти маркетинговые инструменты, обернув их в задержку инициализации. Реально полезная штука, пару строк кода.

Также есть проблема в плагинах. Отказаться от них на 100% пока не получается, но многие из них вносят свой негативный вклад, много времени уходит на поиск и отладку.

Ну, это проблема конкретного сайта и его сборки, как он исторически создавался и развивался. Все плагины можно либо заменить легковесными аналогами, либо написать свое. Это бич любых CMS / расширяемых инструментов - всегда будут "плагины", которые люди ставят для решения какой-то задачи, но используют реально 0.5% функциональности.

Пока вижу только такой оптимальный сценарий - разрабатывать проект с нуля, дабы уйти от массовых решений и создать только нужный для сайта функционал

Если проект настолько плох, что речь реально не о постепенном рефакторинге, а о переписывании с нуля - дело конечно дрянь. Но я бы советовал все-таки сделать шаг назад, выдохнуть и подумать, взвесив +/-. Можно ли постепенно, по кускам данную поделку отрефакторить, заменяя фичу за фичей на адекватную реализацию? Если да - это будет самый дешевый и оптимальный подход. Если реально нельзя - тогда может есть смысл использовать другое динамическое решение, если проект того требует? Возможно какой-нибуть Statamic или October CMS. Это же не белое-черное (статика-WP), есть и другие варианты.

И да, не используйте пожалуйста слово функционал, это режущая ухо ошибка :) Это математический термин. То, что вы имеете в виду называется функциональность.

Остается вопрос в основе. Остаться на Wordpress или рассмотреть что-то более перспективное. В Wordpress конечно же привлекает его размах, огромное кол-во готовых решений, разработчиков. Но может действительно - это его недостаток?

Разумно. Взвесьте и другие варианты (см. выше). Подсуммирую так - на WordPress можно делать быстрые, удобные и производительные сайты. Даже с использованием "передовых технологий" из мира PHP - composer, очереди, CI/CD и прочие вкусняшки. Все это можно. Но 95% рынка "вордпресс-разработчиков" даже понятия не имеют что это все такое. По моим наблюдениям, из 100% WP-разработчиков, где-то 60% - вообще не разработчики, а имплементаторы - эти умеют наставить плагинов и премиум-тему, натыкать в настройках, скопировать пару кусков кода со Stack Overflow и своей записной книжки (часто - устаревшего кода лет на 5-10). Еще 25% - это фулстаки и прочие разрабы, которые шарят в другом (чистом PHP, других CMS, других языках, фронтенд) и по сути разрабы, но недостаточно знают WP чтобы эффективно с ним работать - отсюда говнокод и костыли. Еще 10% - опытные WordPress-разработчики, которые хорошо знают именно WP, но часто отстают в развитии от PHP мира в целом, слегка застряли в прошлом. И только оставшиеся 5% - реально идеальная рабочая сила, которая умеет и в PHP, и в другие языки, и в WP. И умеет объединять разные инструменты и технологии для достижения оптимального результата. Вот этих и надо искать. Это будет дороже, но в итоге оно того стоит.

[Александр Борисович]

"предиктивный поиск с полем поиска fullscreen, а также чтобы результаты красиво выводились по группам - отдельно сверху 5 найденных статей, а под ними еще из глоссария и FAQ статьи,

Хотите хороший поиск, нужен сфинкс и подобное. Wordpress тут не силен. Используйте headless cms типа strapi, генерируйте статику, поиск по api. Или же поставьте GraphQL на пресс и работайте с ним как с админкой, а статику генерируйте по API.

Большое преимущество статики, если вы сверстали дизайн с помощью pug у вас нет необходимости натягивать его на движек. Цепляете его к API и верстаете прямо на живом контенте. Красота.