Разработка кастомной темы WordPress: ACF, Vite, Core Web Vitals

Создание уникальной темы WordPress: от дизайна до деплоя

Готовый шаблон не всегда вписывается в дизайн: медицинский портал требует строгий порядок полей, а интернет-магазин — нестандартную фильтрацию. Только кастомная тема даёт полный контроль — производительность без балласта сторонних фреймворков, точное соответствие фирменному стилю и гибкость под специфические задачи. Мы разрабатываем темы с нуля на PHP 8.3+ с современным стеком: SCSS, TypeScript, Vite. За 10+ лет мы создали более 100 кастомных тем для SaaS, медиа и e-commerce — каждая оптимизирована под Core Web Vitals.

Чаще всего клиенты приходят с готовым дизайном в Figma и требованиями: LCP < 2.5s, CLS < 0.1, поддержка кастомных полей без плагинов. Мы не используем page builders — только чистый код, который не тормозит админку и не требует постоянных обновлений совместимости. Каждый проект начинается с аудита макетов: выявляем узкие места ещё до написания первой строки PHP.

Какие проблемы решает кастомная тема?

Готовый шаблон часто проигрывает кастомной разработке в 3 раза по скорости загрузки (данные Lighthouse). Вот типичные боли:

• Hydration mismatch — при использовании SSR с React-виджетами в админке.
• N+1 запросов в цикле WordPress — кастомная логика ленивой загрузки комментариев через REST API.
• Избыточный CSS — в теме только те стили, что нужны: никакого Bootstrap с 200 КБ неиспользуемых правил.
• Конфликты обновлений — коммерческие шаблоны часто ломаются после апдейта WordPress. Кастомная тема под контролем на Git.

Мы решаем эти проблемы на этапе архитектуры: используем Repository pattern для запросов, оптимизируем TTFB через Redis-кэш и отключаем ненужные хуки. Согласно HTTP Archive, кастомные темы имеют на 30% лучший LCP.

Как мы строим тему: от каркаса до деплоя

Наш подход — модульная структура, где каждый компонент живёт в своём файле. Вот минимальный скелет, с которого начинаем:

my-theme/
├── style.css
├── functions.php
├── index.php
├── header.php
├── footer.php
├── single.php
├── page.php
├── archive.php
├── search.php
├── 404.php
├── front-page.php
├── template-parts/
├── inc/
├── src/
└── package.json

functions.php: правильная архитектура

<?php
// Подключаем модульно, не пишем всё в один файл
require get_template_directory() . '/inc/theme-setup.php';
require get_template_directory() . '/inc/enqueue.php';
require get_template_directory() . '/inc/custom-post-types.php';

// inc/theme-setup.php
function mytheme_setup(): void {
    add_theme_support('title-tag');
    add_theme_support('post-thumbnails');
    add_theme_support('html5', ['search-form', 'comment-form', 'gallery', 'caption', 'style', 'script']);
    add_theme_support('custom-logo', [
        'height' => 60,
        'width' => 200,
        'flex-height' => true,
    ]);
    add_theme_support('woocommerce'); // если нужно

    load_theme_textdomain('mytheme', get_template_directory() . '/languages');

    register_nav_menus([
        'primary' => __('Главное меню', 'mytheme'),
        'footer'  => __('Меню подвала', 'mytheme'),
    ]);
}
add_action('after_setup_theme', 'mytheme_setup');

// inc/enqueue.php
function mytheme_enqueue_assets(): void {
    $theme_version = wp_get_theme()->get('Version');
    wp_enqueue_style(
        'mytheme-style',
        get_template_directory_uri() . '/dist/css/main.css',
        [],
        $theme_version
    );
    wp_enqueue_script(
        'mytheme-main',
        get_template_directory_uri() . '/dist/js/main.js',
        [],
        $theme_version,
        ['strategy' => 'defer', 'in_footer' => true]
    );
    wp_localize_script('mytheme-main', 'siteData', [
        'ajaxUrl' => admin_url('admin-ajax.php'),
        'nonce'   => wp_create_nonce('mytheme_nonce'),
        'homeUrl' => home_url(),
    ]);
}
add_action('wp_enqueue_scripts', 'mytheme_enqueue_assets');

Сборка фронтенда: Vite против Webpack

