Cafe website development using 1C-Bitrix

Café Website Development on 1C-Bitrix

A café website solves three tasks: show menu, bring guest, take reservation. Sounds simple, but 90% of visitors open from phone standing outside or scrolling feed. If page loads over 3 seconds or menu unreadable without zoom — guest goes to competitor across street. On 1C-Bitrix café gets managed menu catalog via info blocks, reservation via web-forms sending to CRM, and technical foundation that administrator updates without developer.

Menu as Info Block

Menu — central site element. "Menu" info block structure:

• Sections — dish categories (breakfast, salads, soups, hot dishes, desserts, drinks, bar)
• Elements — specific dishes

Element properties:

• Name — mandatory, displayed on card
• Description — composition and features
• Weight/Volume — string property (150 g, 300 ml)
• Calories — numeric property, output optional
• Allergens — multiple list (gluten, lactose, nuts, shellfish)
• Photo — file property, mandatory
• Label — list (new, bestseller, spicy, vegetarian)
• Active — standard field, lets hide dishes without deletion

Administrator works through standard info block interface: adds dish, uploads photo, marks "business lunch" — appears on site. Sorting via "Sort" field — chef can highlight seasonal items.

On front menu displays with category filtering (tabs or sidebar) and allergen icons. No pagination — full menu on one page with anchor links for easy scrolling.

Promotions and Business Lunches

Separate "Promotions" info block with properties:

• Title and Description of promotion
• Start Date / End Date — date properties, element auto-hides after expiration
• Type — list (business lunch, discount, seasonal offer, combo)
• Dish Binding — link to menu info block

Business lunches updated weekly. For convenience, template created: copy previous week element with dish and date changes. Main page shows current promotions via news.list component with active date filter.

Table Booking

Café — not restaurant with hall management system. R-Keeper or iiko integration excessive. Simple web-form sufficient:

• Guest Name
• Phone (input mask)
• Date and Time
• Guest Count
• Wishes (text field)

Form created via form module or feedback component. Data goes to admin email and parallelly creates lead in Bitrix24 CRM (if cloud connected) or recorded in crm module. Administrator confirms booking by phone.

For spam protection — Google reCAPTCHA v3 (invisible) and request limit per IP.

Interior Photo Gallery

Interior photos form first impression. "Gallery" info block with sections: dining hall, terrace, banquet room, kitchen. Photos uploaded to multiple file property. On front — masonry grid with lightbox (Fancybox). Important: photos must be professional — not development task, but worth fixing content requirements in TZ.

Reviews

Reviews module — standard pre-moderated info block. Guest leaves review via form (name, text, 1-5 rating), administrator checks and publishes. Average rating calculated by cached component, displayed on main. Reviews marked via Schema.org Review — aggregated rating appears in search results.

Map and Contacts

Yandex.Maps or Google Maps via API. Pin with address, route building option. Hours marked via Schema.org OpeningHoursSpecification. Phone — clickable (tel:), calling on mobile.

Schema.org Restaurant

Restaurant micromarkup covers:

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

Markup added to component template via JSON-LD. Checked via Google Rich Results Test before launch.

Mobile Optimization: Core Web Vitals and Image Handling

For café, 85–95% traffic is mobile. Phone, address, menu — everything searched on-the-go. If LCP (Largest Contentful Paint) exceeds 2.5 seconds, Google lowers positions, visitor closes tab.

Problem number one — images. Dish and interior photos heavy: 2–5 MB from photographer. On 375px mobile width loading 2400px image — wasteful.

Solution on 1C-Bitrix level:

Native scaling via CFile::ResizeImageGet() generates thumbnails on first request. Configure size set:

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

Template uses <picture> tag with <source> for WebP and <img> for JPEG fallback. srcset attribute with size hints lets browser choose optimal version.

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

Caching: Bitrix components cache natively (timeout configured in component params). Static (CSS, JS, fonts) served with Cache-Control: max-age=31536000 via nginx. Images similar, with invalidation via filename change on update.

Fonts: one font, two weights (regular, bold), font-display: swap, preload via <link rel="preload">. No Google Fonts — locally hosted, excluding extra DNS-lookup.

Minification and Compression: CSS and JS combined and minified via Bitrix native means (main module setting). Gzip or Brotli — at nginx level.

Result: LCP < 2 seconds, CLS < 0.1, FID < 100 ms. Checked via PageSpeed Insights and real Chrome UX Report data post-accumulation.

Work Stages

Total: 6–8 weeks. Main delay usually content: photo shoot and text approval.