为什么主页面引入css文件background不起作用_页面加载性能之HTTP请求

文本内容、图片内容的优化都是基于本身大小的，但有一个更基础的方案可以实施，就是减少这些资源的下载频率。

减少资源个数，就可以减少HTTP请求个数。

合并文本资源

每个文件都需要发起一个HTTP请求，每个请求会消耗一定的时间，合并这些文件就能提升页面的加载速度。

CSS比较特殊，是层叠样式，同一个选择器不会报错和抛出异常，而是能正常运行，后者覆盖前者。但有时候这个会跟我们预期不一致，所以建议给一些特别的样式加特定的类名。如下：

h2 

合并文本资源对于减少HTTP请求数很有效，不过这样做的时候也要小心，后面会介绍一些注意事项。

合并图片资源

图片和文本一样，也可以通过合并的方式来减少HTTP请求数。

虽然这个方法可以适用于任意图片，但我们最常用的还是合并小图标，为这些小图标发起多个HTTP请求实在是一种浪费。

我们可以用CSS的background-position属性来展示相应的图片——俗称"精灵图"。CSS重定位非常快速、无缝，不用担心抖动问题。

你可能会有一系列的社交网站图标，比起下载3个单独的图片，合并成一张图片会更合适，如下：

以下是CSS的示例：

a

"facebook"的类里的"background-position"属性实际上是可以省略的，但此处为了保持一致性，所以保留。

注意事项

• 上面提到的合并文本和图片资源，在HTTP/2协议下，可能效果没有预期的那样，因为HTTP/2的请求更快，如果想了解更详细的，可以参考 https://developers.google.com/web/fundamentals/performance/http2
• 如果合并的资源里面包含一个频繁改动的动态资源，比如node_modules打包成的vendor.js，如果包含了一个首页的js文件，而首页改动频繁，会导致缓存失效，每次都要重新下载一遍整个vendor.js

JavaScript的位置和内联脚本（Inline Push）

我们假设所有的CSS和JavaScript资源都是存在于单独的文件，这也是最优的做法。脚本的加载是个巨大复杂的流程，详情可以参考这篇文章 Deep Dive Into the Murky Waters of Script Loading。有以下两个点值得注意：

脚本的位置

• 尽可能地把脚本放在body的结束标签上方，比起放head标签，这样不会阻塞页面渲染。
• 如果脚本需要操纵初始dom，或者在渲染期间提供一些函数，这类脚本可以单独放在head标签内引入，常见的有：window.onerror的事件绑定、反爬虫、性能监控等
• 最高效的资源加载顺序，也被称为关键渲染路径（Critical Rendering Path），详情可以参考：Bits of Code。

代码的位置

• 尽可能的避免将一个JavaScript拆成2个文件，最好的做法是把这部分拆分的代码直接内嵌在HTML文件中，成为内联脚本（Inline Push）.
• 当你想在渲染的时候展示一些已有的数据（例如：时间等），可以通过内联脚本，这样不用等待整个页面加载完就能显示出来。
• 内联脚本主要是解决两个问题：
  • 为了加载一小段代码，而发起一个HTTP请求的浪费
  • 让一些代码在渲染初期就能执行

<

总结

本文主要介绍了降低HTTP请求次数的一些方法，考虑了文本和图片两种资源。减少与服务器的交互次数，可以帮我们节省时间，加速页面的加载，让用户可以更快的看到内容。

参考

https://developers.google.com/web/fundamentals/performance/get-started/httprequests-5