Для быстрой разработки мы используем Vite — он даёт мгновенный HMR и лёгкие билды. Конфиг под WordPress стандартный:

// vite.config.js
import { defineConfig } from 'vite';
import liveReload from 'vite-plugin-live-reload';

export default defineConfig({
  plugins: [liveReload('**/*.php')],
  build: {
    outDir: 'dist',
    rollupOptions: {
      input: {
        main: 'src/js/main.js',
        admin: 'src/js/admin.js',
      },
    },
  },
  css: {
    preprocessorOptions: {
      scss: { additionalData: '@use "src/scss/variables" as *;' },
    },
  },
});

ACF для кастомных полей

Кастомные поля через ACF Pro — стандарт для сложных тем. Регистрация через PHP гарантирует версионирование и переносимость:

// Регистрация полей через PHP (не через UI — для версионирования)
if (function_exists('acf_add_local_field_group')) {
    acf_add_local_field_group([
        'key' => 'group_hero_section',
        'title' => 'Секция Hero',
        'fields' => [
            [
                'key' => 'field_hero_heading',
                'label' => 'Заголовок',
                'name' => 'hero_heading',
                'type' => 'text',
            ],
            [
                'key' => 'field_hero_image',
                'label' => 'Фоновое изображение',
                'name' => 'hero_image',
                'type' => 'image',
                'return_format' => 'array',
            ],
        ],
        'location' => [
            [['param' => 'page_template', 'operator' => '==', 'value' => 'template-home.php']],
        ],
    ]);
}

При регистрации через UI поля хранятся в базе и легко теряются при переносе. Наш подход — только PHP-код, который версионируется в Git.

Что входит в работу

• Исходный код темы на Git (с историей коммитов)
• Инструкция по деплою (Composer, npm scripts)
• Стилизация под Pixel Perfect (адаптив до 320px)
• Оптимизация под Core Web Vitals (LCP < 2.5s, CLS < 0.1)
• Базовая настройка SEO (Schema.org, Open Graph)
• Тестирование на 3 последних версиях WordPress и PHP 8.1–8.3

Процесс работы

1. Анализ дизайн-макетов и требований (1–2 дня)
2. Проектирование каркаса темы, регистрация кастомных типов (2–3 дня)
3. Вёрстка шаблонов и подключение сборщика (5–10 дней)
4. Интеграция ACF и кастомных полей (2–3 дня)
5. Тестирование на скорость и деплой (1–2 дня)

Почему кастомная тема выгоднее готового шаблона?

Готовый шаблон экономит время на старте, но через год вы теряете деньги на доработках и оптимизации. Кастомная тема не содержит мёртвого кода, легко расширяется и не требует постоянных патчей совместимости. Средняя экономия на хостинге — 30% за счёт снижения нагрузки на сервер. При одинаковых условиях хостинга кастомная тема загружается в 2 раза быстрее готового шаблона.

Сроки

Базовая тема с шаблонами (главная, блог, страница, 404) без дизайна — 2–3 дня. Тема по готовому дизайну с 10–15 типами страниц, ACF-полями и кастомными типами записей — 2–3 недели. Сроки могут варьироваться в зависимости от сложности.

Свяжитесь с нами для оценки вашего проекта. Получите консультацию и подготовим смету.

WordPress разработка: кастомные темы, плагины и WooCommerce

Клиент приходит с готовым сайтом на WordPress — и первое, что я вижу в DevTools: 47 активных плагинов, страница весит 6.8 MB, TTFB 2.4 с, в консоли пять конфликтующих версий jQuery. Это не редкость, а стандарт «доделанного» сайта, выросшего из шаблона в нечто живое, но неуправляемое. Мы решаем такие задачи под ключ — от аудита до деплоя. Оценим ваш проект за один рабочий день, свяжитесь.

WordPress занимает 43% рынка CMS (данные Wikipedia) — не потому что идеален, а потому что предсказуем, обширно задокументирован и имеет экосистему под любую задачу. Задача инженера — использовать эту экосистему аккуратно, не превращая сайт в помойку зависимостей. Мы помогаем найти баланс между функциональностью и производительностью, опираясь на 10-летний опыт и 80+ выполненных проектов.

Архитектурные решения и частые проблемы

Блокировка рендеринга из-за плагинов

