毕竟，对前端来说，优化是不可避免的主题。 看着200(cache )和304的区别时，终于到达了雅虎方面总结的指导方针。 大概是10多年前的东西吧，值得参考。 因此根据原文总结了几个翻译。 原文地址： https://developer.Yahoo.com/performance/rules.html
减少初始访问的请求数，多使用缓存
页面会花很多时间下载组件们，因此会尽量减少使用的组件类型。 尽量将js、css等文件组合成一个文件。 所以现在有网络包的流程。 使用css精灵图将多个图像合并为一个图像，并使用background-image和background-position属性显示所需的图像片段。使用内容分发网络（CDN）emm .用户和web服务器之间的距离会影响响应时间，因此部署到地理位置较远的服务器可以加快页面加载。 所以第三方or可以自己制作CDN。添加Expires或Cache-Control在header这是强制缓存。 对于静态组件，请在header中为expires设置尽可能长的值，以防止其过期。 对于动态组件，请使用缓存控制。 但是，它们仅在有缓存的情况下进行了优化，不影响初次访问。 从33558www.Sina.com/http1.1开始，http请求包含Accept-Encoding属性，通常使用gzip。 当服务器收到这样的请求时，它压缩返回结果，返回结果中有内容编码： gzip。 主要压缩html，但也可以是css、js、json等。 但是，还是不要用pdf、png比较好。 他们已经被压缩了，重新压缩反而有可能会增加体积。打包组件css放在head上，允许页面逐步加载，用户可以尽快查看内容。 放置在尾部可能会触发并阻止页面重绘。 在把css放在前面js中输入head可能会并行下载block，增加用户等待时间。把js放在后面css公式容易触发计算，容易影响性能。 请不要在or中使用一次性公式。 使用少用css表达式适量将js和css独立文件。 独立会增加http请求的数量，但可以减少html大小或使用缓存。 内部联合会增加html大小，但减少要求。 所以例如，在首页上，可以将js和css内联化。 因为速度是最好的。 相对通用的css和js可以单独拿出并放入缓存中，以加快使用这些文件的所有页面的加载速度。 www.bing.com-- 202.89.233.100 (http://www.Sina.com/DNS )在网址中搜索ip地址。 (还记得主机文件吗？ 这就是为什么跨墙修改本机主机文件)可以缓存DNS。 例如，可以在用户的ISP或LAN维护的特殊缓存服务器上缓存，但也可以将其放在用户的计算机上。 如果客户端的DNS缓存为空，则DNS搜索数与网页中的唯一主机名数相同，如url、js、css和flash。 因此，可以适当减少唯一的主机名。将js与css独立成文件删除空格和注释以压缩文件。 选项模糊文件可以进一步压缩文件大小。 这不仅可以提高独立的js、css文件和内联，还可以通过使用gzip提高页面速度。减少DNS查找重定向请求通常没有缓存(除非使用Expires或Cache-Control )，否则重新加载新地址时，其平滑度无法与非重定向相比我记得如果在url上加上最后一个/，例如cn.bing.com/，否则实际上cn.bing.com会被重定向到cn.bing.com/。压缩js与css重复包含会产生不必要的要求，浪费性能。避免重定向ETags与If-Modified-Since相似，但更准确、更易于使用。 他们都是协议缓存。 当浏览器请求资源时，将检索响应。 可以使用ETag属性和Last-Modified属性。 前者表示此文件的唯一识别码，后者表示此文件的上次更新时间(秒)。 然后如果浏览器又需要这个文件，我会发送请求。 使用If-modified-Since和If-None-Match属性，带上次请求中提供的标识。 服务器收到请求后，根据这些属性进行比较，如果发现与当前文件属性匹配，则返回304 (使用浏览器缓存文件)。 ETags的缺点是同一文件的ETags因服务器而异，因此如果站点是多服务器，则最好使用Last-Modified而不使用ETags。 (我有一个想法。 可以在此基础上进一步优化点吗？ 如果正在使用此页面上的js文件。
然后，我们更新了js文件中的a方法，但该页不更新缓存，因为该页没有使用a方法。)。 当项目中的文件发生更改时，将重新计算散列值。 此外，所有文件(而不是每个文件都不同的散列)都是相同的散列，因此不能修改单个文件，也不能重新加载单个文件。 所以可以用chunkhash。 这是为每个js文件单独计算的hash。 但是通过j
s文件入口获取的css文件之流，就得用contenthash。） ajax也可以使用缓存 提高ajax速度的最主要办法是使ajax的responses可缓存。前面一些文件的优化方法也适用于response。如gzip压缩内容，减少DNS查询，压缩js，避免重定向，设置ETags。 如果用了Expires或Cache-Control，那么的确将response缓存了。此时在请求的url上加上时间戳，如&t=11223344。 尽早缓冲 在php中，可以使用flush()，将部分html先发送给等待的客户端。一般head部分内容可以作为一个先发送的内容，因为容易生成，且可以包含各类css与js文件，使得前端能在后端生成html的时候并行获取文件。 尽量使用get请求 post会先发送请求头，再发送内容，而get只要一个。不过ie中url最长不超过2k，所以发送数据很长的话，膜还是不要用get了。 不过有趣的是，post不带数据的话，表现得就像get一样。当然，根据http规范，get用于检索信息，post用于发送信息。所以从这方面来，检索的时候还是用get吧。 不过这只是从速度上考虑。如果是其它角度，比如危险的请求，不希望能被从url输入之类，不能重复使用的操作之类，当然还是用post啦~ 将次等重要的延后加载 页面最重要的部分先加载，而比如js之类可以在onload之后加载，如果页面离开js还有个大概样子的话，比如animations动画类的js就可以。 预加载 与延后加载不同的是，预加载是在浏览器空闲的时候请求一些可以缓存的内容，这样当用户在这个页面进行了操作之后，能直接用那些缓存的内容。 常用的预加载逻辑有： 无条件的预加载，一旦onload之后就加载。 条件预加载，根据用户行为，猜测需要的文件，从而提前加载。 预期的预加载，比如旧网站需要迁移到新网站了，就在旧网站提供新网站的预加载，这样以后用户切换到新网站，也不会和已有缓存的旧网站有很明显的性能区别。 精简dom元素数量 数量越多，越复杂，页面需要下载的字节就越大，操作起来也会更慢。所以尽量减少。 跨域拆分 拆分使得可以最大化并行下载。不过最好域名控制在2-4个，比如把html和动态内容放在www.a.com，把组件拆开放在www.b.com和www.c.com。 效率地使用iframes 了解iframes，以尽量效率地使用iframes。 适用场景： 展现第三方内容，如广告 安全的沙盒 并行下载script 缺点： 就算空白也会耗费性能 block页面的onload 非语义 避免404 除了那种“猜您的意思是XXX？”，一般404是无用的，它不仅会阻止并行下载，浪费服务器资源，浏览器也会尝试解析结果，浪费性能。 减小cookie的大小 cookie会附在http请求头中，所以减少大小能提高响应时间。 还可以适当设置过期时间，在适当的域级别设置cookie以免影响其他子域。 用不带cookie的域存放组件 对于某些请求，比如请求一张静态图片，可能并不需要cookie的附加信息，这时候就不要发cookie了。 为了实现它，我们可以用一个专门的域来存放这种资源。 它还有一个好处，即有些代理可能会拒绝缓存带cookie请求获取的内容。 减少js对dom的操作 用js访问dom很慢，所以尽量较少。 还可以缓存对元素的访问，离线更新完节点再操作dom树，避免js操作布局。 使用事件委托 可以将类似的时间绑定到父节点上，略去每一个div都绑定上，然后比如根据target来定位到触发div，再执行js。这样能显著提高速度。而且也可以尽早进行操作，添加删除div也跟简单。 css使用link import会被放到底部执行。而link可以在头部。 避免css的过滤器 在ie7以下，为了实现渐变，有AlphaImageLoader，但是它在下载图片时会阻止渲染并冻结页面，增加内存消耗，并且应用在每个div而不是图片上，更加浪费性能。可以使用PNG8代替，或者hack:_filter以免影响更高等级的浏览器。 优化图片 拿到图片之后，还可以进行一部分操作，如: 检查gif中图片调色板大小是否与颜色数对应，用 http://www.imagemagick.org/ 小工具可以完成。 将gif转为png减小体积。一般都可以转为png。 运行工具 http://pmt.sourceforge.net/pngcrush/ 或 jpegtran以压缩图片大小。 优化雪碧图 雪碧图里横排会比竖着排使文件更小，组合近似的颜色也能使整个颜色数较小。记得对移动端优化，并且尽量减少空隙，因为空隙大小虽然不太影响文件大小，但是对可用内存要求很高。差10倍的宽高可会差100倍的面积。 减少html中图片缩放 我们可以设置图片的宽高，所以要小心滥用，尽量避免需要100*100但是用的图是500*500。 使favicon.ico小且可缓存 favicon.ico会一直被请求，避免它404。而且因为他的位置，请求他会一直带cookie。在ie中，它还会干扰下载顺序，比如onload之后下载部分组件，ie就会先下载favicon.ico再下载组件。因此，尽量压缩它，最好在1k以下。 http://www.imagemagick.org/ 可以帮助压缩。 将之比如通过expire缓存到本地。 使组件保持25k以下大小 因为iphone不会缓存25k以上的文件。注意这里我们说的是未压缩的大小。这里也说明了压缩的重要，gzip未必够用。 将组件打包 将组件打包就像邮件里带有多个附件。一次请求获取多个组件，毕竟一个请求比多个请求快。不过可能有些不支持，比如iphone就不支持。 避免空img 空的img会导致浏览器再发一个请求，根据浏览器分为向当前页面所在目录发送请求（ie），向当前页面发送请求（chrome，safari）。 页面会一直企图加载直至加载失败，阻塞其它下载。 而且，对于访问量大的页面来说，这样浪费了服务器性能，产生的却是大量计划外的流量，而且如果是带cookie的，还有可能损坏这些数据。
附200（cache）与304区别：
200（cache)即浏览器使用本地缓存版本，最快，因为不用向web服务器发请求。一般可以用future-dated Expires 或 Cache-Control: max-age headers来告诉浏览器是否使用本地缓存版本。 304即浏览器发送一个“If-Modified-Since"条件请求，其中这个属性代表所请求资源上次请求时最后修改时间，如果服务器跟自己这里的last-modified比较，结果为浏览器本地缓存的版本已经是最新，则会304，然后使用浏览器缓存版本。即浏览器检查文件是否自其缓存的最后一个版本后是否被修改的响应（304s, on the other hand, are the response of the server after the browser has checked if a file was modified since the last version it had cached (the ·answer being "no")）。 从这个角度看，对于文件使用尽可能长的缓存时间（expires或cache-control：max-age），直接从200（cache）这种方式获取。如果文件有改动，修改文件名字或请求时带上版本号。