Tooltip data in the term map: 74% of a 454 KB payload on every page (644 terms)
Hi Jeff,
First, thanks for the plugin — the glossary structure and Term Studio are exactly what I needed, and I've built it out quite far. I'm probably running one of the largest installs out there, so I wanted to share some performance data that may be useful as you plan ahead.
My setup
- 644 glossary terms, each with a full definition
- ~1,300 articles that link to them automatically
- Single WordPress site, roughly 2,000 indexed pages
What I measured
The generated term map (/wp-content/uploads/clevlite-map/map-*.js) is now 454 KB uncompressed, and it loads on every page of the site, including articles that reference no glossary term at all.
Breaking down its content:
| Total file size | 454 KB |
tip fields (tooltip definitions) |
334 KB — 74% of the file |
| Everything else (id, term, url, canonical, relationship) | ~120 KB |
So roughly three quarters of the payload exists solely to power hover tooltips.
Why this matters
Two problems compound here.
First, tooltips don't exist on mobile. There's no hover on touch devices. Yet mobile visitors still download and parse all 334 KB of tooltip text they can never trigger.
Second, the file is served with Brotli, so the network transfer is fine — the cost is parsing and execution, and compression doesn't help there.
Here's what Lighthouse reports on one of my article pages (PageSpeed report):
- 526 KB of unused JavaScript flagged (essentially this file)
- 1.7 s of JavaScript execution time
- 2.7 s of main-thread work
- 8 long tasks on mobile
- CLS 0.231 on desktop — Lighthouse also flags a forced reflow, which I suspect comes from
linked-terms.jsinserting links into already-rendered text - Mobile lab LCP: 7.4 s on a throttled 4G connection
Google Search Console flags 1,000+ URLs on my site for CLS as a result.
One more angle worth knowing about: PageSpeed now has an "Agentic navigation" category — how readable a site is for AI agents. My page scores 1/3 on desktop, and CLS is one of the two failing audits. So this now affects AI visibility, not just Core Web Vitals.
What would help
A few ideas, in rough order of how much they'd help me:
- An option to exclude
tipfields from the generated map. Even just a toggle — sites that don't use tooltips, or that accept losing them, would drop the file by ~75% instantly. - Load tooltip definitions on demand, via a small REST request on hover, rather than shipping all of them upfront. Best of both worlds, and it would scale to any glossary size.
- A filter hook on the map data before it's written, so site owners can strip fields themselves without patching the plugin.
- Only enqueue the map where it's needed — glossary pages and posts that actually contain linked terms.
Is there already a way?
Before I work around this myself: is there an existing setting or filter to disable tip generation that I've missed? I've gone through General, Styling and Add-Ons without finding one. If there's a hook I can use today, that would unblock me immediately.
Happy to run tests on my install if that's useful — I have a large, real-world dataset and I can measure before/after on request.
Thanks again for the work,
Fabien — youtips.com
will investigate and review further.