perf(pricing): reduce INP, lazy-load calculators, defer YourGPT widget

[rusikv]

Summary

Performance + UX optimizations targeting /pricing/. Mobile PageSpeed Insights flagged INP at 220 ms (failing the >200 ms threshold) and YourGPT's Inter font on the LCP critical chain. This branch addresses those plus several follow-ups that surfaced during the audit.

Performance

• INP: rAF-batch slider input handlers, cache CSS variable reads via window._sliderColors, delegate per-element click listeners.
• Script Evaluation: lazy-load the six pricing calculators (~104 KiB) via dynamic import() — fetched only on first open / on pricing:product-activated for inline TBMQ.
• LCP critical chain: defer YourGPT widget (and its Inter font from Google Fonts) until first user interaction on the page; eager-load only for users who previously opened the chat (sessionStorage tb:chatbot-opened).
• Forced reflow: replace JS-positioned <div class="segment-highlight"> with per-tab CSS background, eliminating getBoundingClientRect() reads after class writes.
• Tooltip / FAQ binds: deferred to requestIdleCallback so they don't compete with the LCP paint.

UX

• Pre-paint inline <script> syncs the URL state (?section=, ?product=, ?solution=) to the DOM before first paint — deep-link visitors see the correct tabs + correct billing toggle immediately, with no flash of SSR defaults.
• Fix perpetual calculator CTA scrolling page to top (async openTbPerpCalc raced the href="#" follow).
• Remove the URL-driven ?calculator=… calc-open feature: the contract diverged from the legacy site, the default-fallback mapped Public Cloud → PE PAYG modal (UX mismatch), and no internal links used it.

Code review fixes

• Listener leak in DeferredLoadTrigger.__deferUntilInteraction timer path — flush listeners stayed attached if fallback timer fired before any interaction.

Commits

1. Reduce pricing-page calculator INP on mobile
2. Defer YourGPT widget until interaction on the current page
3. Eager-load YourGPT widget for users who actually opened chat
4. Lazy-load ThingsBoard modal calculators
5. Lazy-load inline TBMQ calculators
6. Delegate pricing-page click handlers from forEach to single root listener
7. Defer pricing tooltip binds + ?faqSection= handler to idle time
8. Replace JS-positioned segment highlight with per-tab CSS background
9. Fix perpetual calculator CTA scrolling page to top on click
10. Sync URL-driven pricing state from first paint via pre-paint inline script
11. Remove URL-driven calculator open feature
12. Fix listener leak in __deferUntilInteraction timer path
13. Sync ?solution= billing state in pre-paint inline script

Test plan

• pnpm build:fast passes
• pnpm lint:linkcheck passes
• /pricing/ cold load: no calc-*.js chunks in network waterfall until "Estimate your cost" is clicked
• All product/sub-tab switching, billing/region toggles, top-up accordions, plan-card CTAs behave identically
• FAQ click → expands; [data-open-calc] links open the right calculator
• Deep-link /pricing/#faq-foo scrolls + expands correct FAQ + activates correct product/sub-tab synchronously
• Deep-link /pricing/?product=thingsboard-pe&solution=pe-perpetual paints with Perpetual billing toggle on first frame — no flash of PAYG cards
• Tooltips appear on hover (first hover may have ~50 ms delay before idle binds complete)
• YourGPT widget appears after first interaction on a fresh tab; appears immediately on subsequent navs in the same session if user previously opened the chat
• View Transitions: / → /pricing/ → /about/ → back — calculators still openable, no duplicate listeners

[vvlladd28]

Review summary

Reviewed 19 changed files in perf(pricing): reduce INP, lazy-load calculators, defer YourGPT widget. The bulk is a careful extract-to-module refactor of six pricing calculators (logic preserved verbatim), plus real perf wins: rAF-batched slider input, lazy import() for the three modal calculators, pre-paint URL state sync, segment-highlight replaced with per-tab CSS, single delegated click listener replacing 10+ per-element loops, and the new __deferUntilInteraction API for the YourGPT widget. Left 5 inline comments — most are minor robustness asks; one (leaked dev path) is a clear cleanup before merge.

---

This is an auto-generated review. Findings may contain errors — please verify before applying changes.

[vvlladd28]

Review summary

