Frontend and Templates for 1C-Bitrix
Component Templates — Where 70% of Problems Live
The Bitrix component system is straightforward: there's a component (logic) and a template (presentation). The problem is that in real projects, this boundary gets blurred. You open template.php from the previous contractor — and there are SQL queries, business logic, and inline styles all in one file. We enforce strict separation: logic goes in result_modifier.php or component_epilog.php, presentation stays in template.php. No CIBlockElement::GetList in the template.
The Structure We Follow
A custom component template isn't a single file — it's a structure:
-
template.php— HTML only, outputs$arResult -
result_modifier.php— data preparation, additional queries, formatting -
component_epilog.php— code that runs after caching (counters, forms) -
style.cssandscript.js— auto-included via\Bitrix\Main\Page\Asset -
.parameters.php— parameters for visual editor configuration
CSS and JS are included via Asset::getInstance()->addCss() and addJs(). Not through <link> in the template — otherwise file merging and caching break.
Caching — Critical for High-Load
Component caching in Bitrix is powerful, but easy to break. A typical mistake: you output the user's name inside a cached catalog component — and everyone sees the same name. The solution: component_epilog.php for dynamic inserts that shouldn't be cached.
Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) — we always configure it. Changed a product in the admin panel — the cache for that specific product resets automatically, without flushing everything.
Standard Templates
-
Catalog —
catalog.sectionandcatalog.elementwith view switching (grid/list/table). Lazy load for images,srcsetfor retina -
Cart —
sale.basket.basketwith AJAX updates without page reload. Mini-cart in the header viasale.basket.basket.line -
Mega menu —
menuwith section-level caching and deferred submenu loading -
Search —
search.titlewith autocomplete suggestions, 300ms debounce, product previews in the dropdown -
Breadcrumbs —
breadcrumbwith BreadcrumbList Schema.org markup
Customizing Marketplace Templates
A purchased ready-made solution is a starting point, not the finish line. What we typically rework:
- Extract inline styles into separate files — stock templates love cramming CSS directly into HTML
- Remove unused JS — stock solutions pull in jQuery plugins totaling 200+ KB, of which only one slider is actually used
- Rework
result_modifier.php— often contains redundant database queries for data already present in$arResult - Adapt the design without losing update capability — we customize a copy of the template, leaving the original untouched
CSS: BEM, Tailwind, or Hybrid
BEM — Predictability for Large Projects
On projects with dozens of component templates, BEM is a lifesaver. .product-card, .product-card__price, .product-card--featured. Styles are isolated, no conflicts, a new developer reads the classes and understands the structure without documentation.
Bitrix specifics: components generate wrappers with classes like bx-component. We don't fight them — we wrap our BEM block inside.
Tailwind — Speed for Standard Tasks
For projects where development speed takes priority over long-term maintainability. PurgeCSS (built into Tailwind 3+) strips unused styles — resulting CSS is 10-30 KB instead of hundreds. Design token configuration through tailwind.config.js: colors, fonts, spacing locked in one place.
Hybrid — What We Use Most Often
BEM for structural components (catalog, product card, checkout), Tailwind for utility needs (spacing, flex layouts, text colors). Works when the team has agreed on the boundary.
Frontend Performance — Core Web Vitals
Critical CSS — LCP Under Control
We extract above-the-fold styles using critical (npm package), inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". The LCP difference is a second to a second and a half on mobile.
Images — The Main Source of Slowdowns
- WebP via
<picture>with JPEG fallback. AVIF if the audience is on modern browsers -
loading="lazy"for everything below the fold -
widthandheightexplicitly set — CLS = 0, no layout shift - On-the-fly conversion: a handler in
urlrewrite.phpfor automatic WebP generation from uploaded images
Minification and Compression
- CSS and JS via Vite or Bitrix's built-in file merging ("Settings → Main Module → CSS Optimization")
- Brotli on nginx (
brotli_comp_level 6) — 15-20% more efficient than gzip - Static asset caching:
expires 1y+ versioning via query string or filename hash
Responsive Layout — Mobile-First
Base styles are for mobile (320px+). Desktop styles are added via @media (min-width: 1024px). Not the other way around.
| Breakpoint | Range | What we adapt |
|---|---|---|
| Mobile | 320-639px | Single-column grid, enlarged touch targets (minimum 44x44px) |
| Tablet | 640-1023px | Two-column grid, adapted navigation |
| Desktop | 1024-1439px | Full grid, sidebars, mega menu |
| Wide screens | 1440px+ | max-width on container, increased spacing |
Retina: SVG for icons (run through SVGO — 30-50% size reduction), srcset with 2x for raster images.
Accessibility and Cross-Browser Support
ARIA attributes for interactive elements: role="dialog" on modals, aria-expanded on accordions, aria-label on icon buttons. Tab navigation, contrast per WCAG 2.1 AA.
We support: Chrome, Firefox, Safari, Edge — last 2 versions. Safari iOS 15+, Chrome Android 10+, Yandex Browser. For everything else — graceful degradation: everything works, but without animations and shadows.
Timelines
| Scope | Timeline |
|---|---|
| Landing page (5-7 screens) | 3-5 days |
| Corporate site (15-20 unique pages) | 2-4 weeks |
| Online store (30+ component templates) | 4-8 weeks |
| Marketplace solution customization | 1-3 weeks |
| Redesign of an existing project | 3-6 weeks |
After analyzing the mockups, we provide a breakdown by components and pages — specifying what gets reused and what is built from scratch.