Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on a page to render. Google considers LCP under 2.5 seconds “good” and over 4 seconds “poor.” LCP is a Core Web Vital and a ranking factor — slower LCP means lower search rankings.
The menu is rarely the LCP element itself (that’s usually a hero image or a headline), but menu resources can delay everything else on the page by competing for bandwidth and CPU time during the critical loading period.
How menu scripts block rendering
When a browser encounters a <script> tag without async or defer, it stops rendering the page, downloads the script, executes it, and then resumes rendering. If the menu script is 150KB and takes 200 milliseconds to download and 150 milliseconds to execute on a mid-range phone, the entire page render is delayed by 350 milliseconds.
This blocking behavior affects LCP directly. The hero image can’t render until the browser finishes with the script, even though the image has nothing to do with the menu. The user sees a blank page (or a partial page) for 350 milliseconds longer than necessary.
The fix is to load menu scripts with async or defer:
async: The script downloads in parallel with page rendering and executes as soon as it’s ready. The page might render before the script finishes.defer: The script downloads in parallel and executes after the HTML is parsed. The page renders without waiting for the script.
Both approaches remove the menu script from the critical rendering path, letting LCP happen without delay. The menu might appear a fraction of a second after the page content, but that’s imperceptible and far better than delaying everything.
CSS in the critical path
Menu CSS can also block rendering if it’s included in the main stylesheet or loaded as a render-blocking resource. The browser won’t render anything until all render-blocking CSS is downloaded and parsed.
If the menu CSS is 30KB within a 200KB main stylesheet, the browser parses all 200KB before rendering — even though most of the menu CSS isn’t needed until the user opens the menu. Extracting critical CSS (the styles needed for above-the-fold content) and deferring the rest reduces the blocking time.
For menu-specific CSS, the simplest approach is to include it in a separate file loaded with a media attribute or loaded via JavaScript after the page renders. The menu styles arrive after the page is visible, and when the user opens the menu, the styles are already cached.
Measuring menu impact on LCP
To see whether your menu is affecting LCP:
-
Run PageSpeed Insights on your store’s mobile homepage. Check the “Opportunities” section for “Reduce unused JavaScript” and “Eliminate render-blocking resources.” If your menu app appears in these lists, it’s contributing to slow LCP.
-
Open Chrome DevTools → Performance tab, run a mobile performance trace, and look at the waterfall. Find the menu script and CSS. Are they loading before the LCP element renders? If so, they’re in the critical path.
-
Compare LCP with and without the menu app. Temporarily disable the menu app and run PageSpeed Insights again. If LCP improves significantly, the menu was a bottleneck.
Navi+ is designed to stay out of the critical path. The script loads asynchronously, the CSS is minimal, and the menu renders after the page content is already visible. This means Navi+ doesn’t affect LCP — the page loads as if there’s no menu app, and the navigation appears seamlessly after.
This article is part of the larger guide on Mobile menu performance: why every millisecond matters.