Reviewed 19 changed files in perf(pricing): reduce INP, lazy-load calculators, defer YourGPT widget. The bulk is a mechanical move of the six calculators' JS from inline <script> blocks into lazy-loaded ~/scripts/pricing/calc-*.ts modules — I spot-checked the moved bodies (init guards, openImpl/data-inited idempotency, calculate() at init tail, slider math) and they preserve the original behavior. The genuinely new logic — delegated click handler, CSS-only segment highlight, _sliderColors cache + theme MutationObserver, pre-paint state sync, event.preventDefault() CTA fix — is sound: the delegated billing/region label clicks dispatch synthetic change that the existing handlers pick up (and the labels are <span>s, so there's no native double-toggle), and no dangling segment-highlight/moveHighlight/?calculator= references remain. Two observations left inline.

---

This is an auto-generated review. Findings may contain errors — please verify before applying changes.

[vvlladd28]

Worth confirming the View-Transition story here. The repo has no <ClientRouter /> (BaseLayout doesn't render one), so astro:page-load never actually fires — this re-install is currently dead. More importantly, if View Transitions are enabled later (the PR test plan exercises / → /pricing/ → /about/ → back), these modal calculators won't be VT-safe: p and openImpl in calc-tb-payg.ts are module-scoped and never reset, so after a navigation openTbPaygCalc() skips re-init (if (openImpl) return) and drives the previous page's detached #tb-payg-calc node — the modal would silently fail to open. The inline TBMQ calculators avoid exactly this by re-initialising against the fresh DOM via the data-inited container guard. Consider either dropping the dead astro:page-load wiring, or making the three modal calcs VT-safe the same way for consistency (same pattern in TbPerpetualCalculator.astro / TbPrivateCloudCalculator.astro).

[rusikv]

Fixed in 14565ca — dropped the dead astro:page-load listeners from TbPaygCalculator.astro, TbPerpetualCalculator.astro, and TbPrivateCloudCalculator.astro. Verified no ClientRouter / ViewTransitions reference exists in src/, astro.config.ts, or the Starlight integration config (Starlight's docs sidebar persists via a sessionStorage + pre-paint custom-element trick, not VT). Picked the deletion route over retrofitting the data-inited guard — VT isn't on the roadmap and removing the misleading dead code is preferable to adding speculative VT-safety scaffolding. If anyone wires up ClientRouter later they'll need to make these modules properly VT-safe, not just rely on a re-install hook that depends on module state surviving navigation.

[vvlladd28]

This pre-paint resolver duplicates ~40 lines of the URL→state logic (param parsing, sectionMap, the perpetual billing flip, the product/sub-tab/section activation) from initPricing() below, and the two copies have to be hand-kept in sync. The NOTE comments in both places help, but drift here fails silently — a future tweak to the billing flip or sectionMap in only one block won't break any test, it'll just reintroduce the FOUC this is meant to prevent (or paint a state that JS then corrects a frame later). Worth extracting the shared resolution into a single helper both the inline script and initPricing() call, so there's one source of truth.

[rusikv]

Acknowledged but not changing in this PR. The two URL→state copies are short (~40 lines), the NOTE comments at both ends explicitly call out the drift contract, and a shared helper that runs in both the inline pre-paint context AND inside initPricing()'s closure scope has its own coordination cost. Happy to revisit as a separate refactor if the duplication grows or drift bites — for now leaving the explicit-contract approach in place.

[vvlladd28]

Follow-up: YourGPT load-ordering regression

One more observation on the YourGptWidget change — left inline.

---

This is an auto-generated review. Findings may contain errors — please verify before applying changes.

[vvlladd28]

This moves the widget off the shared __deferOnInteraction trigger onto its own load + requestIdleCallback path, and in doing so it drops an intentional load ordering. The original deferral wasn't only about keeping the script/font off the critical path — it also guaranteed the chatbot loads after analytics:

• GtmHead registers __deferOnInteraction(loadGtm) with the default 2500 ms fallback.
• The old YourGPT used __deferOnInteraction(loadWidget, 10000) — a 10000 ms fallback.
• DeferredLoadTrigger runs pending callbacks in registration order, and GtmHead is mounted before YourGptWidget in ThirdPartyScripts.astro.

So in both the interaction and the no-interaction case, GTM/analytics loaded first. With the new load+idle trigger, on a no-interaction page load the widget can fire before GTM's 2.5 s fallback, so analytics is no longer guaranteed to load first.

Suggest reverting to (window.__deferOnInteraction || ((cb) => cb()))(loadWidget, 10000) — it keeps both the off-critical-path deferral and the analytics-first ordering.

[rusikv]

Fixed in c6f3c18 — restored to the pre-PR pattern __deferOnInteraction(loadWidget, 10000) where loadWidget wraps injectWidget in requestIdleCallback. Surfaced a second bug along the way: when DeferredLoadTrigger.astro:32's fired short-circuit runs the callback synchronously (tb:user-engaged set by a prior page), the body-append fires inside <head> parsing — the rIC bounce dodges that. Expanded the inline comment to document both invariants (analytics-first ordering + body-safety) so this doesn't get reverted blindly again.

[vvlladd28]

Please remove the comment that is not clear in production mode

[vvlladd28]

Review summary

Reviewed 19 changed files in perf(pricing): reduce INP, lazy-load calculators, defer YourGPT widget. The bulk of the diff is a clean mechanical extraction of the six calculator implementations out of their .astro <script> blocks into lazy-imported src/scripts/pricing/calc-*.ts modules. That part looks solid: the modal openers memoize the dynamic import() and reset the memo on failure for retry, init is idempotent (openImpl guard for modals, dataset.inited for the inline TBMQ calcs), the delegated click handler preserves the original side effects (e.g. billing-label clicks dispatch change, which still runs setBilling → updateFaqVisibility → updateUrl), the perpetual-CTA event.preventDefault() fix is applied in the component that actually renders that CTA (CommunityEditionCard), and the segment-highlight removal is safe because both tab components declare their styles is:global, so the shared .segment-tab.active rule still reaches the sub-tabs. Left 3 comments inline — one possible deep-link init gap, one question about dead View-Transitions machinery, and one maintainability nit.

Additional findings

These are about behavior that spans the file rather than a single changed line:

• src/pages/pricing/index.astro:1332 — document.addEventListener('astro:page-load', initPricing) (unchanged line) plus the new _pricingDelegCtl AbortController machinery and several new comments ("View Transitions keep the document alive", the TBMQ loader's "the script re-runs on each astro:page-load") all assume the SPA router is active. I couldn't find a <ClientRouter /> / viewTransitions anywhere in src/, astro.config.ts, or the Starlight config — so on these BaseLayout pages astro:page-load never fires and initPricing() runs exactly once per full load. If that's correct, the abort/re-run handling and re-dispatch guards are dead defensive code (harmless, but the comments are misleading). Worth confirming whether View Transitions are intended to be enabled — see the inline note at line 547.

---

This is an auto-generated review. Findings may contain errors — please verify before applying changes.

[vvlladd28]

This (and the identical loaders in TbmqPerpetualCalculator / TbmqPrivateCloudCalculator) initializes the inline TBMQ calculators only via a one-shot pricing:product-activated listener. On a deep-link that makes TBMQ the initial active product (?product=tbmq-payg, ?section=tbmq-options), initPricing() dispatches that event once at module-eval time (activateProductTab('tbmq')). That only works if this loader's <script> has already executed and registered the listener before the page's initPricing() script runs — i.e. it depends on the bundler's script-execution order. If initPricing() happens to run first, the initial 'tbmq' event is missed and the calculator stays uninitialized (dead sliders / no totals) until the user re-clicks the tab. Could you confirm a TBMQ deep-link initializes the calculator on first paint? If it's order-dependent, a more robust fix would be to have the loader also check the currently-active product on registration (e.g. read the .product-tab.active/visible content and import immediately if it's already tbmq), rather than relying solely on catching the one-time event.

[vvlladd28]

The _pricingDelegCtl abort-the-previous-controller pattern (and the comment justifying it — "initPricing() re-runs on every astro:page-load… View Transitions keep the document alive") only does anything if initPricing actually runs more than once. I couldn't find <ClientRouter /> / View Transitions enabled anywhere in the project, and these pages use BaseLayout, so astro:page-load never fires and initPricing() runs once per full page load. If that's right, prevCtl?.abort() is never reached and this could just be a plain addEventListener on main.pricing-page. Not harmful as-is, but is View Transitions something that's planned here, or is this machinery (plus the astro:page-load listener at the bottom) leftover from an assumption that isn't true on these pages?

[vvlladd28]

This pre-paint block re-implements ~60 lines of the URL→state resolution that initPricing() also does (sectionMap, param parsing, billing-toggle flip, tab/section activation), kept in sync only by the cross-referencing comments. It's a real correctness trap: a future change to param names, the sectionMap, or the billing markup has to be made in both places or deep-link first-paint silently regresses (the exact flash this block exists to prevent). Since the duplication is forced by the inline-vs-module split, consider at least factoring the shared resolver into a small function defined once in an is:inline script and called from both, so there's a single source of truth for the param→state mapping.

[vvlladd28]

Review summary

Reviewed 18 changed files in perf(pricing): reduce INP, lazy-load calculators, defer YourGPT widget. This is a careful, well-commented refactor and the core changes hold up: the delegated click handlers are behaviorally equivalent to the per-element listeners they replace (verified the region/billing-label <span>s don't double-fire with native <label> activation, and the PC billing checkbox does carry data-billing-toggle), the is:global styles make the segment-highlight→.active CSS refactor apply correctly to sub-tabs, the slider-color cache busts on the data-theme attribute the site actually toggles, and the lazy-load openers are idempotent with sensible retry-on-failure. Left 1 comment inline plus a few low-priority notes below.

Additional findings

Observations outside the inline-diff range or about the PR metadata:

• PR description vs. diff mismatch. The description's "Performance / LCP" section and "Code review fixes" describe deferring the YourGPT widget and a listener-leak fix in DeferredLoadTrigger.__deferUntilInteraction, but src/components/YourGptWidget.astro isn't in this PR's changed files, and __deferUntilInteraction doesn't exist in the tree (the function is __deferOnInteraction, and its only change here is an added comment). Either those commits landed separately or the description is stale — worth reconciling so reviewers/changelog aren't misled.
• "View Transitions" test-plan item is moot. There is no <ClientRouter /> / <ViewTransitions /> anywhere in the repo, so astro:page-load never fires on these BaseLayout marketing pages. That makes removing document.addEventListener('astro:page-load', initPricing) correct and the rewritten "no ClientRouter" comments accurate — but the test-plan line "View Transitions: / → /pricing/ → /about/ → back … no duplicate listeners" can't actually exercise a client-side transition (every nav is a full reload). (Separately, CalculatorModal.astro:1579 still registers an astro:page-load listener — harmless dead weight, pre-existing, not introduced here.)
• src/pages/pricing/index.astro:400 & :1295 — both the pre-paint script and initPricing() iterate every [data-billing-toggle] when activeBilling === 'perpetual', which also flips the Private Cloud toggle (tb-pc-billing) to its "annual" state on a ?solution=pe-perpetual deep-link. Impact is minor (PC has no data-billing-group content elements, so nothing is hidden, and PC isn't the deep-link target) and the behavior is pre-existing in initPricing() — but the new pre-paint copy now applies it before first paint too. Scoping the loop to the self-managed toggle would be more precise.
• src/components/Pricing/TbmqPerpetualCalculator.astro:51 (and the sibling inline TBMQ loaders) — loadCalc() re-invokes import(...) + initMqpCalc() on every pricing:product-activated for tbmq, without memoizing the promise the way the modal openers do (p ??= import(...)). Harmless since the module is cached and initMqpCalc() is idempotent, but it's inconsistent with the modal-opener pattern and does a (cheap) redundant init on each tab switch back to TBMQ.

---

This is an auto-generated review. Findings may contain errors — please verify before applying changes.

[vvlladd28]

initPricing() now hard-depends on window.__resolvePricingState, which is defined only by the separate pre-paint is:inline script near the top of <body>. The pre-paint block wraps its DOM work in try/catch, but this consumer has no fallback — if that inline script ever fails to run or throws (a CSP that blocks inline scripts, or a syntax error introduced into the block later), this destructuring throws and all of initPricing() aborts, leaving the entire pricing page non-interactive (tabs, toggles, accordions, calculators all dead).

Before this PR the param→state mapping was self-contained in initPricing(), so a failure here was impossible. Low probability given inline scripts are used elsewhere on the page, but the blast radius is the whole page — worth a guard, e.g. fall back to computing state locally when typeof window.__resolvePricingState !== 'function'.