Hugo

В предыдущей заметке на тему переезда на Hugo всем блогом я объяснял, почему решил заодно опробовать новую внешнюю систему комментариев Replybox — она очень немного весит, имеет возможности авторизации и так далее. Впрочем, уже за пару дней эксплуатации у неё выявились недостатки, несовместимые с жизнью.

Самый первый недостаток выявили сразу — оказывается, стремление Apple к победе privacy уже сделало не очень удобным использование таких систем, поскольку по умолчанию им требуется доступ к сторонним кукам, а Safari его по умолчанию блокирует. Впрочем, с этим бы я еще пожил.

Неприятнее оказалось другое — система, красиво описывая, как она интегрирована с Wordpress, на самом деле просто быстро перелила себе все комментарии, но новые комментарии отдавать Wordpress-у не собиралась. В связи с чем мне очень неудобно перед теми, кто комментировал предыдущую запись — их комментарии никак не перенести обратно. Я могу только придумать их перепостить здесь и ответить так же, что и сделано ниже.

Как несложно догадаться, никакого экспорта система не предлагает. Более того, она и не предлагает никакого способа использовать данные — нет ни счетчиков, ни виджета последних комментариев. И она еще и глючная — буквально за несколько дней она насчитала мне 15 тысяч хитов и я даже не понимаю, что она считала — неужели количество показов каждого комментария? Если учесть, что она платная, причем именно по показам, выглядит совсем плохо.

В общем, в итоге я занялся пристальным изучением творения того же Umputun — то есть системы комментариев remark42. Легко догадаться, что именно она и живет теперь здесь. Все приведенные недостатки у неё отсутствуют, а стоимость держания дополнительного контейнера равна минимальному тарифу у Replybox, к тому же я вполне могу и эту сумму сэкономить.

А ниже — те комментарии, которые остались в Replybox.

googhalava: Да, скорость загрузки впечатляет.
А вы не встречали способа писать посты в Hugo с телефона в процессе поиска? Вообще, нет способа писать посты в hugo. Посты писать надо во что-то, откуда hugo возьмет базу. В принципе, написать пост в гитхабе можно и с телефона. Можно попробовать прикрутить что-то типа netlify cms, которая умеет делать маркдаун-посты в выбранный репозиторий. С другой стороны, поскольку я давно перестал писать по 10-20 постов в день в блоге, то с телефона я скорее напишу в твиттер, а сюда можно и более основательно подготовиться.

googhalava: Я понимаю, как Hugo работает. Вопрос в том, как лучше организовать процесс написания, если ты пишешь не один и другие люди не готовы писать посты в Markdown. Я честно не знаю, как организовать процесс для нескольких человек, поскольку отправка постов несколькими человеками почти одновременно выглядит в данном случае странно. Живым людям можно вручить текстовый редактор типа ulysses или iAwriter, чтобы писать в маркдауне.

Alexey Shevchenko:
действительно быстро! Но есть вопросы:

1. Для СЕО, есть возможность генерировать читабельные URL, вместо: https://new1.blognot.co/60602/ ? Типа https://new1.blognot.co/60602/hugo-blog-kak-sdelat
2. Ответить на комментарий удалось только после отключение блокировки third-party cookies (Brave browser). Не круто, но понятно что удобно и быстро. Подозреваю в firefox и safari может быть такая же проблема.

1. Да, тут можно хоть руками задать, хоть из шаблона генерировать, я специально прописываю так, чтобы сохранить совместимость с вордпрессом.
2. В Safari да, есть такая проблема. Но вообще любая внешняя система комментариев столкнется с этим, разве что кроме того же ремарка, который можно поставить на поддомен и тогда его куки будут first-party.

