LiteSpeed: mobile menu works only after reloading?

A new visitor taps the mobile menu and nothing happens. Reloading the page makes the same button work. The signed-in site owner may never encounter the failure. The reviewed report describes this pattern with LiteSpeed Cache’s Guest Mode and Guest Optimization enabled. Q1

Why the first visit needs its own test

LiteSpeed can serve an initial guest request differently and apply additional optimisations. A working signed-in view is therefore not an adequate control for a first visit. Even the statement that JavaScript optimisation is disabled needs to be checked against the guest route actually used. Q2

This pattern narrows the workflow, but it does not establish whether the menu script starts late, a dependency is absent or CSS makes an otherwise opened menu invisible.

Make the incident reproducible

1. Create a clean guest state: Use a new browser profile or clear only the test website’s site data. Record device, entry URL and time. Do not visit other pages on the same website beforehand.
2. Observe the first interaction: Tap the menu before reloading. Inspect whether classes or accessibility states on the button change. A state change without a visible menu suggests a different branch from a click handler that never runs.
3. Compare errors and resources: Preserve the first JavaScript message and the loading sequence of menu assets. Compare them with the successful second visit. A missing script, blocked request and delayed execution are distinct findings.
4. Test optimisations individually: On staging, compare the relevant guest and page-optimisation settings one at a time. Clear the affected cache and start with a fresh guest state after each change. An ordinary reload would miss the original condition. Q3

Narrow the permanent change

If one delayed resource and its dependencies are responsible, evaluate an appropriate exclusion in the correct optimisation context. If the menu’s CSS is missing, investigate CSS generation or rule selection instead. LiteSpeed documents different settings and exclusion mechanisms; they are not interchangeable. Q4

Verify the first tap, submenus, navigation to a second page and keyboard operation after the correction. The meaningful result is a working new visit, not merely a browser window whose resources and state are already established. Keep the clean-state steps with the incident notes so the same failure can be checked after later theme updates.

Frequently asked questions

Why can the site owner not reproduce it?

Their login and existing site data can select a different delivery route. The test needs to represent the visitor state that actually fails.

Should I exclude every script from optimisation?

A broad isolation test may help on staging. Afterward, reduce the permanent exception to the resources shown to be involved.

Is an invisible menu always a JavaScript failure?

No. Check whether the open state is correctly applied. If only its appearance is missing, CSS belongs in the investigation.

Information for support

Provide the test URL, theme, LiteSpeed version, guest settings and differences between the first and second visits. Do not send complete browser profiles.

KAN KAI WORKS can compare the initial guest view and menu initialisation. Get help with this case.