图标悬停展示大量数据的最优实现方案咨询

问题1：页面加载时加载完整JSON vs 按需AJAX加载 #

15MB的JSON文件直接在页面加载时引入会严重拖慢首屏加载速度，尤其是移动网络或低速环境下，用户等待交互的时间会被大幅拉长。直接AJAX拉取完整JSON也会面临同样的首屏延迟问题，只是请求时机稍有延后。

最优方案是按需加载+预加载结合：

• 按需加载：仅在图标进入视口或用户即将触发悬停时，请求对应分组的数据（比如按页面区域把2000个图标分成若干组，每次加载当前视口内分组的数据）。
• 预加载：页面首屏加载完成后，利用用户空闲时间后台分批加载后续图标的数据，避免用户悬停时出现内容加载延迟。
• 辅助优化：给JSON文件开启gzip/brotli压缩，15MB原始JSON压缩后通常能降到3-5MB，大幅减少传输体积。

问题2：缓存HTML vs 前端渲染基础数据 #

缓存HTML的优势是后端直接返回渲染好的内容，前端无需额外计算；但缺点更突出：

• HTML体积远大于纯JSON数据，会增加AJAX请求的传输时间和带宽消耗；
• 后续修改悬停内容的样式或结构时，必须同步更新后端的HTML缓存逻辑，维护成本极高。

更推荐传输基础JSON数据，由前端负责渲染：

• JSON数据体积小，传输更快，且能复用HTTP缓存（设置合理的Cache-Control头）；
• 前端渲染灵活性高，样式或结构调整只需修改前端代码，无需改动后端；
• 现代浏览器的渲染性能足够处理单悬停50个小图标的渲染，用模板字符串或轻量模板引擎即可高效完成，不会有明显性能瓶颈。
• 额外优化：前端可以用Map存储已渲染过的图标悬停内容，避免重复渲染相同数据。

问题3：data URI vs 普通src路径 #

data URI的核心问题是无法缓存+体积膨胀：

• base64编码会让图片体积增加约30%，50个小图标累计下来会显著增加悬停数据的大小；
• 每次请求悬停内容都要重复传输这些base64数据，无法利用浏览器缓存，而普通src的图片只要设置了缓存策略，加载一次后就会存在本地。

更推荐普通src路径，配合以下优化：

• 启用HTTP2协议，多路复用特性可以同时加载多个小图标，不会像HTTP1.1那样因请求排队产生延迟；
• 给小图标设置长缓存时间（比如Cache-Control: max-age=31536000），并给文件名添加哈希（比如icon-abc123.png），避免缓存过期问题；
• 如果有大量重复的小图标，将其合并成CSS精灵图，进一步减少请求数。

内容的提问来源于stack exchange，提问作者OciXCrom