zabey_ded :_ В кэш нужно уметь, он подходит где вы контролите всё. Темы лишены этого знания. Если тема без параметров, реализовать кэш просто, но никто не хочет их юзать, ибо нет ничего. Сложные темы настраиваются гибче, их скорость меньше, прирост от кеша большой, но и добавить его сложнее. А добавив, автоматически сильно усложняется допилка+понимание работы для окружающих. Если это просто (заменить всё на partialCached), почему никто этого не делает массово? Это чем-то похоже на дебаг неиспользуемого CSS в тулзах хрома. Полезно, но многие не понимают как оно работает и лезут. Если начать удалять всё неиспользуемое, можно поломать стили и не заметить. Тот же принцип: если кэш работал для вашего сайта, где все параметры одинаковы для всех страниц, это не значит, что оно заработает для других людей, которые используют более специфичные конфиги. О cache potential: 100 присваивается частям, которые не менялись при конкретной генерации для всех страниц. Эта система может ошибаться как детектор неиспользуемого CSS. Если сайдбар всегда справа, с одинаковым контентом, то вам покажет 100. Это не значит, что его можно закэшировать в 100 процентах случаев. Вот кто-то добавил новый виджет для конкретной секции сайта и всё, кэш ломается, потому что некоторые страницы теперь используют другой набор входных параметров. Это значение не константа, один раз проверил работает только если вы вообще больше к теме не притрагиваетесь и не используете её параметры во front matter. Кажется, четырехкратное ускорение вы получили в том числе, что сломали фичи, которые не используете. Поэтому «люди, осилившие язык шаблонов очень гиковского движка, знают что делают» и таки отличаются от людей, научившихся делать темы для WordPress. По крайней мере, не трогают то, в чём не разбираются на 100 процентов. Я надеюсь. А ваш вредный совет может кому-то подарить несколько незабываемых часов и сообщений на форумах в духе ПАМАГИТЕ!11. Начать с Hugo легко, оптимизировать его под готовый сайт со множеством страниц — нужно время и знания. Я настоятельно советую потратить несколько дней на изучение того, как оно работает на уровне чтения важных страниц документации (в особенности, если являетесь представителем WordPress или древнего PHP сообщества, без обид). И ридми темы тоже почитать, если вы решили готовую использовать, а не свой шаблон накодить. Иначе вас ждёт множественное наступание на грабли в самых неожиданных местах. P.S. Чёрная иконка YouTube это так было задумано?

За причисление меня к представителям PHP сообщества, наверное, надо сказать спасибо, но я вообще не программист. Я не собираюсь разрабатывать темы для этого движка и, правя шаблоны для этого блога, преследую цель только исправить шаблоны для этого блога и добиться его публикации за время, немного меньшее 10-20 минут. Почему это так разгневало комментатора — не понимаю. Я же не бегаю по форумам с заявлениями «Криворукие гошники, вы вообще в состоянии представить себе, что в блоге может быть больше сотни записей?». Видимо, потому что знаю, что нет, не могут они себе такое представить. Впрочем, не в Go дело, конечно.

Ну вот, теперь примерно можно жить — я имею в виду комментарии и прочие украшения. Есть, конечно, что еще доделать. Так что не переключайтесь.

Прошлый текст на тему ухода с Wordpress я закончил выводом, что пока не готов переносить свой блог на Hugo — слишком долго собирается, нет удобного редактора и вообще много движений руками. Но возиться с этой темой не перестал, выкладывая все новые записи теперь в двух вариантах — в Wordpress и в репозиторий на Github, откуда и собирался вариант на Hugo. Чтобы как-то ускорить сборку сайта, я перепробовал довольно много вариантов хостинга — тем более, что таких сервисов становится всё больше, а процесс тестирования предельно прост — завести аккаунт с каким-то бесплатным лимитом, указать репозиторий и подождать, пока соберется. Оказалось, что в сборке есть две основные части — собственно сгенерировать сайт из исходных данных и выложить его на CDN или другое публичное место.

Генерация сайта во всех случаях занимала большое время, вне зависимости от сервиса. Какой-то сервис выполнял эту работу быстрее, какой-то медленнее, но в целом эта часть занимала от 180 до 240 секунд, то есть 3-4 минуты, что особой разницы не составляло.

