Skip to content
Business Agile
Work
Web · Wedding photography and film · Jul 2025

Maison Ozaé

A bilingual wedding portfolio that stays fast with nearly 4,000 photographs.

maisonozae.eu
Home page of the Maison Ozaé website, wedding photography and film

Lighthouse desktop · measured on 22 September 2026

79
Performance
84
Accessibility
100
Best practices
100
SEO
LCP
3.2 s
Largest Contentful Paint
CLS
0
Cumulative Layout Shift
TBT
140 ms
Total Blocking Time

Maison Ozaé brings together Fabrice LABIT, photographer, and Grégory CAUZOT, videographer, around wedding photography and film, in France and abroad. Their need: a portfolio that shows their stories large, loads fast on a phone and speaks to French and English speaking couples alike. I designed and built their website, maisonozae.eu, in two stages.

In pictures

maisonozae.eu
Maison Ozaé wedding story grid
The story grid of the live version: a masonry of thumbnails, each one opening a wedding.
Maison Ozaé home page on mobile
On a phone, photos fill the screen, with call, email and WhatsApp in the header.

The project in detail

The first version, launched in July 2025, was a Vite and React application exported as static files: one page per wedding story, a masonry gallery and a contact form. Over the following months I added the home video, films embedded in the story grid and photo galleries for weddings without video.

In September 2026 I rebuilt the site on TanStack Start with static prerendering, served by nginx. Every page exists in French and English with translated URLs, and the root sends visitors to their browser language. The site has 59 prerendered pages: about twenty wedding stories, one page per member of the duo, a services page and legal pages that name the host and every provider from a single source. The contact form goes through a small FastAPI service that relays messages to Brevo, with rate limiting. This new version is in acceptance testing; the first one stays online until it goes live.

The main challenge was performance on a site made almost entirely of photographs: nearly 4,000 source files. At build time, a script generates AVIF and WebP variants per width plus a blurred placeholder for each image. I moved those placeholders out of the JavaScript sent to the browser, fixed a srcset that duplicated its largest variant on 566 images, loaded the Adobe font without blocking rendering and computed which masonry photos appear first so they get priority. The mobile PageSpeed score of the home page went from 67 to over 80, the wedding pages from 70 to 81, and the simulated largest contentful paint was brought down to 4.1 seconds, with no loss of image quality.

SEO follows the same approach: a title and description per page, structured data, a sitemap generated from the pages actually built and an llms.txt file for answer engines. This is the kind of website redesign I run when the content is heavy: the design stays the client's, the work goes into what visitors and search engines actually receive.

What was done

  1. 01

    Rebuilt on TanStack Start, static prerendering served by nginx

  2. 02

    Bilingual site with translated URLs and automatic language choice at the root

  3. 03

    AVIF and WebP variants and blurred placeholders generated at build time

  4. 04

    Home page mobile PageSpeed from 67 to over 80, story pages from 70 to 81

  5. 05

    Contact form relayed by a FastAPI service to Brevo

Frequently asked questions

How do you keep a photography website fast without degrading the images?

By generating several widths of every photo in AVIF and WebP at build time, loading only the width the screen needs and prioritising the photos visible first. On Maison Ozaé, the home page mobile score went from 67 to over 80 with no loss of quality.

How do you build a bilingual French and English website that ranks well?

Every Maison Ozaé page lives at its own address in each language, with a translated slug, reciprocal hreflang tags and a translated title and description. The site root points visitors to their browser language without preventing search engines from crawling both versions.

How do contact requests from a static website reach an inbox?

The form posts messages to a small FastAPI service that emails them through Brevo, with a limit on submissions per visitor. The sending key stays on the server, never in the website code.

Other work

A project? Let's talk this week.

A short brief, an answer within 48 hours, a firm estimate after scoping.

Describe my project