Nuxt.js Frontend Development for 1С-Bitrix

We often encounter this situation: a catalog on a standard Bitrix template loads in 5–7 seconds, LCP goes through the roof, and SEO traffic drops due to Core Web Vitals. Clients complain about slowness, and editing the template is a pain. The solution is headless architecture: Bitrix stays as the backend, and the frontend is written in Nuxt.js. This is a real way to achieve LCP < 1.8 sec and full indexing without rewriting business logic. Get a consultation and receive a migration plan.

Advantages of Headless Bitrix with Nuxt

A classic Bitrix template is a monolith: PHP rendering, HTML concatenation, and a common TTFB > 1 sec. Nuxt.js (Vue 3 with SSR) offers hybrid rendering: static pages (SSG), dynamic ones via SSR, and for the catalog — SWR cache. Result: TTFB drops to 180–250 ms, LCP to 1.8 sec. Our projects show a conversion increase of 20–30% after migration.

How Does ISR Improve Catalog Performance?

ISR (stale-while-revalidate) is 5x faster than no caching: TTFB < 200 ms instead of >1 sec. Background revalidation ensures fresh data without blocking page load.

Why Choose Nuxt Over Bitrix Templates?

Nuxt.js is 3x more performant for dynamic pages due to virtual DOM reconciliation and edge-side caching. Development speed increases by 40% thanks to component-based architecture and Pinia state management.

Speeding Up Bitrix Interface Development by 2x

Nuxt eliminates the routine of working with Bitrix templates. The component-based approach of Vue 3 + Pinia for state + file-based routing — new section development is 40% faster. Here is our typical implementation.

Architecture of a Nuxt Application for Bitrix

Nuxt 3 uses the Vue Composition API and its own caching system (useAsyncData, useFetch). Routing is file-based, similar to Next.js. SSR, SSG, ISR (called hybrid rendering in Nuxt) — all modes are available.

// pages/catalog/[slug].vue
<script setup lang="ts">
const route = useRoute();

const { data: category } = await useFetch(
  `/api/catalog/category/${route.params.slug}`,
  {
    key:      `category-${route.params.slug}`,
    server:   true,
    lazy:     false,
  }
);

const { data: products } = await useFetch('/api/catalog/products', {
  query:  { section: route.params.slug, limit: 24 },
  key:    `products-${route.params.slug}`,
  server: true,
});

useHead({
  title:       category.value?.name,
  meta: [
    { name: 'description', content: category.value?.description },
    { property: 'og:title',       content: category.value?.name },
    { property: 'og:description', content: category.value?.description },
  ],
});
</script>

useFetch in Nuxt 3 automatically deduplicates requests — the same call made on the server during SSR is not repeated on the client during hydration. This reduces unnecessary network traffic.

Server Routes as a Proxy to Bitrix

Nuxt 3 includes a built-in H3 server with server routes (server/api/). This creates a proxy layer directly in Nuxt without a separate backend service. Bitrix tokens never reach the browser, CORS is not an issue. We use this scheme in 90% of projects.

// server/api/catalog/products.get.ts
export default defineEventHandler(async (event) => {
  const query = getQuery(event);

  const response = await $fetch(
    `${process.env.BITRIX_URL}/local/ajax/api.php`,
    {
      method: 'POST',
      body: {
        action: 'catalog.products.list',
        ...query,
      },
      headers: {
        'X-Bitrix-Token': process.env.BITRIX_API_TOKEN,
      },
    }
  );

  return {
    items: response.data.map(normalizeProduct),
    total: response.total,
  };
});

State Management with Pinia

// stores/cart.ts
export const useCartStore = defineStore('cart', () => {
  const items   = ref<CartItem[]>([]);
  const isLoading = ref(false);

  async function addToCart(productId: number, quantity: number) {
    isLoading.value = true;
    try {
      const result = await $fetch('/api/cart/add', {
        method: 'POST',
        body:   { productId, quantity },
      });
      items.value = result.items;
    } finally {
      isLoading.value = false;
    }
  }

  const total = computed(() =>
    items.value.reduce((sum, item) => sum + item.price * item.quantity, 0)
  );

  return { items, isLoading, total, addToCart };
});

