问HN：为什么还要嵌入复杂的第三方iFrame来获取简单的社交证明？
我最近在审核一个React网站时注意到，“爱之墙”小部件增加了400kb的JavaScript和3个iFrame，导致LCP（最大内容绘制时间）下降。这让我觉得不对劲。我们花费数周时间优化每一个像素，然后却为了一个缓慢的、黑箱式的推荐滑块而放弃这些努力。
因此，我决定构建Reviewskits [0]，看看我们是否可以采用纯粹的无头、以数据为先的方法，使用Bun和Hono。
我们的目标是：获取原始JSON，构建自己的UI组件，并保持100/100的Lighthouse评分。
我想问HN（黑客新闻）：你们是否优先考虑现成小部件的“易用性”而不是性能，还是行业已经准备好接受以开发者为先的无头社交证明基础设施？我很想听听你们在项目中是如何处理这个问题的。
[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/