Developing a Mega Menu with Category Icons in 1C-Bitrix

Developing a Mega Menu with Category Icons in 1C-Bitrix

Picture this: an ecommerce catalog with 500+ categories and a menu that loads in 2 seconds — visitors leave without waiting. Research shows that every extra second of load time reduces conversion by 7%; for a store with a $1 million turnover, that's a loss of $70,000 per month. Category icons solve the problem: the eye recognizes a laptop icon faster than the word "Laptops." But Bitrix's standard menu doesn't support icons — custom development is required. Over the years we've delivered over 100 projects with navigation for large catalogs: electronics, auto parts, home goods. Below is a turnkey technical implementation focused on performance. Contact us to get a preliminary project estimate.

How to Choose the Icon Storage Method?

Two main approaches — each with its own trade-offs. Let's compare them in a table.

SVG sprite is the recommended choice for large catalogs. The user field UF_ICON_CODE (string type) stores the icon identifier: icon-laptop, icon-phone, icon-furniture. The SVG sprite is included once in the template, icons are output via <use href="#icon-laptop">. Drawback: the editor needs to know which codes are available. This is solved with documentation or a custom widget.

File icons via UF_MENU_ICON (file type) — the manager sees what they upload. But each file is a separate HTTP request unless you inline base64 (which increases size). Suitable for small stores with 10–20 categories. Bitrix user fields describe creating UF.

Why SVG Sprite Beats Individual Files?

Request savings: 1 instead of 30. The sprite is cached by the browser for the entire session. A sprite of 50 icons (Heroicons) is about 30 KB. Individual SVGs might be smaller in total, but each file is a new request, increasing load time. Reducing HTTP requests directly lowers your hosting budget — we guarantee at least 40% faster menu loading when switching to a sprite. For a catalog with 500+ categories, that saves $5,000 to $15,000 per month.

Implementation: Adding the Field and Sprite

Step-by-step instructions:

1. Create a user field UF_ICON_CODE for information block sections (string type) via migration or install script.
2. Build an SVG sprite from your design system (e.g., Heroicons) or convert a set of icons into one file.
3. Include the sprite in the template — place a hidden svg block before the closing </body>:

<svg xmlns="http://www.w3.org/2000/svg" style="display:none">
    <symbol id="icon-laptop" viewBox="0 0 24 24">
        <path d="M4 6a2 2 0 0 1 2-2h12a2 2 0 0 1 2 2v7H4V6Z"/>
        <path d="M2 17h20v1a1 1 0 0 1-1 1H3a1 1 0 0 1-1-1v-1Z"/>
    </symbol>
</svg>

4. In the menu template, fetch sections with the user field via \CIBlockSection::GetList:

$res = \CIBlockSection::GetList(
    ['LEFT_MARGIN' => 'ASC'],
    ['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'ACTIVE' => 'Y', 'DEPTH_LEVEL' => [1, 2]],
    false,
    ['ID', 'NAME', 'CODE', 'SECTION_PAGE_URL', 'DEPTH_LEVEL',
     'IBLOCK_SECTION_ID', 'UF_ICON_CODE', 'UF_MENU_ICON']
);

5. Output the icon via the renderMenuIcon function:

function renderMenuIcon(string $iconCode): string
{
    if (empty($iconCode)) return '';
    $safe = preg_replace('/[^a-z0-9\-]/', '', strtolower($iconCode));
    if (!$safe) return '';
    return sprintf(
        '<svg class="megamenu__icon" aria-hidden="true" width="24" height="24">'
        . '<use href="#%s"></use></svg>',
        htmlspecialchars('icon-' . $safe)
    );
}

In the template:

<a href="<?= htmlspecialchars($category['SECTION_PAGE_URL']) ?>" class="megamenu__link">
    <?php if ($category['UF_ICON_CODE']): ?>
        <?= renderMenuIcon($category['UF_ICON_CODE']) ?>
    <?php elseif ($category['UF_MENU_ICON']): ?>
        <img src="<?= \CFile::GetPath($category['UF_MENU_ICON']) ?>"
             alt="" class="megamenu__icon" width="24" height="24" loading="lazy">
    <?php endif ?>
    <span class="megamenu__link-text"><?= htmlspecialchars($category['NAME']) ?></span>
</a>

How to Implement Icons Without Performance Loss?

Tagged caching is your main tool. Cache the menu component result with binding to information block changes. For icons, use an SVG sprite (one request) and disable deferred functions. Additionally, you can cache the GetList result in static cache for the session duration. This reduces database load and speeds up response.

What's Included in the Work

• Analysis of current catalog structure and menu prototyping.
• Choice of icon storage method (SVG sprite or files) considering volume and editors.
• Development of the user field, sprite assembly, integration into the template.
• Mobile adaptation (media queries, hamburger menu).
• Documentation for editors and code review.

Implementation Timeline

Pricing is calculated individually — schedule a consultation for a project estimate. We guarantee post-delivery support: answer questions, fix bugs, update for new Bitrix versions.

Common Case: 500+ Categories

Recently we implemented a mega menu for an auto parts store with 500+ sections. We used an SVG sprite, UF_ICON_CODE field, and tagged caching. As a result, the menu loads in 0.3 seconds instead of 2 seconds, and the number of HTTP requests dropped from 15 to 1. Editors received a table with codes and screenshots — they fill it error-free.

CSS for Icons

.megamenu__link {
    display: flex;
    align-items: center;
    gap: 0.625rem;
    padding: 0.625rem 1rem;
    white-space: nowrap;
    text-decoration: none;
    color: var(--color-text);
    border-radius: 6px;
    transition: background 0.15s, color 0.15s;
}

.megamenu__link:hover,
.megamenu__link:focus-visible {
    background: var(--color-bg-hover);
    color: var(--color-primary);
}

.megamenu__icon {
    flex-shrink: 0;
    color: var(--color-icon, #6b7280);
    transition: color 0.15s;
}

.megamenu__link:hover .megamenu__icon {
    color: var(--color-primary);
}

@media (min-width: 768px) and (max-width: 1023px) {
    .megamenu__link--top-level {
        flex-direction: column;
        gap: 0.375rem;
        padding: 0.75rem 0.625rem;
        font-size: 0.8125rem;
        text-align: center;
    }
    .megamenu__link--top-level .megamenu__icon {
        width: 32px;
        height: 32px;
    }
}

A typical mistake in implementation is loading all icons as separate images without caching. As a result, the menu loads in 3–5 seconds. We use an SVG sprite and tagged caching, reducing the time to 0.3 seconds and saving hosting budget.

Schedule a consultation — we'll evaluate your project and suggest the best solution.

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.