Why does a corporate website look so high-end but take so long to open? Infer design and development decisions from Core Web Vitals

Website performance is not a technical issue that is dealt with only before the development and launch. The large images, videos, fonts, animations and layout methods on the first screen determine a significant amount of performance costs during the design stage.

01 "Visual Advanced" and "Slow Loading" are not mandatory bindings

When upgrading a corporate website, it often hopes to have full-screen videos, high-definition photography, 3D models, scrolling narratives, and multiple sets of fonts. The problem is not that these things cannot be used, but that everything is treated as "must be loaded immediately". Finally, the first screen of the home page looks like a brand blockbuster, but real users first see a few seconds of blankness or lag.

Google's current Core Web Vitals mainly focuses on three user experience dimensions: LCP represents the loading speed of the main content, INP represents the interaction response, and CLS represents the visual stability. The good threshold remains LCP ≤2.5 seconds, INP ≤200 milliseconds, and CLS ≤0.1, and the 75th percentile of actual user data is used as an important judgment.

02 LCP: The most important element on the first screen is actually the one that is most easily slowed down by design

The LCP elements on a corporate website are often Hero large images, product images, video posters or large titles. The LCP optimization documentation of web.dev states that critical resources should be discovered by browsers as early as possible, and particularly warns against using lazy loading on LCP images.

This is exactly the opposite of common development practices: to "unify image lazy loading", the team lazy all images. As a result, the main image on the first screen loaded even later. When delivering, the design and development should clearly define which images belong to the key resources of the first screen and give priority to loading. The case images, galleries and videos at the bottom of the screen will be further delayed.

03 The first-screen video is not unusable, but first ask if it's worth downloading

Videos are often much more expensive than static images. The latest video performance guide from web.dev recommends using poster and controlling resources through the preload policy. If the video is not immediately needed, you can avoid downloading a large amount of video data by default.

If the brand homepage is only for creating a slight background movement, it can be evaluated whether to replace it with shorter and smaller encoded videos, sequence frames, CSS/Canvas animations, or even high-quality static images. Users won't think your brand is more advanced just because you have used a 40MB video; they will only feel that the page is slow.

04 INP: The page has completed loading, but clicking on it does not immediately respond

INP measures the response delay in real interactions. A large amount of JavaScript execution, complex animation libraries, large DOM, and client-side rendering may all cause the main thread to be occupied by long tasks. The INP optimization guide for web.dev suggests reducing and splitting long tasks, optimizing event callbacks, controlling complex layouts, and client-side rendering.

This means that designers also need to restrain the interaction where "each module scrolls for calculation and each card follows the mouse in real time". A single effect may be smooth, but when more than ten are superimposed, there will be obvious lag on low-performance devices. Prioritizing important interactions and loading decorative interactions on demand is more stable than covering the entire site with dynamic effects.

05 CLS: The page "jumps", usually indicating that the size was not reserved in advance

CLS focuses on unexpected layout displacements. Common causes include unclear width and height of images, text reformatting due to font replacement, sudden insertion of Cookie banners or advertisements, and the page being pushed down after asynchronous content loading.

In the design draft, there is usually only the final state, so the layout jumps cannot be seen. When developing, space should be reserved in advance for pictures, videos and embedded content. The font strategy should take fallback into account. The top notification bar and Cookie layer need to decide whether to overwrite or occupy to avoid sudden structural changes when the page is halfway loaded.

06 Font: The most underestimated performance cost of brand upgrading

Introducing multiple sets of Web fonts with seven or eight Font weights for brand awareness can easily increase requests and font size. Font loading may also affect LCP and layout stability. A more reliable approach is to only load the actual font weight used, perform subsets, make reasonable use of font-display, and prepare fallbacks of similar sizes for font switching.

Special attention should be paid to bilingual websites in Chinese and English. Chinese font files are usually much larger than Latin fonts, and the solution of "embedding all brand fonts in the Web" cannot be simply adopted. Visual specifications and technical implementation should be synchronized during the font finalization stage, rather than being found to be unable to load at the end.

07 Performance design requires real user data. Don't just focus on Lighthouse once

Laboratory tests are suitable for locating problems, but Core Web Vitals itself emphasizes field data. Network, device, region and cache status all affect the real experience. A 95-point page on an office gigabit network doesn't mean that 4G mobile phone users overseas are equally fast.

After the project goes live, real user performance should be continuously observed through Search Console, Chrome UX Report or RUM. Especially for cross-border corporate websites, differences in CDN, server location, third-party scripts and regional networks may all be magnified. Performance is not a one-time acceptance but a continuous operational indicator.

08 Conclusion: The performance budget should be discussed together with the visual budget

In the design review, it might be a good idea to add a question to the visual scheme: how many resources need to be downloaded for this effect, how much JavaScript is required, whether it affects the first screen, and whether it should be retained on mobile devices. It's not about having designers write code, but about making the experience cost visible in the solution stage.

A high-end corporate website is not necessarily better with larger materials or more animations. Truly mature design lies in making trade-offs among brand expression, content understanding and performance, so that users do not have to wait for the "high-end feel" to load.

Frequently Asked Questions

What are the current three metrics of Core Web Vitals?

LCP, INP, and CLS respectively focus on loading, interaction response, and visual stability.

What is the good threshold?

Google currently recommends LCP ≤2.5s, INP ≤200ms, CLS ≤0.1, and pays attention to the actual user experience at the 75th percentile.

Can Hero images be lazy loaded?

If it is a primary LCP candidate, it should usually not be lazy loaded. web.dev explicitly recommends not delaying the LCP image on the first screen.

Will the homepage video definitely slow down the website?

Not necessarily, but the resource volume and loading strategy must be controlled. poster, lazy loading, compression encoding or mobile alternative solutions can be used.

Is a perfect score of 100 on PageSpeed the ultimate goal?

No. Scores are merely diagnostic signals. The key remains the real experience of core users and business needs.