我们正在阅读并有一些想法的网络上的内容。是否有我们应该知道的链接？请告诉我们！
react-perf-devtool
阅读评论
这是 Nitin Tulswani 开发的一个有趣且非常有用的 Chrome 扩展程序，用于衡量 React 组件的性能
React Performance Devtool 是一款浏览器扩展程序，用于检查 React 组件的性能。它基于 React 使用 window.performance API 收集的指标，对 React 组件的性能进行统计分析。除了浏览器扩展程序之外，还可以在控制台中检查这些指标。
此外，如果您有兴趣了解有关此工具流程的更多信息，则有一个 很棒的帖子 深入探讨了该项目的历史。
2015-2017 年 WordPress 用户调查数据
通过释放 DevTools 协议的强大功能来监控未使用的 CSS
阅读评论
`font-size` 与所有视口单位
阅读评论
我们已经多次介绍了流体字体。 此页面 可能以最详细的方式涵盖了它。它比简单地使用 vw 单位设置 font-size 要复杂一些，因为那样变化太剧烈了。理想情况下，font-size 在最小值和最大值之间是真正的流畅的。
前端性能检查清单
阅读评论
Vitaly Friedman 提供了一个包含大量性能注意事项的清单。它很好地融合了旧策略（削减冗余，渐进增强等）和更新的考虑因素（树状抖动，预取等）。我喜欢包含一个 快速获胜 部分，因为很多事情都可以轻松完成；在陷入更困难的性能任务之前，完成这些事情很重要。
说到考虑性能，Philip Walton 最近深入研究了 在我们到处使用诸如 TTI 之类的首字母缩略词的世界中，交互式到底意味着什么。
但是“交互性”一词到底是什么意思？
我认为阅读本文的大多数人可能大体上知道“交互性”一词的含义。问题在于，近年来，这个词被赋予了技术含义（例如，在“交互时间”或 TTI 指标中），不幸的是，该含义的细节很少被解释。
其中一个原因是页面依赖于 JavaScript，而 JavaScript 尚未下载、解析和运行。这个原因已被广泛讨论，但还有另一个原因：“主线程”可能正忙于处理其他事情。这是性能的一个特别阴险的敌人，因此请务必阅读 Philip 的文章以了解更多信息。
此外，如果您喜欢前端检查清单，请查看 David Dias 的 前端检查清单。
CodePen 2017 年最受欢迎的作品
阅读评论
在我看来，这是最有趣的年末清单。
你是你所记录的内容
阅读评论
Yevgeniy Brikman 的这篇文章中有很多关于文档的小巧思。他深入探讨的内容不仅仅是记录代码，而是专注于我们如何记录工作的每个阶段，从设计到流程等等。
以下是我最喜欢的几句话，让我不禁拍案叫绝：
当开发人员使用您的代码时，他们实际上是在学习一门新的语言，因此请明智地选择其中的词汇。
……程序必须为人们编写，而只是附带地为机器执行。
我喜欢 Yevgeniy 的观点，即我们在编写代码时需要具备两种不同的思维方式：一种是为了让代码首先能够工作，另一种是为了解释我们如何以及为何以特定方式进行操作。在这些不同的工作阶段之间会发生上下文切换。
总之，从这个角度来看，文档可能不仅仅是锦上添花。相反，它可能只是工作量的 50%。
::part 和 ::theme，一个 ::解释器
阅读评论
Monica Dinculescu 谈到了 ::part 和 ::theme，这两个伪元素很可能在新年获得关注并受到更多关注。正如 Monica 解释的那样，它们旨在帮助我们创建和设置 Web 组件的样式
当前的新提案是
::part和::theme，这是一组伪元素，允许您在影子树内部从影子树外部设置样式。与:shadow和/deep/不同，它们不允许您在影子树内部设置任意元素的样式：它们仅允许您设置作者已标记为可设置样式的元素的样式。它们已经通过了 CSS 工作组的批准，并在 TPAC 的 Web Components 会议上被提出，因此我们相信它们既是正确的方法，也很可能被所有浏览器作为规范实施。
如果“影子树”这个词让你和我一样感到恐慌，请不要担心！Monica 已经写了一篇优秀的文章，深入探讨了 Web 组件和 Shadow DOM 规范。