trinea.cn性能优化

简介:

1、测试工具
主要使用百度统计的网站速度检测工具和google的pagespeed,网站各地访问速度测试使用webkaka。

调优前,百度检测结果为:

可以看出网页所有内容加载需要20多秒!!_!!

PS:需要说明下,因为这次的优化大都属于前端优化,不涉及后台逻辑优化,对于后台逻辑优化测试工具从简单的apache ab,到高级的jmeter和昂贵的loadrunner,本文不做叙述。

2、调优内容及方式
根据测试工具的优化建议进行优化,主要调优内容包括:合并Js、合并Css、使用Css Sprite,启用Gzip压缩,其他元素压缩,使用浏览器缓存。

调优方式包括
(1) 安装WP Super Cache插件 功能强大,主要用于生成html文件后续访问直接通过apache访问而不需要通过php脚本处理
(2) 安装Better WordPress Minify插件 用于css和js压缩
(3) 修改.htaccess文件,.htaccess文件是Apache服务器中的一个配置文件,它负责相关目录下的网页配置。通过htaccess文件,可以帮我们实现:配置网页expires、网页301重定向、自定义404错误页面、改变文件扩展名、允许/阻止特定的用户或者目录的访问、禁止目录列表、配置默认文档等功能。内容为:

htaccess文件内容

(4) 去除不必要的import

3、调优结果

调优后,百度检测结果为,看到网页所有内容加载完成只需要4秒,访问速度有原来的5倍左右:


google pagespeed结果为:

网站空间在美国洛杉矶机房,调优后
全球访问的平均下载时间为1.256s,略高于月光博客,远超coolshell.cn
全国访问的平均下载时间为1.545s,与月光博客访问速度还有一定差距,跟酷壳差不多持平

目录
相关文章
|
1天前
|
存储 缓存 JavaScript
性能优化:通用快照方案
本文我们将探讨快照技术如何增强页面性能和用户体验,如何在业务中集成快照方案,以及我们的通用快照解决方案的技术细节。
|
1天前
|
缓存 NoSQL Redis
接口性能优化的小技巧
接口性能优化的小技巧
|
4天前
|
SQL 缓存 数据库
Django ORM的性能优化:高效处理大量数据
【4月更文挑战第15天】本文介绍了优化Django ORM性能的六大技巧:1) 使用批量操作如bulk_create和bulk_update;2) 利用prefetch_related和select_related减少查询次数;3) 为常用字段添加索引;4) 优化数据库查询,避免循环查询;5) 使用缓存提升频繁查询性能;6) 在必要时使用原生SQL。这些策略能帮助处理大量数据时提升Django ORM的效率。
|
4月前
|
人工智能 安全 索引
.NET8 极致性能优化 CHRL(CORINFO_HELP_RNGCHKFAIL)
.NET8 在 .NET7 的基础上进行了进一步的优化,比如 CHRL (全称:CORINFO_HELP_RNGCHKFAIL)优化技术,它是边界检查,在 .NET7 里面它已经进行了部分优化,但是 .NET8 里面它继续优化,类似人工智能,.NET8 能意识到某些性能问题,从而进行优化。
94 0
|
8月前
|
缓存 前端开发 JavaScript
前端如何进行性能优化的方法(详细版本)
每当有人访问您网站上的页面时,浏览器都必须请求大量文件。这些HTTP请求直接影响网页的加载速度。通常,更少的HTTP请求意味着网站加载速度更快。 现在,网站的加载速度是搜索引擎排名的重要因素。平均而言,媒体页面加载速度为谷歌的10个结果只是1.65秒。
123 0
|
9月前
|
存储 缓存 NoSQL
性能优化方案及思考
周末闲暇在家,朋友让我帮忙优化一个接口,这个接口之前每次加载都需要40s左右,经过优化将性能提了10倍左右;又加了缓存直接接口响应目前为300ms左右,于是将自己的优化思路整理总结一下
|
9月前
|
消息中间件 监控 固态存储
榨干服务器:一次惨无人道的性能优化
做过2B类系统的同学都知道,2B系统最恶心的操作就是什么都喜欢批量,这不,我最近就遇到了一个恶心的需求——50个用户同时每人导入1万条单据,每个单据七八十个字段,请给我优化。
|
10月前
|
监控 网络协议 安全
聊聊服务器性能优化~(建议收藏)
聊聊服务器性能优化~(建议收藏)
266 0
|
10月前
|
SQL 缓存 搜索推荐
第⼋章 查询性能优化
第⼋章 查询性能优化
|
缓存 安全 Java
Go RWMutex:高并发读多写少场景下的性能优化利器
RWMutex 是 Go 中的一种读写锁实现,它通过读锁允许多个 goroutine 同时执行读操作,当有写操作请求时,必须等待所有读操作执行结束后才能执行写操作。 RWMutex 的设计采用了 Write-preferring 方案,即如果有写操作在等待执行,新来的读操作将会被阻塞,以避免写操作的饥饿问题。 根据 RWMutex 的特性,它适用于 读多写少的高并发场景,可以实现并发安全的读操作,从而减少在锁竞争中的等待时间。 虽然它能够给程序带来了性能的提升,然而,如果使用不当,就可能会导致 panic 或死锁等问题。因此,在使用 RWMutex 时需要特别小心,并避免错误的用法。
20201 0
Go RWMutex:高并发读多写少场景下的性能优化利器