Выкладка уже готового сайта была тоже почему-то не быстрой. На разных сервисах она занимала от 10 до 20 минут и, например, на Cloudflare Pages ломалась по таймауту. В какой-то момент мудрый Umputun посоветовал использовать Github Actions для управления процессом и это оказалось чуть быстрее — то есть сборка сайта стала занимать 150 секунд, видимо, за счет того, что всё делается внутри сервиса, ведь исходный репозиторий тоже на Github. Правда, от идеи использования Github Pages я отказался — это самый неудобный вариант из имеющихся, — а вместо этого поднял самый простой дроплет на Digital Ocean, водрузил там самый простой веб-сервер Caddy, и наладил выгрузку готового сайта туда. Этап выгрузки стал занимать секунд 20, а, поскольку использовался rsync, то обновления стали выкладываться практически за секунду-две.

Я почти было смирился с 5 минутами на публикацию сайта, хотя и подумывал, что они обусловлены ограничениями бесплатных хостингов, и не попробовать ли самостоятельно генерировать сайт, — но тут не менее мудрый bobuk попросил ему показать статистику сборки, которая вызывается командой

hugo --templateMetrics --templateMetricsHints

Результат показал страшную вещь — оказывается, при генерации сайта из 8 с лишним тысяч одиночных записей и 500 страниц ленты (плюс страницы тегов и категорий), Hugo каждый раз (то есть 9 тысяч раз) генерировал каждый блок бокового меню (включая облако тегов, например) и собственно сам сайдбар целиком, хотя там ничего не менялось в принципе.

Bobuk хмыкнул и сказал гуглить partialCache. Я до этого и не смотрел в исходники темы особо, полагая, что люди, осилившие язык шаблонов очень гиковского движка, знают что делают, но, как я потом сообщил коллегам, принципиально не отличаются от людей, научившихся делать темы для Wordpress.

Если соберетесь сами повторить этот путь, то рецепт несложный — идете в файлы шаблонов, ищете все вхождения partial, внимательно смотрите на каждое и убеждаетесь, что оно даёт уникальный результат. Впрочем, если вы запросите статистику командой, которая приведена выше, то первой колонкой будет выведен процент идентичности результатов и, если там стоит 100, то вызов этого шаблона обязательно надо менять на partialCached.

И будет примерно такое счастье.

Как видите, время генерации снизилось почти в 4 раза. Это результаты на моем ноутбуке, actions на Github стали отрабатывать этап генерации за 30 секунд, а общее время выкладки стало занимать меньше двух минут, причем почти половину из него стало приходиться на разворачивание собственно среды для генерации и выкладки. Наверное, впрочем, тут тоже можно как-то оптимизировать, опять же унеся генерацию на собственный сервер и не таская каждый раз весь репозиторий, но и так жить можно.

Интересно, что в результате такой оптимизации перестали возникать проблемы и с другими системами — выкладка на Cloudflare Pages стала занимать 4 минуты и больше не ломалась.

Еще одной темой для изучения стали комментарии. В принципе, никаких изменений тут не произошло — либо вы отказываетесь от них, либо используете внешние комментарии. Причем есть даже решения, которые отправляют комментарии в отдельный репозиторий и из него строят отдельный блок для встраивания на страницу, но это уж слишком. Я в итоге остановился на решении от Replybox — симпатичные минимальные внешние комментарии, которые грузят буквально 10-15 кБ кода, что является абсолютным рекордом среди таких систем. Даже с включенными комментариями Google PageSpeed оценивает страницу в 100 из 100, чего не делает практически никогда при наличии других систем. Правда, система платная, но любая другая система, имеющая опцию self-hosted, тоже потребует денег на минимальный хостинг. Собственно, это заодно и ответ на вопрос, почему я не выбрал remark42 авторства того же Umputun.

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

Правда, как я уже тоже отмечал, все новое — это хорошо обруганное старое. Самый первый движок этого блога — Movable Type, — еще в далеком 2002-м году умел через свой интерфейс принять текст, загрузить изображения, гибко настроить шаблон и сгенерировать все страницы контента статически. А потом пришел Wordpress.

Периодически меня вместе с этим блогом охватывает творческое настроение — но не в плане что-нибудь написать (такое тоже бывает), а посовершенствовать его немного, сделать еще более быстрым, местами более гиковским, короче, как-то проапгрейдить.

