为什么人们缩小资产而不是HTML?

41 html minify

为什么人们建议缩小Web资产,例如CSS和JavaScript,但他们从不建议缩小标记?CSS和JavaScript可以在许多不同的页面上使用,而标记每次都会被加载,这使得标记的缩小变得更加重要.

Sal*_*ali 29

这里写的答案非常过时,甚至有时没有意义.从2009年开始,很多事情发生了变化,所以我会尽力回答这个问题.

简短的回答 - 你一定要缩小HTML.它今天微不足道,并提供大约5%的加速.对于更长的答案阅读整个答案

在过去,人们手动缩小css/js(通过运行一些特定的工具来缩小它).这个过程很难实现自动化,并且肯定需要一些技巧.知道现在很多高级站点都没有使用gzip(这是微不足道的),人们不愿意缩小html是可以理解的.

那么为什么人们缩小js,而不是html?当你缩小JS时,你会做以下事情:

  • 删除评论
  • 删除空格(制表符,空格,换行符)
  • 将长名称改为短名称(var isUserLoggedInvar a)

即使在过去,这也给了很多改善.但是在html中,你无法简短地改变长名,在那段时间里几乎没有什么可评论的.所以唯一剩下的就是删除空格和换行符.这只会带来少量改进.

这里写的一个错误的论点是,因为内容是用gzip提供的,所以缩小是没有意义的.这是完全错误的.是的,gzip减少缩小的改进是有意义的,但是为什么你应该gzip注释,如果你可以正确修剪它们的空格并且gzip只是重要的部分.这就像你有一个存档文件夹有一些你永远不会使用的垃圾,你决定只是拉链而不是清理和压缩它.

另一个为什么毫无意义地进行缩小的论点是它很乏味.可能在2009年就是这样,但在此之后出现了新的工具.现在您无需手动缩小标记.对于像Grunt这样的东西,安装grunt-contrib-htmlmin并配置它来缩小你的html 是微不足道的.你只需要2个小时来学习咕噜声和配置一切,然后一切都在不到一秒的时间内自动完成.听起来1秒钟(你甚至可以通过grunt-contrib-watch自动完成任务)对于大约5%的改进来说并不是那么糟糕(即使使用gzip).

还有一个论点是CSS和JS是静态的,HTML是由服务器生成的,所以你不能预先缩小它.这也是真正在2009年,但目前更多的更多的网站都看起来像一个单页的应用程序,其中,服务器是薄客户端是做所有的路由,模板和其他逻辑.所以服务器只给你JSON,客户端呈现它.这里有很多关于页面和不同模板的html.

所以完成我的想法:

  • 谷歌正在缩小HTML.
  • pageSpeed要求你缩小html
  • 这是微不足道的
  • 它提供了约5%的改善
  • 它与gzip不同

  • @MahdiYounesi 没有人维护最小化的资产。当您缩小 html 时,您并没有删除现有的非缩小版本。也没有人告诉你,一旦你缩小了 html,你就不应该改进你的 images/js、uze gzip 等。你可以做所有的事情。 (2认同)

Tri*_*ych 26

一个可能的原因是标记通常会更频繁地更改,并且必须针对每个页面加载进行缩小.例如,在给定的Stack Overflow页面上,有时间戳,用户名和rep计数可能会随着每个页面加载而改变,这意味着您还必须缩小每个页面加载.使用像css和javascript这样的"静态"文件,你可以更少地缩小,所以在某些人看来,这是值得的.

还要考虑每个主要的Web服务器和浏览器都支持gzip,它可以快速压缩所有标记(快速).因为缩小比gzipping慢得多且效率低得多,网站管理员可能会决定缩小每个页面的负载并不值得花费处理成本.

  • CSS和JS也可以gzippable,但缩小仍然被视为具有显着的好处. (7认同)
  • 对我来说,这些是独立的领域.缩小是关于去除箔条,不必要的材料,不影响结果.压缩是关于压缩剩余部分.Gzip确实很棒,但是当我们将它减少到零时,gzipping <! - end head div - >没有意义. (5认同)
  • 极为重要.通过缩小gzipping减少约70%,通过缩小gzip压缩文件减少约5%. (4认同)
  • @Adrian我不会去_quite_那么远.偶尔有充分的理由保存每​​个字节.*I*讨厌缩小的原因是它经常使浏览器内的调试成为一种痛苦,而且通常有更好的方法来加速网站. (4认同)
  • @rjmunro--这是一个相当大的逻辑飞跃.当然,您在服务器端缩短了时间,而不是在客户端解析时间.Gzipping减少了浏览器必须下载的数据量,这通常会大大超过解压缩所需的时间. (3认同)
  • @Austin Triptych是对的.我讨厌推动不属于评论的讨论,但只是格式化JS文件无助于调试.他的观点有效且适当缩小意味着变量名称变为单个字母.更改所有变量名称后尝试调试.关键是,如果我想格式化别人的缩小代码,你的美化是很酷的,但是当我只能查看原始代码而不是未缩小版本时,它在开发控制台中没有任何帮助. (3认同)

Alo*_*hci 13

考虑一下:

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Demo</title>
<link rel="stylesheet" type="text/css" href="nonminify.css"/>
</head>
<body>
<div title="My   non   minifiable   page">
    <p class="http://www.example.com/classes/class/lorem-ipsum">

            Lorem ipsum dolor sit amet, consectetur adipisicing elit, 

            sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. 

            Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris 

            nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in 

            reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla 

            pariatur. Excepteur sint occaecat cupidatat non proident, sunt in 

            culpa qui officia deserunt mollit anim id est laborum.

    </p>
</div>
</body>
</html>
Run Code Online (Sandbox Code Playgroud)

有了这个css文件:

div[title="My   non   minifiable   page"] 
      p[class~="http://www.example.com/classes/class/lorem-ipsum"]
{
    white-space:pre;
}
Run Code Online (Sandbox Code Playgroud)

鉴于此,对于只能看到HTML文件的HTML minifier实际上找不到可以安全缩小的任何内容实际上是不可能的.

  • 我怀疑white-space:pre声明是异常而不是正常,因为它很少使用. (4认同)
  • 没错,但不仅仅是白色空间:当然是前.DOM walk JavaScript也可以对minifier可以改变的空白区域进行假设.奇怪的是,尽管看起来很奇怪,但是在CSS和JavaScript中,空白是很重要的,而在CSS和JavaScript中,它通常不是 (2认同)
  • 我并不否认,网络上使用的99%的HTML页面可能会减少其空白区域而不会被破坏,但是会有1%的情况并非如此.我希望你的HTML minifier运气好,但如果它被大量使用,期望得到网络作者的一系列奇怪的bug报告,指责minifier打破他们的网页. (2认同)

Kie*_*ron 5

我认为这很难,因为有时像白色空间这样的东西用于格式化,可能取决于doctype.