我想知道何时应该包含外部脚本,或者在性能和易维护性方面将它们与html代码一起内联。
这是什么一般做法?
真实世界 - 我有几个需要客户端表单验证的html页面。为此,我使用了一个jQuery插件,我将其包含在所有这些页面中。但问题是,我是否:
感谢。
答案 0 :(得分:111)
在最初发布此答案时(2008年),规则很简单:所有脚本都应该是外部的。无论是维护还是性能。
(为什么性能?因为如果代码是独立的,浏览器可以更容易地缓存它。)
JavaScript不属于HTML代码,如果它包含特殊字符(例如<
,>
),它甚至会产生问题。
如今,网络可扩展性已发生变化。由于发出多个HTTP请求的延迟,减少请求数已成为一个有效的考虑因素。这使得答案更加复杂:在大多数情况下,建议使用 。但是对于某些情况,特别是非常小的代码片段,将它们内嵌到网站的HTML中是有道理的。
答案 1 :(得分:31)
可维护性绝对是将它们保持在外部的一个原因,但是如果配置是单行的(或者通常比将这些文件设置为外部的HTTP开销更短),那么在性能方面更好地保持它们内联。永远记住,每个HTTP请求在执行时间和流量方面都会产生一些开销。
当你的代码长于几行并且并非真正特定于单个页面时,这一切都变得无关紧要。您希望能够重用该代码的那一刻,将其置于外部。如果不这样做,请查看其大小然后再决定。
答案 2 :(得分:21)
外化javascript是雅虎性能规则之一: http://developer.yahoo.com/performance/rules.html#external
虽然你应该总是外化脚本的硬性规则通常是一个不错的选择,但在某些情况下你可能想要内联一些脚本和样式。但是,您应该只列出您知道会提高性能的内容(因为您已经对此进行了测量)。
答案 3 :(得分:19)
如果你只关心性能,那么这个帖子中的大多数建议都是错误的,并且在SPA时代变得越来越错,我们可以假设在没有JS代码的情况下页面是无用的。我花了无数个小时来优化SPA页面加载时间,并使用不同的浏览器验证这些结果。通过重新编排你的html来提高性能可能会非常引人注目。
为了获得最佳性能,您必须将页面视为两级火箭。这两个阶段大致对应<head>
和<body>
阶段,但将其视为<static>
和<dynamic>
。静态部分基本上是一个字符串常量,您可以尽可能快地将响应管道向下移动。如果您使用大量设置cookie的中间件(这些需要在发送http内容之前设置),这可能有点棘手,但原则上它只是刷新响应缓冲区,希望在跳转到某些模板代码之前( razor,php等)在服务器上。这可能听起来很难,但我只是在解释它是错误的,因为它是微不足道的。正如您可能已经猜到的,这个静态部分应该包含内联和缩小的所有javascript。它看起来像
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>
由于您无需花费任何费用即可将此部分发送到网络,因此您可以预期客户端将在连接到您的服务器后开始接收大约5ms +延迟。假设服务器相当接近,则此延迟可能在20ms到60ms之间。浏览器会在收到后立即开始处理此部分,处理时间通常会占用传输时间20倍或更多,现在是服务器端处理<dynamic>
部分的摊销窗口。
浏览器需要大约50毫秒(铬,休息可能慢20%)来处理内联jquery + signalr + angular + ng animate + ng touch + ng routes + lodash。这本身就很神奇。大多数网络应用程序的代码都比所有流行的库都要少,但是我们说你的代码也一样多,所以我们会在客户端上获得延迟+ 100毫秒的处理(这个延迟获胜来自第二个传输块) 。到第二个块到达时,我们已经处理了所有js代码和模板,我们可以开始执行dom变换。
您可能反对此方法与内联概念正交,但它不是。如果您不是内联链接到cdns或您自己的服务器,浏览器将不得不打开另一个连接并延迟执行。由于这个执行基本上是免费的(因为服务器端正在与数据库通信),所以必须清楚所有这些跳转的成本都比没有跳转要多。如果有一个浏览器怪癖说外部js执行得更快,我们可以测量哪个因素占主导地位。我的测量表明额外的请求在此阶段会导致性能下降。
我在优化SPA应用程序方面做了很多工作。人们普遍认为数据量是一个大问题,而实际上是延迟,执行往往占主导地位。我列出的缩小库增加了300kb的数据,这只是68kb的gzip压缩,或2mbit 3g / 4g手机的200ms下载,这正是在同一部手机上检查它的延迟时间已经在其缓存中具有相同的数据,即使它是代理缓存的,因为移动延迟税(电话到塔延迟)仍然适用。同时,具有较低第一跳延迟的桌面连接通常具有更高的带宽。
简而言之,就在现在(2014年),最好内联所有脚本,样式和模板。
编辑(2016年5月)
随着JS应用程序的不断发展,我的一些有效负载现在堆叠了3兆字节以上的缩小代码,很明显,至少应该不再内联公共库。
答案 4 :(得分:14)
我认为specific to one page, short script case是(仅)内联脚本的可辩护案例
答案 5 :(得分:9)
实际上,使用内联javascript有一个非常可靠的案例。 如果js足够小(单行),由于两个因素,我倾向于选择内联javascript:
答案 6 :(得分:5)
您应始终使用外部脚本的另一个原因是为了更轻松地过渡到Content Security Policy (CSP)。 CSP默认禁止所有内联脚本,使您的站点更能抵御XSS攻击。
答案 7 :(得分:4)
我会查看所需的代码,并根据需要将其分成多个单独的文件。每个js文件只能保存一个功能等的“逻辑集”,例如。所有登录相关功能的一个文件。
然后,在每个html页面的网站开发期间,您只包含所需的内容。 当您使用您的站点时,您可以通过将页面所需的每个js文件组合到一个文件中进行优化。
答案 8 :(得分:4)
我可以为内联javascript提供的唯一防御是,当使用带有.net MVC的强类型视图时,你可以参考我认为有用的c#variables mid javascript。
答案 9 :(得分:3)
三个考虑因素:
答案 10 :(得分:2)
使用Firebug也可以更轻松地调试外部脚本。我喜欢单元测试我的JavaScript并拥有所有外部帮助。我讨厌在PHP代码和HTML中看到JavaScript,对我来说这看起来很麻烦。
答案 11 :(得分:2)
关于保持JavaScript外部:
ASP.NET 3.5SP1最近引入了创建复合脚本资源的功能(将一堆js文件合并为一个)。另一个好处是,当打开Webserver压缩时,下载一个稍大的文件将具有更好的压缩比,然后是更小的文件(也更少的http开销,往返等...)。我想这会节省初始页面加载,然后浏览器缓存就会如上所述。
除了ASP.NET之外,这个截屏视频更详细地解释了它的好处: http://www.asp.net/learn/3.5-SP1/video-296.aspx答案 12 :(得分:2)
外部脚本的另一个隐藏好处是,您可以通过jslint之类的语法检查器轻松运行它们。这可以帮助您避免许多令人心碎,难以发现的IE6错误。
答案 13 :(得分:1)
在您的场景中,听起来像在页面中共享的一个文件中编写外部内容对您有好处。我同意上面提到的所有内容。
答案 14 :(得分:1)
我觉得你在制作单页网站时应该使用内联,因为脚本不需要在多个页面之间共享
答案 15 :(得分:1)
Google已将加载时间纳入其网页排名衡量标准,如果您内联很多,蜘蛛通过您的网页抓取需要更长的时间,如果您需要更多内容,这可能会影响您的网页排名。在任何情况下,不同的策略可能会影响您的排名。
答案 16 :(得分:1)
在早期原型设计过程中,保持代码内联以获得快速迭代的好处,但确保在到达生产时将其全部放在外部。
我甚至敢说,如果你不能在外部放置所有的Javascript,那么你手上的设计很糟糕,你应该重构你的数据和脚本
答案 17 :(得分:0)
具有内部JS专家: 更易于管理和调试 您可以看到发生了什么
内部JS缺点: 人们可以改变它,这确实可以使您烦恼。
外部JS优点: 没有改变 您可以看起来更专业(或者至少我是这样认为的)
外部JS缺点: 难以管理 很难知道发生了什么。
答案 18 :(得分:-1)
始终尝试使用外部J,因为内联js始终难以维护。
此外,由于大多数开发人员建议在外部使用js,因此专业要求您使用外部js。
我自己使用外部js。