Надо сказать, что я не очень расположен к большой разработке и люблю обходиться готовыми решениями — взять готовый движок, готовую тему, что-то подкрутить по мелочам и попользоваться результатом. И в какой-то момента у меня сошлись сразу несколько ощущений относительно несовершенства текущего решения.

Основное ощущение касается скорости. Нет, блог вроде не тормозит и ему хватает возможностей хостинга (а если бы не хватало, то увеличить не проблема), но работает небыстро и это в основном результат того, что он работает на том стеке, на котором работает — php+mysql, хоть и с агрессивным кэшированием.

Вместе с тем, меня более чем устраивает сам движок Wordpress со всеми его богатейшими возможностями — благодаря тому, что его уже много лет развивают десятки тысяч человек, в нем можно сделать практически всё и уж точно всё, что может понадобиться небольшому блогу.

Я, впрочем, попробовать еще с месяц назад перенести контент в Ghost — который я помню еще в версии 0.1 и который вроде бы развился во что-то, но был достаточно сильно разочарован. После Wordpress, где информация достаточно хорошо структурирована, в Ghost регулярно встречаются места, где предлагается просто написать вот так, чтобы оно выводилось красиво — это как, знаете, в Word-е секретарши делают шрифт пожирнее и побольше, чтобы получился заголовок, а редактор честно продолжает считать это обычным текстом, а не заголовком. Впрочем, особенно меня удивило отсутствие групповых операций — представьте себе блог с тысячами записей, где любое действие надо делать с одной отдельной записью! Тем более, что первое, что сделал Ghost с контентом — объявил всех пользователей блога, которых Wordpress зарегистрировал как комментаторов (вы и сейчас можете так зарегистрироваться для комментария), просто авторами блога. Таких оказалось несколько десятков и никакого способа выбрать всех и сменить им роли или даже удалить не оказалось. Хотя показатели скорости публичной части прямо радовали, но пришлось отказать.

В результате я решил покопать тему Headless CMS. Упрощенно говоря, это такая конструкция, когда у вас отдельно есть сама CMS, которая управляет созданием и хранением контента, а отдельно — конструкция/фреймворк/генератор, который этот контент собирает в очень быстрый и часто — статический вебсайт и отвечает за его работу. Конструкция очень интересная — во-первых, она действительно красива логически, разделяя контент и его представление, во-вторых, она практически безопасна, поскольку даже критическая уязвимость публичной части вряд ли сможет сказаться на контенте. При этом на выходе получается действительно очень быстрый сайт.

Первая возможность, которую я исследовал, — как бы не отказываться от Wordpress-а и заменить только головную часть блога, которую видят пользователи. Такая возможность есть, поскольку у Wordpress по умолчанию есть Rest API, а с помощью плагина реализуется GraphQL API — пожалуйста, забирайте данные и собирайте из них что хотите.

Я попробовал несколько фреймворков — Next.js, Gatsby и Nuxt, тем более, что это довольно легко сделать с помощью облачных сервисов типа Netlify и Vercel — вы просто берете репозиторий на Github, даете его сервису и он сам собирает из него сайт. Если дать ему статический контент — соберет из него, дать контент через API из Wordpress — терпеливо запросит и соберет из полученного.

Правда, тут надо оговориться. Этому блогу много лет и в нем много контента. 8 с лишним тысяч заметок, 16 тысяч комментариев, 800 картинок, итого несколько гигабайт контента, который тяжеловато тягать с места на места и тем более обрабатывать. Это осложняет процесс тестирования, хотя я пробовал ограничивать число запросов. И, конечно, накладывает свои требования.

Так вот, тестирование фреймворков закончилось некоторым разочарованием — получающиеся сайты были действительно быстрыми, но даже на ограниченных данных они строились довольно долго и в любом случае говорить о разумной скорости публикации не удавалось — новый контент отображался примерно минуты через две-три. Возможно, всё было бы быстрее, если не пользоваться готовыми CI/CD сервисами, а собрать свой, но там впереди нарисовалась еще одна проблема — некрасивость.

