Cafe Website Development on 1C-Bitrix with Booking and Menu

A cafe website solves three tasks: show the menu, bring in the guest, and take a reservation. Sounds simple, but 90% of visitors will open it from their phone while standing on the street or scrolling through their feed. If the page takes more than three seconds to load or the menu can't be read without zooming, the guest will leave for the competitor across the street. Our experience shows that proper architecture on 1C-Bitrix solves these problems. We have developed websites for 15+ establishments, so we know the typical bottlenecks and how to avoid them.

On 1C-Bitrix, a cafe gets a manageable menu catalog via infoblocks, booking via web forms with CRM transfer, and a technical foundation that the admin can update without a developer. The project is delivered turnkey in 6–8 weeks with a warranty and post-launch support.

Implementing the Menu via Infoblocks

The menu is the central element of the site. The structure of the "Menu" infoblock:

• Sections — dish categories (breakfasts, salads, soups, main courses, desserts, drinks, bar)
• Elements — specific dishes

Element properties:

• Name — required, displayed on the card
• Description — composition and features
• Weight/volume — string property (150 g, 300 ml)
• Calories — numeric property, optional display
• Allergens — multiple list (gluten, lactose, nuts, seafood)
• Photo — file property, required
• Label — list (new, hit, spicy, vegetarian)
• Activity — standard field, allows hiding dishes without deletion

The admin works through the standard infoblock interface: adds a dish, uploads a photo, sets a "business lunch" label, and it appears on the site. Sorting via the "Sort" field — the chef can highlight seasonal items by moving them up.

On the frontend, the menu is displayed with filtering by category (tabs or sidebar) and allergen icons. No pagination — the entire menu on one page with anchor links so the guest can scroll through it all.

Promotions and Booking: How Not to Lose a Customer?

Promotions and Business Lunches

A separate "Promotions" infoblock with properties:

• Title and description of the promotion
• Start date / end date — date type properties, the element hides automatically after expiration
• Type — list (business lunch, discount, seasonal offer, combo)
• Link to dishes — connection with the menu infoblock

Business lunches are updated weekly. For the admin's convenience, a template is created: copying last week's element with changed dishes and dates. On the main page, a block with current promotions is formed by the news.list component with a filter by active dates.

Table Booking

A cafe is not a restaurant with a hall management system. Integration with R-Keeper or iiko for booking is overkill here. A web form is sufficient:

• Guest name
• Phone (input mask)
• Date and time
• Number of guests
• Wishes (text field)

The form is created via the form module or the feedback component. Data is sent to the admin email and simultaneously creates a lead in Bitrix24 CRM (if cloud is connected) or is written to the crm module of the box. The admin confirms the booking by phone.

For spam protection — Google reCAPTCHA v3 (invisible to the user) and a limit on the number of requests from one IP.

Photo Gallery, Reviews, and Contacts

Interior Photo Gallery

Infoblock "Gallery" with sections: hall, terrace, banquet hall, kitchen. Photos are uploaded into a multiple file property. On the frontend — masonry grid with lightbox (Fancybox or equivalent). Important: photos must be professional — this is not a development task, but the requirements for content should be fixed at the technical specification stage.

Reviews

Reviews module — a standard infoblock with pre-moderation. The guest leaves a review via a form (name, text, rating from 1 to 5), the admin checks and publishes it. The average rating is calculated by a cached component and displayed on the main page. Reviews are marked up with Schema.org Review — the aggregated rating appears in search results.

Map and Contacts

Yandex.Maps or Google Maps via API. A pin with the address, route building capability. Business hours marked up with Schema.org OpeningHoursSpecification. Phone number is clickable (tel:), on mobile — calls.

SEO Markup: Schema.org Restaurant

The Restaurant microdata covers:

• name, address, telephone
• openingHours — business hours
• servesCuisine — cuisine type
• menu — link to the menu page
• aggregateRating — average rating from reviews
• image — restaurant photo

Markup is added to the component template via JSON-LD. It is verified with Google Rich Results Test before launch.

Mobile Optimization: Core Web Vitals and WebP

For a cafe, mobile traffic accounts for 85–95%. Phone, address, menu — everything searched on the go. If LCP (Largest Contentful Paint) exceeds 2.5 seconds, Google lowers positions, and the guest closes the tab.

Problem number one — images. Photos of dishes and interiors are heavy: 2–5 MB from the photographer's camera. On a mobile screen 375px wide, loading a 2400px image is wasteful. WebP compresses images 30% more efficiently than JPEG, saving hosting budget and speeding up loading. The WebP format was developed by Google and is supported by all modern browsers (WebP).

Solution at the 1C-Bitrix level:

The built-in scaling via CFile::ResizeImageGet() generates thumbnails on the first request. We configure a set of sizes:

• Menu card (mobile) — 400×300, quality 80%, WebP format
• Menu card (desktop) — 800×600, quality 85%, WebP format
• Gallery (preview) — 600×400, WebP
• Gallery (full size) — 1600×1200, WebP with JPEG fallback

In the component template, the <picture> tag is used with <source> for WebP and <img> for JPEG fallback. The srcset attribute specifying sizes lets the browser choose the optimal version.

Lazy loading — loading="lazy" attribute on all images below the first screen. For the menu, this means the first 3–4 dishes load immediately, the rest load on scroll. Intersection Observer API for custom behavior if needed.

Caching: Bitrix components are cached by default (cache time setting in component parameters). Static files (CSS, JS, fonts) are served with Cache-Control: max-age=31536000 headers via nginx settings. For images — similarly, with invalidation via filename change on update.

Fonts: one font, two styles (regular, bold), loaded with font-display: swap, preloaded via <link rel="preload">. No Google Fonts — files are hosted locally, eliminating extra DNS lookups.

Minification and compression: CSS and JS are combined and minified via Bitrix's built-in tools (setting in the main module). Gzip or Brotli at the nginx level.

Result: LCP < 2 seconds, CLS < 0.1, FID < 100 ms. Verified via PageSpeed Insights and real data from Chrome UX Report after statistics accumulate. Our certified engineers guarantee compliance with these metrics.

If you want a website that loads quickly and brings bookings, contact us for a consultation.

What's Included in Cafe Website Development

• Documentation: technical specification, menu structure, form routing
• Access: hosting, domain, Bitrix24 admin panel
• Training: instructions for updating menu and promotions
• Support: 30 days after launch free of charge

Stages and Timeline

Total: 6–8 weeks. The main delay is usually content: food photography and text approval.

To get an estimate for your project, contact us — we will prepare a commercial proposal with timelines and costs. Order turnkey cafe website development and get a consultation from a Bitrix engineer.

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

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:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. 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.