A frontend developer delivered static HTML with CSS and JS. Now it needs to become a working Bitrix template where the header is header.php with a dynamic menu via bitrix:menu, the news block is a bitrix:news.list component, and the contact form is bitrix:form.result.new. This is not a mechanical copy-paste: integration requires understanding how Bitrix manages data, cache, and rendering. As noted in the official 1C-Bitrix documentation, correct template integration is key to performance.
We are a team of developers with 10+ years of experience with 1C-Bitrix and have completed over 120 turnkey integrations. Each project starts with a layout audit: we check for jQuery conflicts, Cyrillic identifiers, and incorrect paths. Only then do we proceed to transfer into a template. Our methodology includes preliminary audit, component breakdown, and caching setup. The result is a dynamic site easily editable through the admin panel.
Average integration time is reduced by 30% thanks to our proven methodology, and 95% of projects have no jQuery conflicts after transfer. This approach guarantees stability and performance.
Why correct integration matters
Errors at the integration stage lead to performance issues, unavailability of caching, and conflicts during system updates. For example, if jQuery code is not converted to BX.ready(), scripts may not execute due to library conflict. Incorrect image paths will break display on second-level pages. Proper integration is the foundation for all further site work. Budget savings from fixing such errors can be significant.
What layout integration is
Integration is the conversion of static HTML/CSS/JS into a dynamic Bitrix system. Input: layout files (HTML, CSS, JS, images). Output: a full site template in /local/templates/, where static blocks are replaced with components and data comes from the database. This is a separate technical task that often takes as much time as the layout itself — especially if the frontender did not consider Bitrix specifics. In 80% of cases, the layout requires adjustments to meet platform requirements.
Stages of integration
- Layout audit — checking compatibility with Bitrix, identifying conflicts.
- Splitting HTML into template — dividing into
header.php, footer.php, and component zones.
- Connecting resources — CSS and JS via
$APPLICATION->SetAdditionalCSS(), considering caching.
- Replacing static blocks with components — menu, news, forms.
- Transferring component styles — disabling or overriding default CSS.
- Testing — in browsers and admin panel, checking responsiveness.
How to avoid typical mistakes
Image and file paths — in static layout, relative paths (../images/logo.png) are used; in Bitrix use SITE_TEMPLATE_PATH or absolute paths. Otherwise images won't display on non-root pages.
jQuery conflicts — the layout often brings its own jQuery, Bitrix has its own. Solution: remove the layout's jQuery, use BX.ready() instead of $(document).ready(), or explicitly call jQuery.noConflict().
Cyrillic in IDs and classes — sometimes found in layouts for Bitrix. Bitrix adds its own classes like bx- — they must not conflict with layout names.
Admin panel — when an authorized administrator is present, Bitrix adds a bar at the top (~45px). If the layout has a position: fixed header calculated from the top, take into account the bitrix-admin class on <html>.
More about caching
Bitrix uses tagged caching, which allows storing parts of the page with different validity periods. During integration, it's important to properly configure component caching to avoid data staleness. We use automatic cache invalidation when infoblocks change.
Case: integrating a landing page into a template
From our practice: a marketing agency developed a landing page layout for its client — 8 sections, custom slider, multi-step form, animations on Intersection Observer. The client wanted to edit text via the Bitrix admin panel.
We split the landing page: static sections with text — via bitrix:main.include with editable areas (so the editor could change text without code), the slider — an infoblock plus a custom bitrix:news.list template, the form — bitrix:form.result.new with an overridden template preserving the multi-step JS logic. Animations were left untouched — they are in the template's script.js and work independently. Integration took 3 working days and cost the client 40% less than alternative solutions.
What's included in the work
- Layout audit for Bitrix compatibility
- Splitting HTML into template files (header, footer, component zones)
- Connecting resources with caching considerations
- Transferring all blocks to components with template overrides
- Setting up paths, styles, scripts
- Testing in browsers and admin panel
- Delivering source files and an editing guide
- Integration cost is calculated individually after layout analysis.
Comparing static layout and integrated template
An integrated template is 3 times faster to modify than editing static HTML. Content management via the admin panel is 5 times more efficient than code editing.
| Parameter |
Static HTML |
Integrated template |
| Content management |
Editing in code |
Via admin panel |
| Dynamic data |
None |
From database via components |
| Caching |
None |
Tagged caching |
| Scalability |
Limited |
Full infoblock support |
Timelines
| Type of layout |
Timelines |
| Simple landing page (1–3 pages, basic blocks) |
1–3 days |
| Corporate site (5–20 pages, standard components) |
1–2 weeks |
| Online store (catalog, cart, checkout) |
2–5 weeks |
Ready to take on your project? Contact us for a free estimate. Order turnkey layout integration — get a quality guarantee and documentation. Get expert advice.
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:
| Component |
What we do |
catalog.section and catalog.element |
View switching (grid/list/table), lazy load for images, srcset for retina |
sale.basket.basket |
AJAX update without reload, mini-cart via sale.basket.basket.line |
menu |
Mega menu with caching by sections, lazy loading of submenus |
search.title |
Autosuggest with 300ms debounce, product previews in dropdown |
breadcrumb |
Microdata BreadcrumbList according to Schema.org |
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:
- Analysis of mockups and current project — identify components for rework
- Structure design — break the page into BEM blocks
- Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
- Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
- 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
| Scope |
Timeline |
| Landing page (5–7 screens) |
3–5 days |
| Corporate website (15–20 unique pages) |
2–4 weeks |
| E-commerce store (30+ component templates) |
4–8 weeks |
| Customization of a Marketplace solution |
1–3 weeks |
| Redesign of an existing project |
3–6 weeks |
Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.
