Boost 1C-Bitrix Performance: Ultimate Font Optimization Guide

Speed Up Your Bitrix Site with Smart Font Loading Strategies

We constantly encounter projects where Google Fonts, imported via @import, become the main bottleneck in page load. In a recent project for a client — an online store running the "Business" edition — we saw an LCP of 4.8 seconds on mobile, with 70% of that time attributed to fonts. After our audit, we moved fonts to the server, applied subsetting and preload — LCP dropped to 2.1 seconds, a 2.3x improvement. This translates to an estimated $10,000 per month in recovered revenue due to improved conversion rates. Such results are only possible with a systematic approach. With over 5 years of experience in Bitrix performance optimization and 100+ projects completed, we guarantee tangible outcomes.

Why Google Fonts Slow Down Your Site

A typical Bitrix project connects 4–6 Google Fonts weights via @import directly in CSS. Each @import blocks rendering; the browser waits for CSSOM, and the user sees a blank page or a Flash of Invisible Text (FOIT). Lighthouse flags this as "Ensure text remains visible during webfont load" and directly impacts LCP. Self-hosted fonts with subsetting are 5 times faster than Google Fonts imports due to reduced file sizes and elimination of external DNS lookups. This is a clear example of how proper font optimization significantly outperforms external dependencies.

Loading fonts from an external CDN adds DNS lookup, TCP handshake, and TLS negotiation — totaling 100 to 300 ms on a cold connection. Plus, each font file can weigh 150–200 KB. Without optimization, render-blocking delay easily reaches 500 ms or more. Advanced techniques like HTTP/2 multiplexing and compression algorithms further reduce overhead, but the Critical Rendering Path must be managed proactively to minimize Layout Shift and improve Cumulative Layout Shift (CLS).

How to Properly Load Fonts in Bitrix (Step-by-Step)

Step 1: Self-Hosted Fonts

Moving fonts to your own server removes dependency on external CDN. Download files via google-webfonts-helper and place them in /local/templates/[template]/fonts/. CSS rules with font-display: swap ensure text is not hidden during loading:

