Website Hero Video for Architecture Firms: Size, Poster and Speed

A website hero video can make an architecture firm's homepage feel alive the moment it loads, or it can be the single slowest thing on the page. The difference is rarely the footage itself, but whether the poster image, file size and video markup keep the video out of the browser's critical rendering path. This guide covers the poster-as-LCP pattern, a realistic file-size budget, the markup for a safe autoplaying hero, and how to turn a finished project film into a short looping hero, using current Core Web Vitals guidance and two 2026 engineering write-ups, as of September 2026.

Key takeaways

• Google's Core Web Vitals guidance scores a video by its poster image load time or first frame presentation time, whichever comes first, so a heavy poster is often what makes a hero video read as slow, not the video file itself.
• Budget roughly 1 to 3 MB for a full-bleed looping background clip; two 2026 write-ups cut hero videos from 18 MB and from generic multi-megabyte exports down into that range using the AV1 codec with audio stripped out.
• Autoplay, muted, loop and playsinline on the video element, plus preload="none", are what let a hero video play automatically without blocking the page or hijacking the screen on an iPhone.
• AV1 compresses harder than H.264, but Safari's support is still only partial as of September 2026, so a hero video needs an H.264 fallback rather than a single AV1 file.
• An Arch2Video project film exports as a roughly 30-second, 1080×1920 clip; turning one into a website hero means trimming to a clean loop point and re-encoding it, not just dropping the finished file into a hero component.

Why the poster image decides your hero video's speed score

Web.dev's Largest Contentful Paint guidance says sites "should strive to have Largest Contentful Paint of 2.5 seconds or less," measured at the 75th percentile of page loads, with anything past 4.0 seconds counted as poor. For a video element specifically, the same guidance states that "the poster image load time or first frame presentation time for videos is used, whichever is earlier." In plain terms, the browser scores a hero video the instant its poster paints, or its first frame appears if there's no poster, not once the whole clip has finished downloading.

That's the detail most architecture firm sites get backwards. A homepage ships a 15 to 20 MB autoplay video with no poster at all, so the browser has nothing to paint until a meaningful chunk of that heavy file has arrived. Treat the poster as the real LCP candidate instead: get a small, fast image on screen first, then let the video load in behind it.

A July 2026 case study from Mintec rebuilt a hero section around exactly that idea: "the poster IS the LCP element. The video loads lazily behind it." Swapping the poster from a 280 KB JPEG to a 74 KB WebP file cut about 200 milliseconds off LCP on its own. Combined with a codec switch on the video, described below, the full rebuild brought LCP from 4.7 seconds down to 1.8 seconds on that page.

The markup that keeps an autoplaying hero video out of the way

Five choices in the video markup do most of the work. Autoplay tells the browser to start playing without a click. Muted is what makes that legal: nearly every browser blocks autoplay on a video with sound, and without muted, autoplay is simply ignored. Loop repeats the clip so a short clip plays indefinitely with no extra script. Playsinline keeps the video embedded in the hero on an iPhone; konadu.dev's June 2026 write-up puts it bluntly: "playsinline is required on iOS or the video hijacks fullscreen." The fifth choice, preload="none", tells the browser not to fetch the video file until it's needed, so it doesn't compete with the page's text, fonts and poster image during the first paint.

Mintec's rebuild pairs preload="none" on the video with fetchpriority="high" on the poster image, telling the browser to prioritize the small poster and deprioritize the large video. Konadu.dev takes a more defensive version of the same idea: rather than trusting preload="none" alone, it waits for the browser to be idle before attaching the video's source, and checks the visitor's prefers-reduced-motion setting and a Save-Data connection signal first. Either approach works; the idle-load version is more code, but it also spares a visitor on a slow or data-limited connection from downloading a hero video at all.

File-size budget and codec choice

Once the markup keeps the video out of the critical path, its file size still determines how much bandwidth a visitor spends once it loads. Konadu.dev's target for "a full-bleed background clip at 1024x576, 24fps, with audio stripped" is roughly 1 to 1.5 MB, encoded with H.264 at a constant rate factor of 28 and a slow preset, with the audio track removed and the file's index moved to the front so playback can start before the download finishes. Mintec's rebuild landed at 3.1 MB for a larger frame by switching from H.264 to the newer AV1 codec, down from an 18 MB H.264 original.

AV1 compresses noticeably harder than H.264 at a comparable quality, which is most of why Mintec's file shrank so much. The catch is browser support: as of September 2026, caniuse.com's AV1 data shows full support in Chrome, Firefox and Samsung Internet, but only partial support in Safari on both desktop and iOS. Ship AV1 as a hero video's only source and a meaningful share of Safari visitors either see nothing or fall back to whatever the browser does with an unsupported format. The safe pattern is two sources in the video element, AV1 first and H.264 second, so a browser that understands AV1 uses the smaller file and Safari falls back automatically.

