这个问题很好地总结了这些天 Web 开发出了什么问题，所以我决定用这个答案来回答问题，还提供了回答 OP 的所有子问题所需的各种细节。
依赖只是因为 ?
我多次（从各种来源）听说 lit-html 的大小只有 2 或 3KB
为了在软件中产生最佳结果，我们通常决定包含一些依赖项，因为它的特性、它为我们解决了什么以及最终效果如何。
人们说一个库或实用程序很小的事实不应该自动翻译成“然后我会包含它”，特别是当你的最后一句话是：
我可以没有 lit-html
由于我对您的问题或使用lit-html没有太多的努力甚至热情，您确定您根本不需要它吗？
错误衡量的权衡
当我们谈论“ Web things ”时，我们通常会谈论生产代码，以及用于获取此类生产代码的所有常识性技术和最佳实践。
这包括使用静态文件压缩，因此默认情况下，仅导入render和html从lit-html导入将生成3.5Kb 的捆绑包，作为压缩和压缩的产品大小。
这就是你的数字的来源，即使比它的第一个版本稍微大一点，其中基础确实在大约 2Kb（压缩和压缩）中工作，lit-html 提供了 3.5Kb 的足够汁液，与万维网的其余部分。
您的favicon.ico或获取它的请求，携带所有最终的 cookie，可能已经对相似的（如果不是更大的）字节量进行加权。
你确定互联网的问题，甚至你的网站，是一个额外增加 3.5Kb 的库吗？
主要专家建议的面向移动的预算小于170Kb，缩小和压缩，大约是 lit-html 的 48 倍，我认为这对于您的初始逻辑来说已经足够了。
关于批评许可证
此外，最终的 dist 包中嵌入了 7 次：
不仅压缩使重复的文本大小几乎无关紧要，而且您还在争论来自 Google 产品的许可文本，如果我是您，无论如何我都会小心隐藏。
我认为 webpack 4 应该会自动删除评论。
当像/*! important */这样写注释时，通常由压缩器保留，因为源代码的作者打算留下该注释。
这是保留许可证的常用技术，但即使有工具不关心任何类型的评论，除非有不同的指示，例如--comments=/^!/通过uglify-js，请记住您的站点、应用程序、项目，即使用第三方软件，必须 以某种方式包含 此类软件许可。
我相信您并不是有意诋毁 Polymer 团队或 Google 许可证，但由于这件事非常微妙，我认为最好确保我们在这些问题上意见一致。
无论如何，如何最小化
我怎样才能使它与我的所有其他代码紧密地最小化（其中注释被自动删除并且所有内容都被放在一行中）？
默认情况下，Webpack 会保留重要的注释，除非您想将自己连接到 Webpack 内部以避免默认情况下这样做，否则您可以使用其中一种不会保留它们的工具，除非另有说明。
最常用的是UglifyJS。被称为uglify-jsnpm 模块，或者uglify-es对于 ES2015+ 代码，它默认剥离所有注释。
您npx甚至可以在不安装它的情况下尝试它：
npx uglify-es webpack/exported/lit-html.js
并且看到输出已经没有评论了。
自动化的方法是将 UglifyJS 安装为 devDependency，并直接或通过-o指令修改 webpack 文件，作为package.json脚本的入口。
备择方案
在 Webpack 和 Rollup 中集成 UglifyJS 非常容易，但是由于您已经了解 Webpack，我建议您看一下这个存储库，它的唯一目的是展示如何捆绑 lit-html 或 hyperHTML。
您可以在本地克隆、安装和测试它，以查看最佳结果，如果您已经针对支持 ES2015 的浏览器，则最终放弃 babel 转换（它会产生较小的结果）。
您可以实时验证一旦缩小和 gzip 压缩，包括“ Hello World ”代码，lit-html 在 Webpack 中的权重为 3.5Kb，在汇总中为 4.2Kb，但在使用整个预设环境进行转译后，您也可以调整为精细- 调整你的捆绑包。
作为总结
即使我是与 lit-html 竞争的主库的作者，阅读有关 10Kb 以下库彻底改变了我们开发 Web 的方式的抱怨也非常令人沮丧。
其他所有主流框架都比 lit 或 hyperHTML 重 5 到 20 倍，而且 Web 的问题比大约 5K 实用程序更大，所以请下次您看到您感兴趣的库的许可证时，它的大小与所有内容无关现在是网络，不要轻易攻击图书馆作者或只是尊重图书馆版权和许可的捆绑商。
谢谢你。