分类归档: Web

Web 前端优化最佳实践之 Server 篇

Web 前端优化最佳实践第二部分面向 Server 。目前共计有 6 条实践规则。【注,这最多算技术笔记,查看最原始内容,还请访问:Exceptional Performance : Best Practices for Speeding Up Your Web Site

1. 使用 CDN (Use a Content Delivery Network)

国内 CDN 的普及还不够。不过我们有独特的电信、网通之间的问题,如果针对这个作优化,基本上也算能收到 CDN 或类似的效果吧(假装如此)。【Tin 说国内 CDN 用的挺多,看看 CDN 厂商的市场就知道了,还没走入寻常百姓家】

2. 添加 Expires 或 Cache-Control 信息头 (Add an Expires or a Cache-Control Header)

各个浏览器都有针对的方案, Apache 例子【注意:下面的说明例子还不够精细,具体的环境上还要加一些调整】:

ExpiresActive On
ExpiresByType image/gif "modification plus 1 weeks"

Lighttpd 启用 mod_expire 模块 后:

$HTTP["url"] =~ "\.(jpg|gif|png)$" {
expire.url = ( "" => "access 1 years" )
}

Nginx 例子参考:

location ~* \.(jpg|gif|png)$ {
if (-f $request_filename) {
expires      max;
break;
}
}

3. 压缩内容 (Gzip Components)

对于绝大多数站点,这都是必要的一步,能有效减轻网络流量压力。或许有人担心对 CPU 压缩对于 CPU 的影响,放心大胆的整吧,没事儿。Nginx 例子:

gzip            on;
gzip_types      text/plain text/html text/css ext/javascript;

另外参见:

4. 设置 Etags (Configure ETags)

对于 Etag,可能是多数网站维护者都会忽略的地方。在这一系列优化规则出现之前,可能互联网上绝大多数站点都对这个问题忽略了。当然,Etag 对多数站点性能的影响并不是很大。除非是面向 RSS 的网站。【看到有朋友批评说写的简略,并且说 IE 不支持 ETag。明确说一下:IE 支持 ETag,倒是使用 IIS 要注意相关 Etag Bug。】

补充:我的意思是”很多网站在不注意的情况下都是打开 Etag 的,而没有网站关心如何用,消耗资源而不知。并不是说 Etag 不好,合理利用 Etag ,绝对能取得很好的收益.

5. 尽早刷新 Buffer (Flush the Buffer Early)

对这一条,琢磨了半天,貌似还是异步的思路。能更好的提升用户体验?

6. 对 AJAX 请求使用 GET 方法 (Use GET for AJAX Requests)

XMLHttpRequest POST 要两步,而 GET 只需要一步。但要注意的是在 IE 上 GET 最大能处理的 URL 长度是 2K。

前一篇:

下一篇分析一下 Cookie 。

EOF

Updated: 另请参见楼下高春辉的留言,很精彩

Web 前端优化最佳实践之 内容篇

Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献。广为人知的优化规则也由 13 条到 14 条,再到 20 条,乃至现在的 34 条–真是与时俱进啊。最新的 34 条也针对不同的角度做了分类。

面向内容的优化规则目前有 10 条。

1. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests)

作为第一条,可能也是最重要的一条。根据 Yahoo! 研究团队的数据分析,有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少 HTTP 请求:

2. 减少 DNS 查找 (Reduce DNS Lookups)

必须明确的一点,DNS 查找的开销是很大的。另外,我倒是觉得这是 Yahoo! 所有站点的通病,Yahoo!主站点可能还不够明显,一些分站点,存在明显的类似问题。对于国内站点来说,如果过多的使用了站外的 Widget ,也很容易引起过多的 DNS 查找问题。

3. 避免重定向 (Avoid Redirects)

不是绝对的避免,尽量减少。另外,应该注意一些不必要的重定向。比如对 Web 站点子目录的后面添加个 / (Slash) ,就能有效避免一次重定向。https://www.dbanotes.net/arch 与 https://www.dbanotes.net/arch/ 二者之间是有差异的。如果是 Apache 服务器,通过配置 Alias 或mod_rewrite 或是 DirectorySlash 能够消除这个问题。

