Liferay前端性能调优(2) Liferay服务器上开启优化参数

因为我们应用是运行在Liferay 应用服务器上的,所以对于服务器进行一些优化当然是我们最先想到的。

之前我们也做了很多测试,因为liferay会有css-fast-load,和 js-fast-load,这些参数会吧若干个css文 件或者若干个js文件合并成单个大文件,这样可以显著的减少网络的IO开销次数,我们开发为了方便调试,当 然是需要让这些文件都不合并,这样我们可以方便的进行调试,但是在DEMO服务器,我们显然还是吧他们合并 为好,所以我们在portal-ext.properties上进行了如下的配置:

如图所示,就是把 theme,javascript这些fast load 从false变为true.

当然了,我们开发阶段使用的一般是ext-all- debug.js,我们为了提高性能,会使用ext-all.js来代替ext-all-debug.js。

时间: 2024-08-08 07:16:43

Liferay前端性能调优(2) Liferay服务器上开启优化参数的相关文章

Liferay前端性能调优(1) 测评工具YSlow

最近我们团队要问Liferay做前端页面调优,当然了,测评工具是最重要的,为了看具体的页面加载时间等 ,我们首选当然是Chrome浏览器的诊断工具,但是总感觉不专业,基于我已有的经验,我还是推荐了YSlow,它 会对于页面的各项指标进行打分,然后最终获得总分然后评级,一般级别有A,B,C,D,E,F6个级别. 如何安 装和测试YSlow: (1) 从Firefox的Add-on上下载 "YSlow" (2)重启Firefox检查是否YSlow 已经被正确的安装 (3)到我们要测试的页面

Liferay前端性能调优(6) 总结

我们现在做个总结: 事实上,为了有更好的用户体验我们从各个方面做了优化: 资源本身尺寸 裁剪: 对于css,js资源,我们用yui-compressor对其进行了压缩处理 对于image资源,我们用 了sprite工具吧多个小图片合并成大的单个图片 资源从服务器下载到客户端的速度开销减少: 我们对于服务器开启了Gzip Filter的过滤功能,这样所有的资源都是被压缩过的,从而当下载到浏览器中可 以大大减少下载时间. 资源的数量缩小: 这个我们主要是Liferay的服务器进行了一系列的参 数优化

Liferay前端性能调优(3) Gzip Filter

对于多数Http请求来说,如果我们能让他们以压缩文件的形式提供这些资源的话,也会极大的提高效率. 我们只要开启Gzip,然后就可以减少下载这些资源所占用的网络传输时间. 为了进行比较,我们先给个截 图,这是没有启用Gzip的情况: 从这里可以看出,在启用Gzip之前,下载ext-all-debug.js需要2.8MB这么大的文件,需要用时1.53秒. 然后我们就配置Gzip Filter,为此需要做2个步骤: (1)在$LIFERAY_HOME/portal- ext.properties文件中

Liferay前端性能调优(4) 打包artifact时候启用yui-compressor

上一章节我们介绍了,从浏览器向服务器获取资源时候,可以通过Gzip让浏览器拿到的是压缩的资源从而减少网络下载时间,那么我们能否从源头上考虑呢,就是我们从源头(资源本身)让资源尽可能的小. 办法当然是有的,一般资源有css,js,image,我们的思路是,对于css,js,我们用yui-compressor来对其进行压缩,对于image,我们将他们sprite成单个的大图从而减少网络请求次数. yui-compressor,相信很多人都不陌生,它可以专门来压缩css,js,一般会去除其中的注释,空

Liferay前端性能调优(5) sprite图片

当然了,对于图片文件,我们不可以用yui-compressor进行压缩,但是我们可以吧若干个小图片sprite成 一张大图片然后给出每个图片的坐标,从而减少网络IO的次数开销. 具体步骤是: (1)压缩所有的 图片文件成一个zip包 (2)上传到以下地址:http://spritegen.website-performance.org/ (3) 然后它就会产生一个报告然后告诉你css的改变并且创建sprite后的图片 这个sprite后的图片如下: 然后对应的坐标也改变了,如下: 然后我们就可以

通向架构师的道路(第三天)之apache性能调优

一.总结前一天的学习 在前两天的学习中我们知道.了解并掌握了Web Server结合App Server实现单向Https的这样的一个架构.这个架构是一个非常基础的J2ee工程上线布署时的一种架构.在前两天的教程中,还讲述了Http服务器.App Server的最基本安全配置(包括单向https的实现), 它只是避免了用户可以通过浏览器侵入我们的Web访问器或者能够通过Web浏览器来查询我们的Web目录结构及其目录内的文件与相关内容,这种入侵我们把它称为: Directory traversal

【原创】构建高性能ASP.NET站点 第五章—性能调优综述(中篇)

原文:[原创]构建高性能ASP.NET站点 第五章-性能调优综述(中篇) 构建高性能ASP.NET站点 第五章-性能调优综述(中篇) 前言:本篇主要讲述用一些简单的工具来分析一些与站点性能有关的数据,在上一篇文章中,我们讨论了一下性能调优的一般过程,本篇就开始介绍一些方法和工具,让大家快速的入门.      系列文章链接: 构建高性能ASP.NET站点 开篇 构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 构建高性能ASP.NET站点之二 优化HTTP请求(前端) 构建高性能ASP

这是一篇最通熟易懂的性能调优总结!

精彩早知道 作者概述 什么是性能调优?(what) 为什么需要性能调优?(why) 什么时候需要性能调优?(when) 什么地方需要性能调优?(where) 什么人来进行性能调优?(who) 怎么样进行性能调优?(How) 总结 硬件配置:CUP Xeon E5620 x 2 8核心, 内存 16G , 硬盘 RAID 10 操作系统: CentOS 6.4 x86_64(64位)  一.作者概述 在这篇博文中,我不想用一些抽象的概念去说性能调优的问题,只想用最通俗的语言尽量来准确的表达我的想法

性能调优概述,这是一篇最通俗易懂的性能调优总结

精彩早知道 作者概述 什么是性能调优?(what) 为什么需要性能调优?(why) 什么时候需要性能调优?(when) 什么地方需要性能调优?(where) 什么人来进行性能调优?(who) 怎么样进行性能调优?(How) 总结 硬件配置:CUP Xeon E5620 x 2 8核心, 内存 16G , 硬盘 RAID 10,操作系统: CentOS 6.4 x86_64(64位). 概述 在这篇博文中,我不想用一些抽象的概念去说性能调优的问题,只想用最通俗的语言尽量来准确的表达我的想法. 由于