Turning a finished project film into a looping hero

A studio that has already made a project film with a tool like Arch2Video has a natural hero video candidate on hand, but the finished file usually needs work before it belongs on a homepage. Arch2Video's films export at 1080×1920 (9:16) and run about 30 seconds, built from six connected scenes its AI director plans from your uploaded renderings, drawings or photographs. That vertical frame and full runtime suit a Reel or a Story; a website hero usually calls for something shorter, and often something wider.

Start with the loop point. Looping the full clip means the frame snaps back to the start abruptly, and a hard cut in an autoplaying background is distracting even at a glance. Scrub the film for two points, ideally within an 8 to 12 second span, where the framing and lighting are close enough that the cut back to the start reads as a clean beat rather than a jump, such as a quiet establishing shot of a hillside house exterior recurring near both ends of a segment. Trim to that span instead of looping the whole 30 seconds.

Next, decide the frame. A vertical 9:16 clip works as-is for a mobile-first hero, where the viewport is already portrait, but cropping it to fill a wide desktop banner cuts away a large share of the frame, similar to the crop math covered in choosing and preparing images for an architecture video. A site that needs a wide desktop hero should plan for a separate widescreen export, or use the vertical film only on mobile and a still image or different loop on desktop.

From there, the steps mirror any hero video: strip the soundtrack, since the loop plays muted regardless and a silent file encodes smaller; re-encode at the actual display size the hero container needs rather than the full source width, matching the budget above; export both an AV1 and an H.264 version; and pull a still frame from partway into the loop as a compressed WebP poster. For background on preparing source images before they reach a film, see turning architectural renderings into video.

Respecting reduced motion and slow connections

Not every visitor wants an autoplaying video, and not every connection can afford one. A prefers-reduced-motion media query in your CSS can swap the hero video out for its poster image, or pause it after the first loop, for visitors with that operating-system setting on. Konadu.dev's write-up checks the same signal in JavaScript before attaching the video's source at all, alongside a Save-Data connection check, so a visitor who wants reduced motion or a lighter data footprint never downloads the hero video at all. Neither check takes much code, and both let the hero video help visitors who want it without penalizing the ones who don't.

Test before you publish

Run the homepage through a Core Web Vitals testing tool before and after each change, since the poster swap, the codec switch and the markup changes each move LCP on their own and it's worth confirming which one mattered. A lab test gives an immediate read; the real-user data behind tools like PageSpeed Insights updates on a rolling basis, so a lab score improving today doesn't mean the field data reflects it yet. If the studio's example project films are the source for a hero video, treat the export settings above as a separate pass after the film is finished and approved.

Frequently asked questions

What file size should a website hero video be for an architecture firm?

Aim for roughly 1 to 3 MB for a full-bleed looping background clip. Konadu.dev's June 2026 write-up targets 1 to 1.5 MB for a compact clip with audio stripped, while Mintec's July 2026 case study landed at 3.1 MB for a larger frame using the AV1 codec, down from an 18 MB H.264 original. Both are far below the 15 to 20 MB files many architecture firm sites still ship.

Why does my hero video hurt page speed even though it's muted and looping?

Muted and loop control playback, not load timing. If the video has no poster image, or a heavy one, the browser has to wait for the poster or the video's first frame before it can register the page's Largest Contentful Paint, per web.dev's LCP guidance. A small, fast-loading poster paired with preload="none" on the video is what actually protects the speed score.

Should I use AV1 or H.264 for a website hero video?

Use both. AV1 compresses harder, which is most of why a 2026 case study cut a hero video from 18 MB to 3.1 MB, but caniuse.com shows Safari's support as only partial as of September 2026. List an AV1 source first and an H.264 source second in the video element, so browsers that support AV1 use the smaller file and Safari falls back to H.264 automatically.

Can I use a vertical AI-generated project film as a website hero video?

Yes, with adjustments. A film built by a tool like Arch2Video exports at 1080×1920 and about 30 seconds, which suits a mobile-first hero directly but needs a separate widescreen export or crop for a desktop banner. Trim it to an 8 to 12 second loop with a clean cut point, strip the soundtrack, and re-encode at the display size the hero actually needs before publishing it.

Do I still need a poster image if the hero video autoplays immediately?

Yes. Per web.dev's guidance, the browser measures Largest Contentful Paint using the poster image's load time or the video's first frame presentation time, whichever is earlier, so skipping the poster just means the first frame of the video itself becomes the thing visitors wait for. A small WebP poster loaded with fetchpriority="high" gives the browser something fast to paint immediately.