4. 使得 Ajax 可缓存 (Make Ajax Cacheable)

响应时间对 Ajax 来说至关重要,否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是 Cache 。其它的一些优化规则对这一条也是有效的。

5. 延迟载入组件 (Post-load Components)

6. 预载入组件 (Preload Components)

上面两条严格说来,都是属于异步这个思想灵活运用的事儿。

7. 减少 DOM 元素数量 (Reduce the Number of DOM Elements)

8. 切分组件到多个域 (Split Components Across Domains)

主要的目的是提高页面组件并行下载能力。但不要跨太多域名,否则就和第二条有些冲突了。

9. 最小化 iframe 的数量 (Minimize the Number of iframes)

熟悉 SEO 的朋友知道 iframe 是 SEO 的大忌。针对前端优化来说 iframe 有其好处,也有其弊端,一分为二看问题吧。

10. 杜绝 http 404 错误 (No 404s)

对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪能有效减少 404 错误,亦能提升用户体验。值得一提的是,CSS 与 Java Script 引起的 404 错误因为定位稍稍”难”一点而往往容易被忽略。

这是内容篇的 10 条。应该说具体引导性的内容还不够详细。逐渐会根据自己的理解补充上来。

EOF

关于 Discuz! 的二次开发

可能是因为 Discuz! 庞大的用户群的原因吧,发现有些中小网站也有在 Discuz! 基础上做二次开发的,巧的是,到了某个阶段,不约而同的遇到类似的问题:开发进度明显滞后。

个人觉得 Discuz! 设计的初衷是面向中小站长的,对于二次开发可能并不是很重视。去官方论坛看了半天,甚至都没有专门二次开发的板块。莫非大家的二次开发都是各自为政,摸着黑搞的么?(好像的确是这样,代码开源,对着修改就成) 一些简单的门户开发估计问题都不大的,如果业务复杂一些,并且流量相对较大,可能隐忧就会比较明显了。

有次因为要验证一点东西,看了一点 Discuz! 的代码,发现一些基本的模块性能上并非很好(我自己并不很懂 PHP,只是出于性能考虑罢了),类似的页面在一定规模下并不会对性能有太大影响,可一旦突破某个量级,影响就非常明显了。有的网友可能会说,别装了,你不知道 Discuz! 功能有多强大吧? 问题可能恰恰就在于功能强大这儿了,一个软件如果自身已经在一些细节上考虑的足够细致,那么无疑也会给二次开发带来不必要的开销。就这一点上说,或许 Discuz! 有必要开发一个面向二次开发的版本,削减一些锦上添花的小功能。

另外,UCenter 这个 SNS 产品我觉得也不会有太大作为,千站一面的 SNS ,除了让大家消磨一些无谓的时间,会带来什么创新呢?

这只是我心血来潮,对产品设计的一点思考罢了,可别真的绕到 Discuz! 到底有哪些优点上去…

EOF
更新,有朋友和我说

Discuz! 代码里面本身包含监控隐私的东西,如果你的网站达到一定数量的用户,程序会触发通知 Discuz! 公司。

谁来证实一下?

附加阅读:

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

IIS 如何启用 GZip 压缩

微软 IIS 上如何启用 Gzip 压缩机制? 或许看过 YSlow 优化规则并且正在使用 IIS 的朋友比较关心这个问题。

基本步骤可以参考微软官方指导,直接一点的方式通过命令行执行如下命令启用对动态/静态内容的压缩输出:

appcmd set config /section:urlCompression /doDynamicCompression:True
appcmd set config /section:urlCompression /doStaticCompression:True

添加一个新的 Web Service Extension (如果原来没有的话) ,输入 gzip.dll 的全路径 。

IIS 6.0 上压缩额外的文件扩展名

修改 MetaBase.xml 文件中 HcFileExtensions 添加额外的文件扩展名。

IIS 7.0 上压缩额外的文件扩展名

修改 ApplicationHost.config 文件,添加合适的 mimeType 并指定激活. 打开文件参考原有的行照葫芦画瓢就成。可能要设置多次才会成功,因为 mimeType 定义可能有些歧义

记录一下,备忘。

EOF