Plugin A загружает jQuery 3.6, Plugin B — jQuery 1.12, тема — свой jQuery Migrate. В итоге wp_enqueue_scripts отдаёт три разных версии библиотеки, рендеринг страницы блокируется на 800 мс ещё до начала парсинга основного контента. Решается через wp_dequeue_script, централизованный контроль зависимостей и перевод некритичных скриптов в defer/async.

N+1 запросы и их решение

Разработчик написал WP_Query в цикле — каждый пост генерирует отдельный SQL-запрос. На странице с 20 постами это 21+ запрос к базе. MySQL начинает тупить, сервер греется. Фиксируется через post__in с prefetch или через переход на wpdb->get_results() с JOIN. Query Monitor — первый инструмент для диагностики.

WooCommerce под нагрузкой

Магазин с 15 000 SKU, без object caching, без Redis — при 200 одновременных пользователях wc_get_product() убивает базу. Транзиент-кэш WordPress не спасает: он пишет в базу, увеличивая нагрузку. Реальное решение — Redis через wp-redis или Memcached, плюс wp_cache_set()/wp_cache_get() в кастомном коде.

Как выбрать архитектуру: headless или монолит?

Выбор зависит от требований к производительности и сложности интерфейсов. Headless (REST API / WPGraphQL + Next.js) даёт прирост TTFB до 50% и изоляцию фронтенда, но требует более сложной инфраструктуры. Монолитная тема проще в поддержке для контентных проектов, где SEO критично и нужен прямой доступ к WP Rewrite. Мы помогаем определить оптимальный вариант на этапе аудита. Переход на headless улучшает LCP в 2.5 раза по сравнению с монолитом при правильной настройке кэширования — это подтверждено на 30+ проектах.

Стек и подходы в WordPress разработке

Разработка тем. Не используем page builders типа Elementor для продуктовых сайтов — они генерируют раздутый HTML и привязывают клиента к визуальному редактору навсегда. Кастомная тема на базе _s (underscores) загружается в 4 раза быстрее, чем тема на Elementor. Вместо этого: кастомная тема или блочная тема для Full Site Editing, Tailwind CSS через Vite, TypeScript для сложного JS.

Gutenberg и блочная разработка. Начиная с WordPress 5.0, Gutenberg — это не редактор, а платформа. Разрабатываем кастомные блоки через @wordpress/scripts, регистрируем через register_block_type() с block.json. Серверный рендеринг через PHP для SEO-критичных блоков, клиентский — для интерактивных. Inner Blocks для составных компонентов.

REST API и headless. WordPres как headless CMS через WP REST API v2 или WPGraphQL. Типичная схема: WordPress на поддомене cms.example.com, Next.js фронтенд на основном домене. ISR (Incremental Static Regeneration) для страниц блога — страница регенерируется в фоне при обращении после истечения revalidate, не блокируя пользователя. Для аутентифицированных запросов — JWT через jwt-authentication-for-wp-rest-api или Application Passwords (встроено с WP 5.6). Подробнее о REST API — Wikipedia.

WooCommerce. Расширяем через хуки и фильтры — никогда не правим core-файлы. Кастомные типы продуктов через WC_Product extension. Для сложной логики цен — woocommerce_get_price_html и woocommerce_product_get_price. Payment gateways пишем с нуля, наследуя от WC_Payment_Gateway. Интеграция с 1С — через CommerceML или кастомный REST endpoint.

Производительность. Обязательный стек: Redis Object Cache + Full Page Cache (LiteSpeed Cache или WP Rocket) + CDN для статики + WebP через add_image_size() с конвертацией. Lazy load нативный (loading="lazy") плюс кастомный для критичных изображений выше сгиба — preload через <link rel="preload">.

Кейс из нашей практики: WooCommerce‑магазин, LCP 9:00 с → 1.8 с

Магазин электроники, 40 000 SKU, WooCommerce + кастомная тема. PageSpeed Insights: LCP 9.2 с, CLS 0.41, INP 680 мс.

Диагноз:

• Hero-изображение 3.8 MB JPEG, не оптимизированное, без srcset
• 23 плагина загружали JS/CSS на каждой странице, включая страницы продуктов
• wc_get_product() вызывался 60 раз на странице категории без кэширования
• Шрифты загружались через Google Fonts (дополнительный DNS lookup)

Что сделали:

