试用了这几天的 ngx_pagespeed 还是放弃了!

最近给所有的站点都启用了 Fastcgi_cache 和 ngx_pagespeed ,具体大家可以参考【Nginx下使用Fastcgi_cache和ngx_pagespeed优化WordPress性能】一文,整体上来说对 Fastcgi_cache 还是很满意的,缓存很稳定,几乎没有不兼容的场景,缓存效能也是非常的突出,就是 ngx_pagespeed 模块感觉在国内使用真的是有点儿“水土不服”了。今天就来说说 ngx_pagespeed 的这些“水土部分”吧。

NGX_pagespeed_tw.png

首先 ngx_pagespeed 是谷歌旗下的产物,也就是著名的PageSpeed技术的 Nginx 模块化的产物,主要的功能是针对前端页面而进行服务器端的优化,对前端设计人员来说,可以省去优化css、js以及图片的过程。

在试用的这几天,明月就发现会多出很多的失效JS链接和JS语法错误等等,罪魁祸首就是 ngx_pagespeed 的“优化”。至于原因我个人分析估计是JS代码标准化的问题,国内很多的JS代码在标准化上都不是很“规范”,特别是第三方的JS代码这类现象比较重要,当然不排除是 ngx_pagespeed 本身优化的问题。那么JS失效链接和语法错误过多后自然就影响到网页的载入时间了。

目前的 ngx_pagespeed 模块虽然是支持 Redis 的,明月也启用了,但是发现 Redis 进程总是会无缘无故的被终止,在关闭了 ngx_pagespeed 模块后此类问题就没有了,看来 ngx_pagespeed 对 Redis 的支持还是不稳定呀,毕竟 Redis 不是 ngx_pagespeed 一个使用的,一旦被终止进程会影响到其他使用 Redis 服务的进程的,所以只能暂停 ngx_pagespeed 的 Redis 了。

因为站点需要启用 CDN 服务,在启用 CDN 后就发现好像国内很多的主流免费 CDN 对 ngx_pagespeed 的支持都不是很好,静态文件的回源率非常的高,主要原因还是不兼容 ngx_pagespeed 模块生成的静态文件造成的。

综上所述,最终我还是停用了 ngx_pagespeed 模块了,目前 Nginx 里保留着 ngx_pagespeed 模块,期待新版本的 ngx_pagespeed 会有所改善。到时再折腾试试了!

最后修改:2017 年 08 月 02 日 05 : 10 PM
如果觉得我的文章对你有用,请随意赞赏

8 条评论

  1. Koolight

    还没有条件折腾到这一步!

    1. 明月登楼
      @Koolight

      呵呵,现在的ECS已经很便宜了!所以会有这一步的!

  2. 明月登楼

    是的!确实,折腾来折腾去的还是回到了起点!

  3. 懿古今

    现在我的站点打开速度还开,所以连 Fastcgi_cache都还没有折腾,等以后访问量大了再考虑是否折腾这个

    1. 橘子书
      @懿古今

      其实,真是够用就好。

    2. 明月登楼
      @懿古今

      嗯,其实“速度”够用就可以了!

  4. 薅羊毛

    功能够用就行

    1. 明月登楼
      @薅羊毛

      是呀,够用就行了!其实我到现在的 Typecho 真的很快了!至少我是很满意的!

发表评论