问 HN：为什么还要为简单的社交证明嵌入沉重的第三方 iFrame？
3 分•作者: LordKode•4 个月前
最近我在审计一个 React 网站时，注意到“爱的墙”小部件增加了 400kb 的 JS 文件和 3 个 iFrame，导致 LCP（最大内容绘制）指标大幅下降。这感觉不对劲。我们花了好几周的时间优化每一个像素，结果却因为一个缓慢的、黑盒式的客户评价轮播图而功亏一篑。<p>我决定构建 Reviewskits [0]，看看我们是否可以使用 Bun 和 Hono 转向纯粹的无头、数据优先的方法。<p>目标是：获取原始 JSON 数据，构建你自己的 UI 组件，并保持 100/100 的 Lighthouse 分数。<p>我向 HN 提问：你们是优先考虑预制小部件的“易用性”还是性能？或者说，业界已经准备好迎接开发者优先、无头的社交证明基础设施了吗？我很想听听你们在项目中是如何处理这个问题的。<p>[0] https://github.com/reviews-kits-team/reviews-kits
[1] https://reviewskits.com/
查看原文
I was auditing a React site recently and noticed that the 'Wall of Love' widget added 400kb of JS and 3 iFrames, tanking the LCP. It felt wrong. We spend weeks optimizing every pixel, then we throw it all away for a slow, black-box testimonial slider.<p>I decided to build Reviewskits [0] to see if we could move to a purely headless, data-first approach using Bun and Hono.<p>The goal: Fetch raw JSON, build your own UI components, and keep a 100/100 Lighthouse score.<p>My question to HN: Do you prioritize the 'ease of use' of pre-made widgets over performance, or is the industry ready for a developer-first, headless infrastructure for social proof? I'm curious to hear how you handle this in your projects.<p>[0] https://github.com/reviews-kits-team/reviews-kits
[1] https://reviewskits.com/