fre*_*ler 5 browser performance jquery
在我开始学习如何使用jQuery库之前,我想让我自己放心一些关于文件大小的问题...
我很清楚浏览器和服务器会缓存jQuery等文件 - 理论上讲,文件应该只下载一次,因此后续使用的速度会提高.
我的问题更多的是关于浏览器如何处理javascript文件,以及每次加载页面时浏览器是否正在处理32k代码文件是否会产生不利影响？这不仅仅是文件的大小,而是它的复杂性.
或者我的理解不正确,浏览器不仅缓存javascript文件,还缓存该文件的某种"编译"版本？(是的,我知道 javascript实际上并没有"编译",但希望你知道我的意思.)
我想大多数浏览器都能够足够快地处理文件,以至于它几乎没有区别,并且必须处理使用jQuery编写的更少代码的速度优势弥补了它.
您对资产大小和 js 引擎性能的担忧有一些您需要考虑的重叠因素。最终，只有您才能确定什么是适合/可接受的项目。
可能说明显而易见，但我们将从这里开始。
任何减少页面消耗的资产大小的机会都是一件好事。保持你的标记、样式和 js 精益。避免采用这样的心态，即您的用户群始终可以使用高速连接。例如，考虑移动受众以及他们的连接速度将如何波动。快速加载的页面是获得出色用户体验的第一步。
修剪脂肪并确保您已验证将 jQuery 包含到您的项目中。
您的陈述“在我开始学习如何使用 jQuery 库之前”让我相信您可能是 Web 开发和 js 开发的新手。无意挖掘你或你问题的有效性，但这个假设将推动我在这里的目标。
总的来说，让自己接触 jQuery 库将是一件好事，即使它不是您项目的正确选择。
多年来，jQuery 库已经成熟到非常出色，并为日常跨浏览器 js 问题提供了一些优雅的解决方案。浏览源代码并了解一些实现的概念只会对您有所帮助。
此外，jQuery 无处不在。不管您可能形成什么个人意见，jQuery 是开发人员工具箱中最受欢迎的库之一，而且似乎无处可去。即使您从未在从头开始开发的项目中使用 jQuery，您也一定会在此过程中遇到某个地方。熟悉库只会有利于您的开发工作。
最终，您需要评估为什么要考虑将 jQuery 引入您的项目。它只是您最常使用的选择器引擎吗？如果您正在进行基本的 DOM 操作并且只需要一个好的选择器引擎，请考虑直接使用Sizzle，它只有 4KB（缩小和压缩）。
也许 jQuery 是您想要包含的一个很酷的插件的依赖项。你能自己重写它以使其精益求精吗？调整工作大小并检查工作是否值得可能节省的文件大小。如果您只节省了几 KB，但需要 40 个小时才能完成工作，是否值得？
创建浏览器支持矩阵。您支持的浏览器不仅会直接影响速度，还会直接影响资产的大小。
检查支持的 js 引擎的性能差异。这将允许您预测页面上 js 的速度，从那里您可以对您认为可以接受的做出任何让步。
请记住，js（您的和 jQuery 等库的）的质量和完整性也会极大地影响性能。更快的 js 引擎，如V8 for Chrome 可能对编写得不好的 js 更宽容一些，而 IE7 的JScript可能会暴露缺陷并大大降低性能。
jQuery 是一个库，它肯定会影响为核心编写的 js 的性能。您可能会发现，大多数性能受到挑战的 jQuery 来自 3rd 方插件，这些插件可能不会进行广泛的跨浏览器基准测试。
如上所述，jQuery 打包了许多跨浏览器修复程序，以弥补 DOM API 支持中的各种不足。这可能会为您节省大量精力或增加一些可能不需要的膨胀。检查您的支持矩阵倾向于哪种方式（旧浏览器与现代浏览器）并确定这可能如何影响您的项目。如果您发现自己只针对最新最好的浏览器，可以想象您可以编写自己的 jQuery 建模库，只添加项目所需的功能。不要忘记调整工作的大小，看看它如何影响底线。
底线是，如果您的项目严重依赖 js 来辅助功能和用户体验，那么很难说使用 jQuery 将是一个糟糕的选择。当您考虑到所需的工作量时，您可能没有足够的工时来编写更精简/更高效的代码。不仅要考虑创建等效库（即使删除了功能）所需的工作量，还要考虑维护它所需的工作量。您需要拥有与一大群开发人员同等的编码能力才能跟上步伐。
不管你怎么决定，祝你好运！