Custom 1C-Bitrix Site Template Development from Scratch

Our experience shows: standard templates from the Bitrix Marketplace solve no more than 20% of real business tasks. The remaining 80% require custom work: unique design, non-standard page structure, specific performance requirements, or integration with external systems. Developing a template on top of a ready-made Marketplace one is a path to technical debt: foreign styles and scripts conflict, and template updates overwrite edits. Over 8 years we have created more than 50 custom templates for various industries — from online stores to B2B portals. Each project begins with a business requirements audit and selection of the optimal template architecture. This guarantees no overpayment for unnecessary functionality and high development speed. Below are technical details to help you make a decision.

Why Abandon a Ready-Made Template

A ready-made theme from the Marketplace is a compromise. You pay for functionality that is often unnecessary and get code that is difficult to adapt. A custom template is written for specific business processes: integration with 1C via API, complex access rights for dealers, individual fiscalization under 54-FZ. We guarantee that such a template will not require rewriting in a year. Support cost savings amount to up to 30% compared to constant modifications of a ready-made solution. Over 3 years of ownership, a custom template saves more than 500,000 rubles on maintenance, and development pays off in 6 months.

Impact on Performance

A custom template without extra modules and styles is typically lighter and faster. We include only necessary CSS/JS, use modern bundlers (Vite, Webpack) with tree-shaking, and implement tagged caching — this yields up to 40% speed improvement compared to typical solutions. Thanks to managed caching via CPHPCache and managed_cache, page load times under high load are reduced by 2-3 times. We also optimize header.php and footer.php which render on every request, minimizing their weight.

Custom Template Structure

A custom template is created in /local/templates/<template_name>/. Using /local/ is crucial: this folder is not affected by Bitrix updates. Minimal structure:

/local/templates/main/
  header.php    — site header, CSS/JS inclusion
  footer.php    — footer, closing tags
  styles.css    — main styles (or build inclusion)
  script.js     — main scripts
  .parameters.php — template settings (optional)
  components/   — component template overrides
  page_templates/ — page type templates
  images/       — template images

In header.php, resources are included via $APPLICATION->SetAdditionalCSS() and $APPLICATION->AddHeadScript(). For modern projects we use a bundler (Vite, Webpack) outputting to the template folder.

Asset Pipeline for Resource Inclusion

Bitrix supports two approaches. First is native: CUtil::InitJSCore(), Asset::getInstance()->addJs(). Files are served directly, concatenation is possible via the main module settings. Second is via a bundler: npm run build generates minified bundles into /local/templates/main/assets/. In header.php, the final file is included. This approach is preferred: tree-shaking, PostCSS, modern JS with transpilation. For projects with Vue or React in the frontend, the Bitrix template acts as a shell: renders HTML containers and passes data via <script> with JSON assembled from $arResult components.

Page Types in the Template

In the page_templates/ folder, PHP files with different page layouts are stored. For example: layout-fullwidth.php (without sidebar), layout-sidebar.php (with side column), layout-landing.php (without header/footer for landing pages). The editor selects the page type in the admin panel. This allows one template to cover different page structures without code duplication.

Case Study: B2B Portal Template

A manufacturing company (our client), Bitrix "Business". Requirements: dealer personal account with individual prices, catalog without public access, integration with 1C via API. The standard template was unsuitable — a custom navigation based on user groups was needed. We developed a template from scratch in /local/templates/b2b/. In header.php — authorization check via $USER->IsAuthorized(), for unauthorized users — redirect to login page. Navigation dynamically built via bitrix:menu with a custom template showing menu items based on user group. Styles — Tailwind CSS via PostCSS, Vite build. Result: template from scratch in 3 weeks, including templates for main catalog components and personal account.

Considerations During Development

• Edit mode — when the admin panel is on, Bitrix adds overlays for content editing. The template must work correctly with bx-editmode-overlay classes.
• SEO meta — $APPLICATION->SetTitle(), $APPLICATION->SetKeywords(), $APPLICATION->SetDescription() are called in components; the template must output them in <head> via appropriate methods.
• Caching — managed_cache and CPHPCache cache component output, but not header.php/footer.php — they render on every request.
• Security — the template must not contain direct SQL queries; all data through Bitrix API.

According to official documentation, a template in /local/ is not affected by updates, confirming its long-term stability.

Comparison: Custom vs Ready-Made Template

Development Timelines

Our Process

1. Requirements analysis — gather specifications, study integrations, measure loads, define page types.
2. Design — create file structure prototype, template mockup, select stack (bundler, CSS framework).
3. Implementation — write header.php/footer.php, configure Asset Pipeline, create page_templates, override necessary components.
4. Testing — verify on all page types, in different browsers, with different access rights.
5. Deployment and documentation — upload to production server, provide instructions for modifications.

What’s Included in Deliverables

• Full template archive with file structure.
• Documentation on connection and customization.
• Configured caching and performance optimization.
• Guarantee of correct operation after Bitrix updates.
• Free consultation on modifications within a month after delivery.

To evaluate a project, just describe the task — we will determine complexity and propose the optimal solution. Contact us to discuss your project. We guarantee transparent timelines and full compliance with the technical specification. Experience with over 50 successfully implemented templates is your insurance against missed deadlines. Get a consultation right now.

Additional information: the concept of website templates is described in the Wikipedia article. For an in-depth study of Bitrix capabilities, we recommend the official documentation.

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.