Ну, правда, при взгляде на подавляющее большинство (не такое уж многочисленное, кстати) предлагаемых шаблонов дизайна возникала мысль, что громоздить всю эту схему, модные фреймворки, кучу сервисов и так далее, чтобы в итоге получился академический стиль с гугл-шрифтами, это как-то слишком. Особенно, когда начинало казаться, что потому сайты такие и быстрые, что там выводить нечего. Итого, все доступные шаблоны выглядели странно, а пара коммерческих не желала работать с Wordpress как источником контента.

В общем, несмотря на сильное нежелание, я пошел исследовать вторую возможность — перенос всего блога на другую платформу.

Тут особых вариантов не было — если не увлекаться совсем экзотическими форматами, то очевидный выбор — экспортировать блог в набор файлов в формате Markdown и использовать статический генератор типа hugo, который используется у нас на сайте подкаста Радио-Т.

Скрипт, переносящий контент, найти оказалось несложно, впрочем, результат его работы пришлось долго править руками — возможно, тому причиной опять-таки большой архив, причем созданный еще движком под названием «Movable Type», если кто такой помнит. Соорудить сайт на hugo оказалось на удивление несложно — в отличие от JS-фреймворков, у движка большое сообщество и немало прилично выглядящих шаблонов. При этом те же сервисы CI/CD позволяют собирать сайт и на базе hugo — опять же, только укажи им репозиторий и вперед.

В общем, я в итоге соорудил такой сайт. Правда, в процессе понял, что скорость публикации меня устраивает еще меньше — на этот раз работа шла с полными данными и сборка сайта занимала примерно 15-20 минут. Правда, кажется, это особенность как раз конкретных сервисов — они заводились от изменений в репозитории, клонировали весь репозиторий целиком, потом, видимо, собирали необходимое окружение, генерировали весь сайт и начинали его деплоить, загружая собственно на хостинг. Но даже локальная сборка у меня на ноутбуке занимала 70 секунд, пересобирая весь сайт — не очень понятно, зачем это делать, если добавляется один пост, например, что отражается примерно в пяти файлах максимум. Это удручает — вы написали текст, обнаружили орфографическую ошибку уже на готовом сайте и теперь её исправление займет 20 минут.

Впрочем, когда я решил попробовать что-то туда написать, стало еще печальнее. Вы помните, я говорил о богатых возможностях Wordpress — причем, очень большую часть в них занимают возможности редактора. Так вот, практически единственный способ создания текстов в данном случае выглядит так — возьмите текстовый редактор и напишите в нем файл со всеми служебными полями. Есть какое-то количество онлайн-редакторов (на самом деле их примерно два), позволяющих ввести текст и как-то его отправить в репозиторий, но их возможности гораздо беднее нынешнего редактора Wordpress, у них какие-то свои настройки, которые еще где-то лежат и при всём это совершенно не факт, что они заработают. Конечно, в мире больших сайтов есть те самые Headless CMS типа Strapi или Contentful, но они сами по себе или платные, или требуют отдельной установки и это перестает помещаться в рамки персонального блога.

Переходя на статический сайт, возникает еще одна проблема — что делать с комментариями? Они, во-первых, есть за все эти годы, и, во-вторых, я надеюсь, еще будут. Чтобы их как-то включить на статических страницах, требуется использовать что-то типа disqus или даже remark42 от нашего уважаемого Umputun-а. Но это либо еще один комплекс для установки и настройки, либо сторонний сервис. Кроме того, установка disqus моментально роняет скорость загрузки — он сам по себе загружает около 400 кБ библиотек, графики и чего-то еще. И вся затея по оптимизации сайта становится немного бессмысленной.

В общем, как я уже всё названием, я решил, что вся эта технология еще не готова к тому, чтобы переносить на неё мой блог. Хотя это, конечно, прикольно и можно поиграться, развивая любознательность, но, если хочется именно писать тексты, а не разрабатывать блог — пока ничего лучше Wordpress нет.

Впрочем, если у вас есть какой-то особенный способ решить те проблемы, которые я описал — делитесь, с удовольствием попробую.