zhan.blog 
В начале лета я решил немного пересмотреть свой привычный подход к разработке WordPress-сайтов.
Первым шагом стал переход на Vite в качестве инструмента сборки. Об этом я уже писал небольшую заметку — «Почему я решил перейти на Vite».
Параллельно я начал постепенно отказываться от jQuery и переходить на обычный JavaScript. Причины этого решения тоже описывал отдельно — «Почему я постепенно отказываюсь от jQuery в WordPress».
Прошло несколько месяцев, и теперь уже можно подвести первые итоги.
Vite и Vanilla JS стали привычнее
В начале всё это казалось немного непривычным.
Я много лет работал со своей устоявшейся структурой WordPress-тем, использовал привычные инструменты и постепенно наращивал их различными доработками.
Когда начинаешь менять сразу несколько фундаментальных вещей, неизбежно появляются проблемы.
Что-то работало не совсем корректно, где-то возникали ошибки, какие-то решения приходилось переделывать. Особенно много вопросов было вокруг того, как правильно организовать работу Vite в WordPress: отдельно для разработки и отдельно для production.
Но сейчас я уже более-менее набил руку.
И самое главное — Vite и ванильный JavaScript перестали казаться чем-то сложным. Я уже понимаю, как лучше организовать структуру проекта, куда что вынести и как сделать так, чтобы это было удобно поддерживать в дальнейшем.
Пришлось полностью переписать заготовку для кастомных тем
Одним из главных минусов перехода на новый подход стало то, что пришлось практически с нуля переписать структуру своей заготовки для кастомных WordPress-тем.
Но, если честно, сейчас я считаю это скорее плюсом, чем минусом.
Старую структуру я практически не менял около пяти лет.
За это время в неё добавлялись различные небольшие улучшения, новые функции и отдельные доработки, но фундаментально она оставалась практически такой же.
А когда начинаешь проектировать всё заново, появляется возможность посмотреть на старые решения свежим взглядом и понять, что действительно необходимо, а от чего уже давно можно было отказаться.
В результате я сделал новую заготовку для кастомных тем с поддержкой Vite.
Dev и production
Одной из задач было сделать нормальное разделение между разработкой и production.
В dev-режиме Vite должен работать как положено: запускаться dev-сервер, использоваться исходные файлы, а изменения должны сразу отображаться во время разработки.
На production-сайте всё должно работать иначе.
После сборки Vite создаёт manifest.json, и WordPress получает информацию о скомпилированных CSS и JavaScript-файлах именно из него.
Таким образом, одна и та же заготовка позволяет нормально работать и во время разработки, и после публикации проекта.
Для меня это оказалось одним из самых важных изменений в новой структуре.
Полное отключение jQuery
Ещё одним изменением стало то, что в своей заготовке для кастомных тем я полностью отключил jQuery.
Если проект действительно не требует jQuery, то я не вижу большого смысла загружать его просто потому, что WordPress исторически с ним работает.
Весь собственный JavaScript теперь стараюсь писать на Vanilla JS.
Поначалу после jQuery некоторые вещи действительно приходилось делать немного иначе. Особенно когда привык к определённому синтаксису и подходу.
Но со временем это перестало быть проблемой.
Сейчас для большинства задач обычного JavaScript более чем достаточно.
И при этом не нужно тянуть дополнительную библиотеку только ради нескольких простых операций с DOM, событиями или запросами.
Мобильная вёрстка стала отправной точкой
Ещё одна вещь, которую я начал делать чаще, — верстать по принципу Mobile First.
Раньше я далеко не всегда строго придерживался этого подхода.
Сейчас стараюсь сначала продумать мобильную версию, а уже потом расширять её для планшетов и десктопов.
На мой взгляд, это действительно немного ускорило работу.
Когда сначала решаешь задачу для небольшого экрана, а затем постепенно добавляешь возможности для больших разрешений, структура CSS получается более понятной.
Да и сейчас мобильная версия сайта уже давно не является какой-то второстепенной.
PageSpeed Insights
И вот здесь получилось интересное наблюдение.
После перехода на новую структуру я заметил, что при тестировании сайтов в PageSpeed Insights оценки стали заметно лучше.
Причём речь именно о базовом результате — без каких-то дополнительных плагинов кэширования и серьёзной оптимизации.
Конечно, сам по себе переход на Vite или Vanilla JS не превращает сайт автоматически в сверхбыстрый.
На итоговую оценку влияет огромное количество факторов: изображения, шрифты, сервер, сторонние скрипты, структура страницы, CSS, JavaScript и многое другое.
Но когда из проекта убирается часть ненужных зависимостей и появляется более контролируемая сборка ресурсов, это определённо помогает.
Для меня это стало приятным бонусом.
Прощай, Owl Carousel
Ещё одна вещь, от которой я решил отказаться, — Owl Carousel.
Owl Carousel 2 я использовал довольно долго, и в своё время это был удобный инструмент.
Но практика одного из проектов показала интересный момент.
Если в какой-то момент возникает задача серьёзно поднять показатели в PageSpeed Insights, Owl Carousel может стать одной из тех вещей, которые начинают мешать.
И тогда приходится искать дополнительные решения, чтобы уменьшить его влияние на производительность.
Поэтому я решил посмотреть в сторону другой библиотеки.
Embla Carousel
В итоге перешёл на Embla Carousel.
Пока впечатления от неё очень хорошие.
Она достаточно простая, хорошо настраивается и при этом не заставляет тянуть за собой огромное количество дополнительной логики.
Но для меня особенно важен ещё один момент — при тестировании PageSpeed Insights я не столкнулся с теми проблемами, которые возникали с Owl Carousel.
Поэтому сейчас для новых проектов предпочитаю именно Embla.
И немного GSAP
Ещё один инструмент, который начал постепенно добавлять в свои проекты, — GSAP.
Пока использую его только в нескольких местах.
Не хочется добавлять анимации просто ради самих анимаций. Если обычного CSS достаточно — лучше использовать CSS.
Но там, где нужна более сложная последовательность анимаций, управление несколькими элементами или более интересные интерактивные эффекты, GSAP оказывается очень удобным.
Думаю, в будущем буду использовать его чаще — там, где это действительно имеет смысл.
Что в итоге?
Если посмотреть на всё это спустя несколько месяцев, я доволен тем, что решил всё-таки поменять привычный подход.
Сейчас у меня есть новая заготовка для кастомных WordPress-тем, в которой:
- используется Vite;
- есть отдельный dev-режим;
- production использует данные из
manifest.json; - собственные CSS и JavaScript собираются через Vite;
- jQuery полностью отключён;
- структура темы стала более расширяемой;
- для каруселей используется Embla Carousel;
- постепенно появляется GSAP;
- а вёрстку я всё чаще начинаю строить по принципу Mobile First.
И самое главное — всем этим стало проще пользоваться.
В начале было много вопросов и моментов, которые приходилось буквально разбирать по частям. Сейчас большая часть этого уже стала привычной.
Мой блог — zhan.page — как раз сделан на этой новой заготовке.
Конечно, это не означает, что на этом всё закончено.
Наоборот, теперь хочется дальше развивать эту структуру, пробовать новые подходы и постепенно улучшать её.
Так что буду и дальше лучше знакомиться с Vite, Vanilla JS и GSAP.
Посмотрим, куда это приведёт дальше.
