Welcome to山东宜军网络科技有限公司

Customer Hot Line

18854179173

current location: Home> 漳州区百度推广>漳州网站优化检

漳州网站优化检测

author:山东宜军网络科技有限公司

【Font size: big medium smail

time:2020-01-09 17:52:25

本文由山东宜军网络科技有限公司提供,重点介绍了网站优化检测相关内容。山东宜军网络科技有限公司专业提供虹口区百度推广,三元区网站建设,兴国县网站优化等多项产品服务。公司客户好评率高,行业口碑好,是在本行业中您的不二选择

网站优化检测著名大师火云邪神曾经说过,天下武功,无坚不摧,唯快不破。

网页性能优化是一个经久不衰的梗,所有的前端工程师都会绞尽脑汁让网页更快一点。

说到性能优化,你肯定会想到狗书,以及雅虎军规。

但是,高性能网站建设指南是10年前的书了,雅虎军规是12年前的Best Practice了。

在2018年的今天,我们需要自动化的,可量化的前端性能评估系统,见 Front-End Performance Checklist 2018 。

还好,Google给我们带来了 LightHouse 。

顾名思义,Lighthouse 为海上的灯塔,为海上的船只指引方向。Lighthouse 帮助我们了解我们的网页在哪里做得不好,并指引我们优化。

在Google的官方文档简介中说,Lighthouse 是一个开源的自动化工具,用于改进网络应用的质量。

Chrome 发行版中已经集成了 Lighthouse。位置是在 Chrome 中的 开发人员工具中的 Audit 页面。 我们可以直接使用 Chrome 进行简单的测试。

网站优化分为四种,分别是:

1. Progerssive Web App(PWA)

2. Performance(性能)

3. Best Practice(最佳实践)

4. Accessibility(可用性)

我们以苹果官网为例,直接 Run Audit 后可以看到相关的性能报告。

可以看到,对于四个大种类,都会有一个评分。

在 PWA 方面,苹果官网只拿了45分,是因为7个审计用例没通过,具体原因也在下面有详细阐述。

没通过的审计用例有:

1. 没注册 Service Worker

2. 没做离线支持

3. 3G 网络下没做加载优化

4. 没做 manifest

...等等等等

对于这些没通过的审计用例,Lighthouse 都会有对应提示,告诉你为什么要做这个审计,为什么这个审计没通过。以及 Learn More 对优化方式进行指导,非常贴心。

PWA 是一个当前观望性质比较大的领域。我们再看看性能方面。

首先,LightHouse 很直观的给了我们三个重要的衡量:

1. First Meaningful Paint(FMP:首次有意义的时间点)

2. First Interactive(网页初次可交互时间点)

3. Consistently Interactive(持续可交互时间点)

由于现在图片管理一般由产品或者是运维负责,图片上传源如果不经过统一的压缩,就很容易出现上传图片过大的问题。解决方法可以是把控图片上传源,以及客户端根据网络以及显示屏幕大小请求不同尺寸的图片。

下面还有最佳实践以及可用性,都很相似,不再浪费文字了哈。

这不仅仅是一篇介绍 Chrome Audit 功能的文章。

坐和放宽,接下来我们深入一点。

Lighthouse 真正好用的地方在于提供了开源的自动化优化审计,这意味着我们可以进行一系列的个性化定制,打造出我们适用的审计工具(附: Lighthouse Github )。

我们可以通过 npm 安装一个全局的 lighthouse

npm install -g lighthouse

或者通过 package.json 引入这个包,在项目中运行。

譬如我在 lightcrawler 的基础上,写了一个可以根据网站目录爬取全站网页并进行分析的爬虫。

hating/lightcrawler网站优化检测

你可以在该项目下运行并爬取你想要分析的网站。

譬如:

node ./cli.js -u

值得注意的是,最终的分析报告不是我们最终想要的,我们在自定义性能分析时,其实对分析的源数据更感兴趣。

我们可以在运行时加入参数:

--save-assets

这样对于所有分析报告,都会保留分析时的原始数据。

拿到原始数据就非常有趣了。

我们以 iPhone X 的页面为例。

跑完脚本后,在对应文件目录下,可以看到对应文件。

├── iphone-x

│ ├── _2018-2-8_17:54:02-0.devtoolslog.json (调试记录)

│ ├── _2018-2-8_17:54:02-0.screenshots.html (截屏)

│ ├── _2018-2-8_17:54:02-0.screenshots.json (截屏)网站优化检测

│ ├── _2018-2-8_17:54:02-0.trace.json

│ └── _2018-2-8_17:54:02.html (最终报告)

其中 devtoolslog 记录了浏览器从按下回车键到返回数据的所有活动,对于我们自定义报告非常的有帮助。

初看 devtoolslog.json,看起来似乎是一堆 method + params 的 Object 组成的数组,这些究竟是什么意思呢?

{

"method": "Page.frameStartedLoading",

"params": {

"frameId": "(36240A6E3A07800F742C83F687C2250C)"

}

}我们需要从 Lighthouse 源代码上研究。

在 Lighthouse 的 Github 项目上,简单介绍了一下该项目架构。

对于 devtoolslog 的具体实现可以看

lighthouse/lighthouse-core/gather/connnection.js下的 handleRawMessage() 函数。

由此我们也可以知道,相关的Method究竟是什么意思。

譬如:

Page.frameStartedLoading这个方法,对应的文档在:

根据这些 devtoolslog ,我们可以知道所有所有数据在哪些时间在一个什么样的状态。

事实上,你可以根据这个 devtoolslog 来创建一个和 Performance 一模一样的流水图。如果你听说过 WebPageTest ,你就会恍然大悟,噢,原来他们是这么干的,如果你想了解更多,可以见这一个 issue。

因为记录了所有资源请求的状态,所以这个 devtoolslogs 非常有用。

举个栗子,我想要获取一个网页究竟请求了哪些图片的信息。

你可能会说我用 request 拿到服务器返回数据再用 cheerio,或者是正则黑魔法提取出来就可以了。

事实上并没有那么简单,加入了 lazy-load 的资源是要 JavaScript 执行后才能拿到 src 的,有人也喜欢把图片写到 background-image 里,传统的字符串解析在此时就很无能为力了。

所以我们可以用 devtoolslog,一举消灭所有困难。

再举个栗子,我想要拿到 iPhone X 页面的这个资源:

在 devtoolslogs 很容易就可以找到对应的 requestId:

然后根据这个 requestId ,可以找到对应 request 的整个生命周期:

大概流程是:

1. Network.requestWillBeSent

2. Network.responseReceived

3. Network.dataReceived

4. Network.DataReceived

5. Network.loadingFinished

是吧,非常好用。

最后分享一下围绕 Lighthouse 的相关资源吧:

Calibre - Get the web performance insights you need to improve customer experience

这是一个Lighthouse持续服务,大概就是用人家的服务器给你定时跑Lighthouse,然后给你一份持续的报告。有免费试用。

Greta.io - Upgrading the Internet

用不同地区的Lighthouse给你跑Lighthouse。

还感兴趣的话可以去lighthouse Github的Readme,会有收获的。

感谢你阅读我的文章,不介意的话点个赞吧 ?