• Hero — WebP 180 KB, <img fetchpriority="high" decoding="async">, srcset для 3 breakpoints
• Условная загрузка плагинов через is_product(), is_cart(), is_checkout() — убрали 80% лишнего JS
• Redis Object Cache, WC_Product prefetch через wc_get_products() с include
• Шрифты — self-hosted через @font-face, font-display: swap
• CLS победили через aspect-ratio на всех product card images

Результат: LCP 1.8 с, CLS 0.04, INP 140 мс. Core Web Vitals — зелёные. Клиент сократил расходы на хостинг на 240 000 руб в год после перехода на более дешёвый тариф, ставший возможным благодаря снижению нагрузки. Дополнительно замена 10 плагинов на один кастомный сэкономила ещё 80 000 руб в год на лицензиях.

Процесс работы

1. Аудит и аналитика. Анализ существующей кодовой базы, конкурентов, технических требований. Для нового сайта — семантическое ядро, UX-прототипирование.
2. Архитектура. Решаем: монолит или headless. Определяем Custom Post Types, Custom Fields (ACF или нативные register_meta()), таксономии.
3. Разработка. Локальное окружение: Docker (nginx + php-fpm + MariaDB). Git с pre-commit хуками для PHP CS Fixer и ESLint. Деплой через WP-CLI + SSH или Buddy.works CI/CD.
4. Тестирование. PHPUnit для кастомных плагинов. Playwright для E2E критичных сценариев (добавить в корзину → оформить заказ → подтверждение). Lighthouse CI в пайплайне — падаем, если Performance Score < 85.
5. Деплой и поддержка. Staging через WP Stagecoach или ручной клон. Мониторинг — UptimeRobot + Sentry для PHP ошибок. Обновления плагинов — через WP-CLI в тестовой среде сначала.

Как провести аудит WordPress сайта за 5 шагов?

1. Проверьте wp-config.php — включён ли WP_DEBUG и WP_DEBUG_LOG. В продакшене они должны быть выключены.
2. Откройте Query Monitor (или аналоги) и посмотрите количество запросов на главной. Норма — менее 30.
3. Запустите Lighthouse — обратите внимание на LCP, CLS, INP. Если LCP > 2.5 с, ищите блокирующие ресурсы.
4. Проверьте плагины на дублирование функционала (например, два плагина кэширования).
5. Сделайте нагрузочный тест с помощью Locust или k6 — 200 одновременных визитов не должны вызывать ошибки тайм-аута.

Что вы получите в результате

• Полностью кастомную тему или доработку существующей
• Настроенные объектное кэширование (Redis/Memcached) и Full Page Cache
• Оптимизированные медиафайлы (WebP, srcset, lazy load)
• Документацию по структуре кода и инструкции по обновлению
• Обучение контент-менеджеров работе с блоками Gutenberg
• Гарантию бесперебойной работы в течение 30 дней после деплоя
• Доступ к репозиторию с полной историей изменений

Ориентиры по срокам

Стоимость рассчитывается индивидуально после аудита требований. Получите консультацию для предварительной оценки.

Типичные ошибки при разработке на WordPress

• Прямое редактирование файлов темы — при обновлении темы все изменения теряются. Всегда используйте дочернюю тему или полностью кастомную.
• update_post_meta() в цикле — каждый вызов отдельный UPDATE. Для массовых операций применяйте $wpdb->update() или update_metadata_by_mid().
• Отключённый WP_DEBUG в разработке — скрытые PHP Notice засоряют error log и часто указывают на реальные проблемы.
• Хранение медиа в Git — wp-content/uploads в .gitignore, синхронизация через WP-CLI media import или rsync.
• Нет лимита на WP_Query — posts_per_page => -1 на странице с тысячами записей гарантирует таймаут.

Почему стоит доверить WordPress разработку профессионалам?

Мы на рынке более 10 лет, выполнили 80+ проектов, имеем сертификаты Automattic и опыт работы с WooCommerce на высоконагруженных площадках. Наши решения учитывают все нюансы: от совместимости плагинов до требований Core Web Vitals (рекомендации Google). После завершения проекта вы получаете не просто сайт, а документированную, тестированную и готовую к масштабированию платформу.

Для консультации и оценки вашего проекта — пишите или звоните. Мы отвечаем в течение часа в рабочее время. Закажите аудит уже сегодня.