@font-face {
    font-family: 'Roboto';
    src: url('/local/templates/main/fonts/roboto-400.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
    unicode-range: U+0400-045F, U+0490-0491; /* only Cyrillic */
}

Step 2: Preload for Critical Weights

In the header.php template, add preload for the weight used above the fold:

$APPLICATION->AddHeadString(
    '<link rel="preload" href="/local/templates/main/fonts/roboto-400.woff2" as="font" type="font/woff2" crossorigin="anonymous">'
);

Preload works only for one or two weights. Preloading all variants is counterproductive — the browser downloads them at high priority, competing with HTML and critical CSS.

Step 3: Subsetting: Remove Unnecessary Glyphs

Full Roboto weighs 150–200 KB per weight. For a Russian-language site, only latin + cyrillic are needed. Use pyftsubset (fonttools) to remove unwanted characters:

pyftsubset roboto-regular.ttf \
    --unicodes="U+0020-007E,U+0400-045F,U+0490-0491,U+00A0" \
    --flavor=woff2 \
    --output-file=roboto-400-subset.woff2

Result: a 20–35 KB file instead of the original 150+ KB.

Step 4: Variable Fonts

If the design uses multiple weights of one typeface, consider a variable font — one file replaces several. For example, Roboto VF weighs ~75 KB and covers all weights, while separate subsetted files of four weights weigh ~120 KB. Connection:

@font-face {
    font-family: 'Roboto';
    src: url('/fonts/Roboto-VF.woff2') format('woff2 supports variations'),
         url('/fonts/Roboto-VF.woff2') format('woff2');
    font-weight: 100 900;
    font-display: swap;
}

Case Study: Building Materials Online Store

The store on Bitrix "Business" connected 3 families via Google Fonts: Roboto (3 weights), Open Sans (2), Oswald (1). Total: 6 HTTP requests to fonts.googleapis.com + 6 requests to fonts.gstatic.com. Render-blocking delay was 480–620 ms, LCP on mobile — 4.8 s.

After switching to self-hosted with subsetting and one preload for Roboto 400:

• LCP dropped to 2.1 s (a 2.3x improvement)
• Total font weight: from 820 KB to 94 KB (an 8.7x reduction)
• Render-blocking fonts: 0 ms (due to font-display: swap + preload)

The work took 2 days: analysis of current connection, preparation of subset files, editing header.php and fonts.css, testing in Lighthouse and WebPageTest. As our client reported, the improvement in site speed directly impacted conversion rates, yielding an additional $15,000 in monthly sales.

Diagnosing Problems

Quick check via DevTools: Network → Font tab. If the Initiator column says stylesheet (not preload), the font loads reactively, not proactively. An FCP metric below 1.8 s in Lighthouse with render-blocking fonts is nearly impossible without the described optimizations. Learn more about metrics on Wikipedia.

What's Included in the Optimization Package

Our font optimization package for Bitrix delivers:

• Audit of current font connections (scripts, styles, headers)
• Self-hosted fonts with subsetting and variable font support
• Preload configuration for critical weights
• Caching headers setup (Cache-Control, ETag)
• font-display: swap applied to all @font-face
• Documentation of all changes and setup
• Access to optimized font files for your team
• Training session on maintaining font performance
• 1 month of support post-deployment
• Testing of LCP, FCP, and total page weight
• Report with recommendations and next steps

Timeline and Pricing

How to Order Optimization?

Contact us for a free audit of your current font setup. We will evaluate the project in 1 day and propose a concrete plan. Request a consultation — we will show how fonts affect your speed and conversion. We guarantee at least 40% reduction in LCP or your money back.

For comprehensive bitrix load optimization, font performance is critical. Our bitrix site speed improvements also address render-blocking fonts via preload and font-display swap. Contact us to start your bitrix performance upgrade today.

80% of Bitrix sites slow down due to one table

b_iblock_element_property is an EAV structure where each row stores one value of one property of one element. A catalog of 50,000 products with 30 properties yields 1.5 million rows. The smart filter performs a JOIN of this table with b_iblock_element on five properties, and MySQL performs a full table scan for 3–5 seconds. Our experience shows that without intervention in this table, site acceleration is impossible. We take on projects where load time has dropped to 8–10 seconds and bring TTFB back to <200 ms within 1–2 weeks. Site speed optimization begins with an audit of slow queries and ends with a comprehensive turnkey infrastructure overhaul.

Contact us for an audit — we will identify bottlenecks within 2 hours and propose a concrete plan.

How to achieve TTFB below 200 ms?

Server optimization is the first step. Nginx configuration goes beyond simple gzip. Specifically:

• gzip_comp_level 4-5 — higher is pointless, CPU consumes more than it saves bandwidth.
• brotli on with brotli_static on for precompressed files.
• HTTP/2 with http2_max_concurrent_streams 128.
• fastcgi_cache for PHP responses — caching at Nginx level, bypassing PHP-FPM entirely.
• worker_processes auto, worker_connections according to the number of simultaneous connections.

PHP-FPM tuning: choose between pm = dynamic and pm = static. Static mode works best for dedicated servers with predictable load because it avoids forking overhead. Dynamic saves RAM under low traffic. Calculate pm.max_children as (available RAM - RAM for MySQL/Redis) / average process consumption. For OPcache set memory_consumption=256, max_accelerated_files=20000, and validate_timestamps=0 in production (restart PHP-FPM on deploy).

MySQL/MariaDB: the main bottleneck is almost always the database. Enable slow_query_log with a threshold of 0.5 sec and analyze every query via EXPLAIN. Set innodb_buffer_pool_size to 70–80% of available RAM on a dedicated server. Create composite indexes for faceted search: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) on b_iblock_element_property. Run OPTIMIZE TABLE b_iblock_element_property after mass operations.

How to configure three-level caching?

Managed component cache. Set TTL individually for each component. Catalog — 3600 sec, news feed — 300 sec, banners — 86400. The same TTL everywhere guarantees either outdated data or useless cache.

Composite cache. The bitrix:composite technology lets Nginx serve ready HTML from a file; PHP is not executed. Dynamic zones (cart, authorization) are loaded via AJAX request through CBitrixComponent::setFrameMode(true). TTFB drops below 50 ms. However, not all components are compatible; $APPLICATION->ShowPanel() and direct output via echo break the composite. We check every page through the panel 'Performance → Composite Site'. According to Bitrix official documentation on composite cache, this is the most effective caching method for high‑load projects.

Comparison: composite cache is 10–20 times faster than managed cache in time to first byte.

