I draw everything on this site by hand, so I am not the person you would expect to write a post telling you to want less from your design. But I have sat across the table from enough boutique hotel and restaurant owners in Laguna and Newport who wanted a site that felt as good as the place itself, and watched that same site score a 30 on mobile PageSpeed, that I have made peace with saying it plainly: some of the design choices we all reach for first are quietly the ones costing you the most in search.
This is not an argument for boring. It is a list of the specific choices I see most often in hospitality and gallery sites across the county, and the version of each one that keeps the feeling without the tax. If you want the underlying vocabulary — LCP, INP, CLS — we cover that separately. This is about where those numbers actually come from in a design file.
The autoplay hero video
Nothing sells a boutique property faster than a slow, moody video of waves or candlelight looping behind the headline, and nothing tanks your Largest Contentful Paint faster either, because the browser has to fetch and start decoding a video file before it can consider the hero "painted." The fix is not to cut the video — it is to stop making it the thing the browser has to wait on. Show a compressed, well-chosen poster image as the actual LCP element, and let the video load in and crossfade in behind it once the page is already interactive. Keep the loop itself short and genuinely compressed — most hero videos I inherit from a previous build are five to ten times larger than they need to be for how small they are actually displayed on a phone screen. Nobody can tell the difference between a properly compressed loop and the raw export. Google can.
The gorgeous, slow-loading custom font
This site runs a display serif for headlines for the same reason a hotel picks a typeface for its signage — it sets a mood instantly, before anyone reads a word. But a heavy variable font family loaded without care means the browser sometimes hides your text entirely until the font file arrives, a flash of invisible text that directly delays how quickly a visitor sees anything at all. The fix is boring and non-negotiable: set font-display to swap so a system font shows instantly and swaps in once your custom font is ready, subset the font file to only the weights and characters you actually use instead of shipping the whole family, and preload the one or two font files that render above the fold. None of this touches how the site looks. It only touches how long someone stares at a blank screen first.
Parallax and scroll-jacking
Layered scroll effects look genuinely impressive in a design review and are one of the more reliable ways to wreck your Interaction to Next Paint, because most implementations recalculate expensive layout and paint work on every single scroll event instead of letting the browser's own compositor handle it cheaply. If a scroll effect is worth keeping, it almost always can be rebuilt using CSS transforms and opacity changes — properties the browser can animate on the compositor thread without touching layout at all — instead of JavaScript recalculating positions on every frame. The visual effect survives. The jank does not.
Designed for the 27-inch monitor, shipped to the phone in direct sun
Almost every design review happens on a large monitor in a quiet office, and almost every visitor to a hospitality or gallery site is on a phone, often outdoors, often on a mobile connection that is nothing like the office Wi-Fi the mockup was approved on. A hero treatment that feels cinematic at desktop scale frequently becomes the exact problem on mobile: the same heavy video and font assets forced through a slower connection, on a smaller screen where the visual payoff is smaller too. I now review every hospitality design on an actual phone, on a throttled connection, before it ships — not as a courtesy pass at the end, but as part of approving the design in the first place, because a design that only works in the office is not actually finished.
Full-screen booking modals are a related trap. They look sleek in a Figma prototype and, poorly built, they can trap a mobile visitor in a slow-loading overlay with no obvious way back to the page they were just reading, which costs a booking as surely as a slow page load does. A modal that loads instantly because it was built lightweight, with an obvious close affordance, converts better than a beautiful one a visitor gives up on waiting for.
Icon fonts and custom cursors, the small stuff that adds up
None of these individually wreck a page the way an autoplay hero does, which is exactly why they survive so many rounds of review — each one seems too small to matter. A full icon font library loaded to display six icons, a custom animated cursor loaded as its own script, a sticky navigation bar with a blur or glass effect recalculated on every scroll frame: each adds a little request weight or a little main-thread work, and a site can carry four or five of these small choices at once without anyone noticing until the Core Web Vitals report comes back yellow. The fix for each is usually the same shape — load only the specific icons you use as inline SVG instead of a whole font file, keep cursor and hover effects to properties the compositor can animate cheaply, and test the sticky header's actual paint cost rather than assuming a blur effect is free because it looks simple. Small choices are still choices, and they still get billed to the visitor's loading experience.
The gallery nobody optimized
A boutique hotel or a Laguna gallery lives or dies by its photography, and I would never tell a client to use fewer or worse photos. I will tell them their fifteen-image room gallery does not need to ship fifteen full-resolution originals on initial page load. Serve responsive images sized to how large they actually render at each screen width, use a modern format like WebP or AVIF instead of a decade-old JPEG export, and lazy-load everything below the fold so the browser is not fetching image twelve while a visitor is still deciding whether to scroll past image two. This is the single highest-leverage fix I make on hospitality sites, because photography is usually the heaviest asset category on the page by a wide margin, and it is almost always the most fixable without changing a single pixel of the actual photo.
What I actually believe about this
Constraints make design better, not worse — I learned that shaping boards before I ever touched a design tool, where a blank is genuinely finite and every decision has to earn its place. A page-speed budget is the same kind of constraint. It does not mean stripping a site down to a text file. It means every heavy choice has to justify itself: does this video, this font, this effect actually serve the feeling we are going for, enough to be worth what it costs a visitor waiting on a phone in direct sun outside a Laguna Beach gallery. Sometimes the honest answer is yes, and you keep it and optimize around it. Sometimes the honest answer is that the effect was never doing much work and the load time was doing real damage the whole time.
The site we built for a boutique hotel in Laguna Beach kept the mood — the photography, the warmth, the sense of the actual place — while passing Core Web Vitals cleanly, and neither of those things happened by accident or by compromise. They happened because every heavy element got the same question asked of it before it shipped. That is the actual job description for design and development done together instead of handed off in sequence: nobody gets to add weight without also owning what it costs.
Beautiful and fast are not actually in tension. Lazy and fast are. Most of what gets blamed on "design" wrecking performance is really just nobody on the project owning the cost of a choice after it got approved in a mockup.