A photographer uploads 4K images — visitors complain about slow loading. A gallery of 30 photos weighs 150 MB and takes 15 seconds to load. The result — losing clients. Our company — 10+ years of certified experience in 1C-Bitrix development, over 50 projects for photographers — guarantees: even dozens of galleries do not affect speed. Development on 1C-Bitrix allows packaging visuals into WebP, setting up CDN, and giving clients a personal cabinet for downloading. Contact us for a guaranteed consultation — we will show case studies. Most projects start from $2,500 and save up to 30% compared to custom alternatives.
Why 1C-Bitrix is chosen for a photographer's website?
The platform provides ready-made modules for information blocks, tagged caching, and background agents. For portfolios, information blocks v2.0 with multiple file properties are used. Booking, personal cabinet, and blog are covered by standard tools. The built-in SEO module generates sitemap and Schema.org markup automatically. According to Bitrix documentation, component 2.0 and ORM ensure high performance even under thousands of requests.
How to optimize a portfolio for fast loading?
The portfolio is the core of the site. A photographer uploads images 4000–6000 px, 5–15 MB each. The visitor should see the gallery instantly.
Step 1: Information block structure
- Sections: genres (wedding, reportage, product, portrait).
- Elements: photo shoots or series.
- Properties: description, date, location, multiple file property "Photos".
Step 2: Thumbnail generation
After uploading a photo, the handler OnAfterIBlockElementUpdate launches a background task via event manager. Agents are used. Set of thumbnails:
| Purpose |
Size |
Format |
Quality |
| Mobile preview |
400×267 |
WebP |
80% |
| Desktop preview |
800×533 |
WebP |
85% |
| Lightbox |
1600×1067 |
WebP |
90% |
| Full-size |
2400×1600 |
WebP + JPEG |
92% |
The original is saved but not served directly — only via thumbnails. CFile::ResizeImageGet() with proportional resize maintains proportions. WebP is converted via Imagick, support check via Accept header or <picture> tag. WebP is 2–3 times lighter than JPEG at the same quality.
Step 3: Lazy loading with progressive display
Standard loading="lazy" causes layout shift. Our solution:
- Placeholder with dominant color — upon photo upload, the average color is extracted (PHP), saved as an element property. In CSS, the placeholder is colored with that color.
- Blur-up — micro-preview 20×13 px (< 1 KB) is inlined into HTML as base64, displayed blurred. When the real image loads — smooth replacement via CSS transition.
- Intersection Observer — custom script loads images when approaching viewport (margin 200px). This speeds up visible image loading by 2 times compared to simple
loading=lazy. Our lazy loading method is 2x faster and reduces layout shifts.
The gallery grid — Masonry on CSS Grid: grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)). Lightbox — Fancybox 5 or GLightbox with swipe support.
Step 4: CDN connection
For audiences from different regions, CDN is mandatory. Configuration via the Bitrix CDN module or manual nginx setup with proxying to CloudFlare / BunnyCDN. Thumbnails are served via CDN, originals from the server directly. CDN reduces loading time by 40-60% compared to no CDN.
CDN setup details for Bitrix
To properly set up CDN, configure the CDN module in the admin panel: specify CDN domain, exclude service scripts, enable caching for images and CSS/JS. It is recommended to use a distributed CDN with nodes in Russia and Europe.
Protection from downloading
Cannot be fully prevented, but can be complicated:
- Disable context menu (JavaScript).
- Watermark on displayed versions.
- Serve via CSS
background-image instead of <img>.
Result: a gallery of 30 photos loads in 1.5–2 seconds on mobile LTE. The first screen is displayed in 0.8–1 second thanks to inline placeholder and preload hero image.
How is the booking system structured?
Booking — via an interactive calendar of availability. The client sees free dates and submits a request.
Implementation: an information block "Schedule" with elements as days. Properties: date, status (free/occupied/pre-booked), shoot type. The frontend renders a monthly grid, occupied days are gray. Data is loaded via AJAX when changing the month.
The client clicks a free date → form: name, phone, shoot type, location, comment. The request creates a lead in CRM or sends an email. After confirmation, the photographer changes the day status to "occupied" via the admin panel.
Services with packages
Information block "Services": name, format (hourly/package), duration, what's included, number of photos, link to gallery. On the frontend — cards with a "Book now" button.
Blog and SEO
The blog attracts traffic via queries like "how to prepare for a wedding photo shoot" and demonstrates expertise. Implemented via a standard news information block. SEO: SEF through urlrewrite, meta tags via information block properties, breadcrumbs, Schema.org Article in JSON-LD. Sitemap generated by the SEO module. Our proven SEO approach guarantees better rankings.
Client cabinet for delivering photos
Instead of Yandex.Disk — a closed gallery on the site. Information block "Client galleries": link to user, shoot date, set of photos, status, access period. Access: authorization or password-protected link. Gallery with lightbox, download individual photos or ZIP archive via ZipArchive. Watermark on previews — via GD/Imagick. This reliable system ensures secure photo delivery.
What's included in the work and timelines
- Analysis and prototyping of portfolio, services, calendar structure.
- Design mockup with focus on mobile version.
- Setting up information blocks, thumbnail generation, caching.
- Developing client cabinet with authorization and online booking.
- Integrating CDN, optimizing Core Web Vitals.
- Delivering documentation, training, post-launch support.
| Stage |
Content |
Duration |
| Analysis |
Structure, requirements |
1 week |
| Design |
Mockup, mobile version |
1.5 weeks |
| Layout/frontend |
Grid, lightbox, lazy load, calendar |
2 weeks |
| Backend |
Information blocks, thumbnails, cabinet, blog |
2 weeks |
| Optimization |
WebP, CDN, Core Web Vitals |
1 week |
| Content/launch |
Upload photos, training, deploy |
3 days |
Total: 7–9 weeks. It is critical to receive photo materials in advance — processing and uploading take more time. Pricing is discussed individually, starting from $2,500.
Get a certified engineer consultation: contact us to discuss your project. We will offer the optimal solution for your tasks.
How to properly design infoblocks?
When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.
Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.
Why 1C-Bitrix outperforms most CMS for business
The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.
What highload blocks are and how they speed up the catalog
Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.
From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.
What integrations are critical for 1C-Bitrix stores
Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.
What's included in 1C-Bitrix website development
Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.
- Technical specification – user stories, infoblock diagrams, integration schemas.
- Source code in Git – with commit history, release tags, branching rules.
- Administrative documentation – description of custom components, deployment instructions, list of agents and events.
- Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
- Access to staging during development – test before production deployment.
- Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).
Our process and technologies
| Project type |
Timeline |
Complexity |
Key features |
| Corporate website |
from 1 month |
Medium |
Catalog, news, forms, CRM integration |
| Online store |
from 2 months |
High |
54-FZ, marketplaces, 1C exchange, SKU |
| B2B portal |
from 3 months |
Very high |
Personal prices, document flow, Bizproc |
| Landing page |
from 2 weeks |
Low |
LCP < 2s, composite cache, static |
| Multisite structure |
from 1.5 months |
High |
Separate content, shared catalog, hreflang |
Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.
Process:
-
Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
-
Design – UI/UX with design system. Components are reusable.
-
Development – write components with custom templates in
local/templates/. Business logic in local/modules/.
-
Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
-
Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.
Multilingual support and redesign
Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.
Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.
Guarantee and support
We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.