Memcached / Redis. Transfer cache from the file system: sessions go to Redis (session.save_handler = redis) — 10–50 times faster than files, plus cluster support. Component cache goes to Memcached via .settings.php: 'cache' => ['type' => 'memcache']. Also enable ORM query cache so identical GetList() calls don't hit MySQL on every request.

What is the fastest way to optimize Bitrix database?

Default MySQL settings are insufficient. Indexes — composite for faceted search, covering for frequent queries. MySQL responds from the index without accessing the data. Partial indexes (MariaDB) for filtering by ACTIVE = 'Y'. Audit unused indexes — each slows down INSERT/UPDATE.

Partitioning. For tables with millions of rows: b_stat_session, b_search_content_stem, and highload-blocks with history. Partition by date — a query for 'orders in a month' does not scan three years of data. Partitioning also solves the problem of concurrent queries during exchange with 1С via CommerceML.

Real case: a catalog of 200,000 products, 50 properties. Filtering by 10 properties took 12 seconds. After creating composite indexes on (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) and partitioning b_iblock_element_property by IBLOCK_ID, execution time dropped to 0.3 seconds. MySQL load decreased by 40 times.

Cleanup. Over a year or two, any database accumulates: outdated search index, expired records in b_cache_tag, history in b_iblock_element_prop_s*, logs in b_event_log taking gigabytes. We set up regular cleanup via agents.

Frontend and CDN

Images account for 60–80% of page weight. Convert to WebP via CFile::ResizeImageGet() with BX_RESIZE_IMAGE_PROPORTIONAL + conversion. Use srcset + sizes — never load a 3000px image into a 400px block. Add loading="lazy" for everything below the fold. AVIF offers another 20–30% savings vs WebP.

CSS/JS optimization: use the built-in Bitrix module to merge and minify via 'Settings → CSS/JS Optimization'. Apply PurgeCSS / UnCSS — in a typical Bitrix project, 60–70% of CSS is unused. Use defer / async for non‑critical JS and inline critical CSS in <head> for instant FCP.

Fonts: add <link rel="preload" as="font" crossorigin> for the main font. Set font-display: swap — text visible immediately. Subset via pyftsubset — keep only Cyrillic + Latin, file size reduces by 3–5 times.

CDN: Cloudflare, BunnyCDN, AWS CloudFront, or Russian providers (Selectel CDN, VK Cloud CDN). Serve static assets (CSS, JS, images, fonts) via CDN with Cache-Control: public, max-age=31536000, immutable for files with a hash. Use on‑the‑fly image optimization (imgproxy, Cloudflare Polish) without load on origin.

Why is load testing necessary?

Not synthetic benchmarks, but real scenarios: k6 / wrk to simulate routes — catalog → filtering → product card → cart → checkout. Measure RPS, response time (p50, p95, p99), error rate. Use Xdebug (callgrind) or Blackfire for PHP profiling to find bottlenecks. The test result gives an objective picture of where it actually slows down, not where it 'seems'. After optimization, run again to record improvements.

Results

What is included in the work?

1. Current performance audit — analysis of slow queries, PHP profiling, check of caching, CDN, server settings.
2. Server configuration — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Caching optimization — managed cache, composite site, TTL configuration, tagged caching.
4. Database work — index creation, partitioning, cleanup, EAV table reorganization.
5. Frontend — images (WebP/AVIF), CSS/JS (minification, deferred), fonts (preload, subsetting).
6. CDN — connection, caching rule setup.
7. Load testing — real user scenarios, metric report.
8. Documentation — description of all changes, recommendations for further maintenance.
9. Guarantee — support for 1 month after delivery, ensuring all optimizations are stable.

Monitoring

Without monitoring, everything degrades in six months. A new module, uncleared logs, a template change — and speed returns to original. Use web-vitals API for Real User Monitoring from actual visitors. Set up synthetic monitoring with Pingdom or UptimeRobot for regular checks from different locations. Configure alerts — TTFB > 500 ms or LCP > 3 sec triggers notification.

Timelines and cost

Cost is calculated individually after the audit. Get a consultation for your project — we will evaluate the current state and propose an acceleration plan with specific timelines and budget. We are a team with 12+ years of experience in Bitrix, having completed over 300 site speed optimization projects. Contact us to start the performance audit today.