Pinia is the official state manager for Vue 3, simpler than Redux, integrates with Vue DevTools, and supports SSR.

Case Study: Construction Portal

One of our clients is a large construction services portal with 12,000 companies, ratings, and a tender module. Bitrix was used for content management. We proposed a headless architecture with Nuxt 3. The main challenge: SEO for contractor pages with frequent updates. SSG was not possible, SSR with cache was optimal.

Implementation:

1. Nuxt 3 with hybrid rendering: contractor pages — SSR + Redis cache (5 minutes), static pages — SSG.
2. Nuxt server routes: proxy to Bitrix REST API with useStorage('redis') cache.
3. Contractor search — Vue component with instant search via Typesense. On update, Bitrix triggers a webhook → Node.js service updates Typesense.
4. Tender module — SPA inside Nuxt: bidding, authorization via JWT.

The project was delivered in 5 months, and the client continues cooperation.

Comparison of Approaches

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/catalog/**':  { swr: 300 },
    '/company/**':  { swr: 180 },
    '/about':       { prerender: true },
    '/cart/**':     { ssr: false },
  }
});

Deployment and Infrastructure

Nuxt 3 is deployed as a Node.js server, statically, or on edge functions. For a combined setup with Bitrix on one server — Node.js + PM2 + nginx:

server {
    server_name shop.example.ru;

    location /bitrix/  { proxy_pass http://127.0.0.1:8080; }
    location /upload/  { proxy_pass http://127.0.0.1:8080; }
    location /local/ajax/ { proxy_pass http://127.0.0.1:8080; }
    location /         { proxy_pass http://127.0.0.1:3000; }
}

Process and What's Included

1. Analytics — audit of the current Bitrix template, API, data structure. Identify bottlenecks.
2. Design — headless layer architecture, API schema, Nuxt routes, caching.
3. Development — server routes (proxy), Vue/Nuxt components, Pinia stores, routeRules configuration.
4. Testing — SSR rendering, Core Web Vitals, indexing, integration tests.
5. Deployment — Node.js + nginx, PM2 cluster, monitoring.

Scope of work:

• Designing Bitrix API for Nuxt consumption.
• Developing Nuxt server routes (proxy + cache).
• Developing Vue/Nuxt components: catalog, card, search, cart.
• Configuring hybrid rendering: routeRules for different page types.
• Pinia stores: cart, auth, wishlist.
• Deploying Node.js + nginx, setting up PM2 cluster.
• API and architecture documentation.
• Training your team on headless frontend.
• 3 months warranty after delivery.

Timeline and Cost

Timeline is comparable to Next.js — MVP 2–3 months, full project 4–6 months. Cost is calculated individually after an audit. Typical migration projects start at $15k and can save you 30-40% on future feature development. If you want to improve the performance of your Bitrix website, contact us for an audit. We will help you transition to a modern architecture.

With 8 years of experience in Bitrix development and 50+ successful headless migrations, our team ensures reliable delivery and measurable results. We have completed projects for e-commerce, portals, and enterprise systems across industries.

Why does website layout for 1C-Bitrix require professionalism?

Open template.php from a previous contractor — and you find SQL queries, business logic, and inline styles all in one file. On almost every second project we take over for support, the template code looks like a dump: cache doesn't work, adding a new feature means rewriting everything. Fixing such layout can be costly, and lost revenue due to a broken cart during peak season can be substantial. Our team with 10 years of experience strictly separates: logic goes into result_modifier.php or component_epilog.php, presentation into template.php. No CIBlockElement::GetList in templates. This reduces editing time by 30–40% and eliminates common cache-breaking errors. We fixed a similar issue for a client who couldn’t update the ‘Promotions’ block for a month — after setting up tagged cache, updates took minutes instead of days. Want the same results? Get a free audit of your current layout.

How to properly organize component templates?

A custom template is not a single file but a structure of five to six files:

• template.php — only HTML and output of $arResult
• result_modifier.php — data preparation, additional queries
• component_epilog.php — code after caching (counters, dynamic content)
• style.css and script.js — loaded via Asset::getInstance()->addCss() and addJs() (not via <link> — otherwise concatenation breaks)
• .parameters.php — visual editor parameters

Example structure for a catalog:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Typical templates we develop turnkey:

Caching: why does it break and how do we fix it?

Component caching in Bitrix breaks with one mistake: you output a username inside a cached catalog — everyone sees the same name. Solution — use component_epilog.php for dynamic inserts.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) is configured by default. Changed a product — cache clears only for that product, not the entire section. On a project with 50,000 products, this gives a 40% speed boost compared to full reset. Official Bitrix documentation recommends using component_epilog.php for dynamic inserts. Real case. A client complained that everyone saw the same cart on the catalog page. It turned out the previous developer output $_SESSION['BASKET'] inside template.php of the catalog.section component. The component was cached for an hour — the cart was frozen. We moved the output to component_epilog.php and configured tagged cache on sale.basket.basket.line. The page didn’t lose speed, the cart became up-to-date. The damage from a non-working cart during peak season could be huge, while the fix cost was modest. Tagged cache reduces page rebuild time by 50× compared to full reset.

CSS approaches: BEM, Tailwind, or hybrid?

For large projects (30+ templates) we use BEM — .product-card__price, .product-card--featured. Styles are isolated, no conflicts. In Bitrix we don’t touch wrappers with bx-component classes — we wrap our own BEM block inside. On typical tasks (landing pages, admin panels) we use Tailwind 3+ with PurgeCSS — resulting CSS 10–30 KB instead of hundreds. Design tokens in tailwind.config.js lock colors, fonts, spacing in one place. On most projects we use a hybrid: BEM for structural components (catalog, card, checkout), Tailwind for utility items (margins, flex layouts). We agree on the boundary with the team in advance.

How do we achieve Core Web Vitals?

Critical CSS — we extract above-the-fold styles using the critical package, inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". LCP on mobile decreases by 1–1.5 seconds.

Images — the main bottleneck. We use <picture> with WebP and JPEG fallback. loading="lazy" for everything below the fold. width and height explicitly set — CLS = 0. A handler in urlrewrite.php generates WebP on the fly.

Minification and compression. CSS and JS via Vite or Bitrix built-in concatenation. Brotli on nginx (brotli_comp_level 6) — 15–20% more efficient than gzip. Static caching: expires 1y + versioning via query string.

For a catalog of 10,000 products, LCP went from 4.2 s to 2.1 s. Conversions improved by 12% after the speed fix. Want similar results? Order a free audit — we’ll evaluate your current layout and propose specific steps.

Deliverables after layout completion

When you order template development or adaptation, you receive:

• Source files of component templates with separation into template.php, result_modifier.php, epilog
• CSS and JS loaded via Asset — no inline styles
• Configured caching with tags
• Documentation on structure and parameters
• Access to a Git repository with change history
• Training for your developer: how to edit the template without losing upgradeability

We guarantee Core Web Vitals compliance and cross-browser compatibility. Each project is assigned a lead engineer with 10+ years of Bitrix experience.

Process:

1. Analysis of mockups and current project — identify components for rework
2. Structure design — break the page into BEM blocks
3. Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
4. Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
5. Deployment — staging, acceptance, production

At each stage you get intermediate results and can make corrections. Contact our team for a project estimate — we’ll provide a timeline and cost within 1–2 days after receiving mockups.

Common mistakes in Bitrix layout

• SQL queries inside template.php — breaks caching and creates heavy load
• Inline <style> and <script> — breaks Asset concatenation and slows loading
• Missing result_modifier.php — logic mixed with presentation
• Direct $_REQUEST in cached components — user-specific data leaks
• Not using component_epilog.php for dynamic content — entire cache invalidated on each user action

Each mistake has a simple fix — we correct them during development or audit.

Timelines

Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.