站前端的用户体验,决定了用户是否想要继续使用网站以及网站的其他功能,网站的用户体验佳,可留住更多的用户。除此之外,前端优化得好,还可以为企业节约成本。那么我们应该如何对我们前端的页面进行性能优化呢?
前端性能优化可以分为三个方面:接口访问优化、静态资源优化和页面渲染速度优化。
1.1、减少http请求,合理设置 HTTP缓存
http协议是无状态的应用层协议,每次发送http请求时,都需要建立连接、通信、断开连接,在服务器端每个http都需要开启独立的线程去处理。所以尽量减少http请求,尽可能地提高访问性能。
减少http请求的方法:
1.2、减少cookie传输
cookie 存在于 http 头,在客户端与服务器之间交换,尽可能地控制 cookie 的大小,cookie越小,响应速度越快,减少 cookie 传输,响应速度更快。
1.3、使用CDN提供静态文件
使用 CDN 可以更快地在全球范围内获取到你的静态文件,加快网页加载。
1.4、启用 GZIP 压缩
http 协议上 GZIP 编码,是一种用来改进 web 应用程序的。开启 GZIP 后,服务器会把网页内容压缩后传输,一般能压缩到原大小40%,这样网页传输速度就更快了。GZIP 有两大好处:一是减少存储空间,二是通过网络传输文件时,可以减少传输时间。
1.5、分域存放资源
HTTP 客户端一般对同一个服务器的并发连接个数都是有限制的,通常最大并行连接为四了,剩下的会进入等待队列,等前边的执行完毕,等待的才会执行。所以利用多域名主机存放资源,增加并行连接量,缩短资源加载时间。
1.6、减少页面重定向
开启 https 可以有效防范攻击,保证用户始终访问到网站的加密连接,保护数据安全,同时省去 301/302 跳转的时间,大大提升网站的安全系数和用户体验。
如果在网站设置当用户访问域名的时候强制 https 进行 301 或者 302 跳转,但是这个过程中,用到 HTTP 因此容易发生劫持,受到第三方的攻击。所以尽可能使用https安全。
1.7、避免使用iframe
iframe 相当于本页面又嵌套了一个页面,消耗性能,还要加载嵌套页面的资源,所以更消耗时间。
1.8、借用浏览器缓存
ajax 请求到的数据,可以缓存到浏览器,下次使用的时候无需再次获取,直接取缓存数据就可以。这个会根据具体的项目来做,比如常用的角色类型就会缓存,获取到的普通数据为了保证实时性,不能使用缓存。
2.1、压缩 html、css、js 等文件
删除不必要的空格、注释和中行,减少文件大小,显著减少用户下载时间,加快网页加载速度。可以直接使用压缩工具,可以自动删除所有不必要内容。
2.2、在 js 之前引用 css
这是一个小细节,js 执行的时候会进入阻塞,如果放入 js 之后加载,会等待 js 执行完成之后才能加载 css,渲染页面,此时就会出现布局错乱。所以 css 文件需要非阻塞引入,以防DOM 花费更多时间才能渲染。
2.3、非阻塞 js
js 会阻止 html 文档的正常解析,当解析器到达 script 标记时,它会停止解析并执行脚本。所以我们经常把 script 引入的 js,放到 html 中最底下。如果需要让脚本位于页面顶部,建议添加非阻塞属性。经常使用 defer 和 async 来异步加载js文件。
<!-- 使用defer -->
<script defer src="foo.js" ></script>
<!-- 使用async -->
<script async src="foo.js"></script>
2.4、图片压缩
最常见的就是 css 雪碧,就是将很多很多的小图标放在一张图片上,就称为雪碧图。雪碧图最大优点就是可以减少http请求,除此也能压缩图片文件大小。使用的时候,通过设置 background-position ,移动图片的位置。除此之外,网站用到的大图,也需要在保证图片质量前提下优化到最小。
2.5、矢量图替代位图
矢量图(SVG)往往比图像小很多,缩放的时候不失真,这些图像还可以通过 css 进行动画和修改,比位图方便控制。可以的话,尽量用矢量图多点。
2.6、js代码相关优化
3.1、懒加载
素材类的网站,页面一屏展示很多图片,而且图片还不能失真,图片加载太多,网页加载慢得很,所以就引用懒加载,只加载可视区的图片,避免加载可以能不需要或不必要的图像。改善页面的响应时间。
3.2、避免响应式布局
响应式网站虽然能够兼容所有终端设备,但是会出现隐藏部分无用内容,浪费带宽,加载时间还长,页面的渲染时间也长。想更多了解响应式布局,请点击《前端响应式布局为什么是个坑?》。
3.3、设置大小,避免重绘
遇到 img 标签,会立马发送一个 http 请求,下载图片,页面继续向下渲染,等图片加载成功了,发现图片的宽高大小发生变化,影响后边排版,所以页面会重新再绘制一次这部分。所以尽可能设置图片的大小。
3.4、减少DOM元素
解析 html 内容,将标签转化为DOM节点,之后再解析其他文件,DOM元素越少,也就是标签越少,文件转化得越快,加载速度也就快了。
3.5、减少 Flash 的使用
flash 文件比较大,加载起来耗时。除此,flash 插件还需要运行才能运行,最主要有些浏览器flash插件马上要下线了,建议尽量不用 flash。
3.6、文件顺序
css文件放在最顶部,优先渲染。js放在最底部,避免阻塞。
让网页如何加载更快,有好多的细节,还是要好好提升自己的技能~~~~~~~~~
点个关注!更多分享内容。
年来,随着互联网的高速发展,网页中蕴藏的海量数据成为各行业竞争的关键。而在获取这些数据的过程中,一个重要的技术就是爬虫。结合JavaScript渲染技术,爬虫不仅能够更好地应对动态网页,还能为用户带来更加精准、丰富的信息。下面小编将为您详细介绍这一新兴技术。
一、爬虫与JavaScript渲染的概念
爬虫是一种自动化程序,可以模拟人类对网页进行访问,并从中提取所需信息。而JavaScript渲染则是指网页加载时,浏览器会执行其中的JavaScript代码,生成并显示页面内容。传统的爬虫技术只能抓取静态网页内容,无法获取通过JavaScript动态生成的信息。而结合爬虫和JavaScript渲染技术,则可以解决这一问题。
二、爬虫与JavaScript渲染技术的优势
1.动态网页抓取:传统爬虫只能抓取静态页面,无法获取动态生成的内容。而结合JavaScript渲染技术,爬虫可以模拟浏览器行为,获取完整的网页数据。
2.数据准确性:JavaScript渲染技术可以实时加载和更新数据,爬虫可以及时抓取最新的信息,保证数据的准确性。
3.用户体验优化:通过爬虫和JavaScript渲染技术,网页内容可以更加丰富、多样化,提升用户体验。
4.数据分析与挖掘:爬虫获取到的数据可以用于各种分析和挖掘工作,为企业决策提供参考。
三、爬虫与JavaScript渲染的应用案例
1.电商行业:通过爬虫和JavaScript渲染技术,企业可以实时抓取竞争对手的商品信息、价格变动等数据,从而制定更具竞争力的销售策略。
2.新闻媒体:通过爬虫和JavaScript渲染技术,新闻媒体可以快速抓取各类资讯,并实时更新到自己的平台上,提供给用户最新、全面的新闻内容。
3.社交媒体监测:通过爬虫和JavaScript渲染技术,企业可以实时监测社交媒体上与自身品牌相关的讨论和用户反馈,及时做出回应和调整。
4.数据分析与预测:通过爬虫和JavaScript渲染技术,可以获取大量的数据,进行数据分析和挖掘,为企业决策提供可靠的依据。
四、注意事项与发展趋势
1.合法合规:在使用爬虫技术时,需要遵守相关法律法规,尊重网站的使用规则,避免侵犯他人的权益。
2.技术更新迭代:随着互联网技术的不断发展,爬虫和JavaScript渲染技术也在不断更新迭代中。开发者需要及时了解新技术,并灵活应用于实际项目中。
总结:
爬虫与JavaScript渲染技术的结合为我们带来了更多可能性。无论是从数据获取、用户体验还是商业决策等方面,这一技术都具有重要意义。然而,在应用过程中,我们也要遵守相关规定,保护他人的权益。相信随着技术的不断发展,爬虫与JavaScript渲染将会在更多领域展现出其强大的潜力和价值。
面性能和用户体验的各个指标怎么来优化呢?open signal官方提供了2018年2月份统计的全世界4G网络覆盖率和通信速率的统计分布图如下,在目前移动互联网的浪潮下,我们要利用好用户终端设备的每个字节的流量。
当然页面性能和体验优化并不是一蹴而就的,需要不断的研究、跟踪,发现问题,解决问题。但是我们可以在一开始编写业务代码的时候就做的更好,做到极致。所以,关于优化实战我们主要分为两部分:加载渲染链路优化 和 编程代码优化。
从访问url到页面呈现,整个链路可以做优化的思路。
幸运的是,W3C推荐的Navigation Timing标准中所定义的核心的页面性能数据,它包含了从上个页面销毁到跳转到当前页面加载完成每个阶段所消耗的时间。在canIuse上查到的兼容性也很好:
利用这个接口可以很方便的帮助我们排查链路问题。在Navigation Timing标准中介绍到这个API主要包含两个接口:PerformanceTiming和PerformanceNavigation,这两个接口由浏览器进行实现和维护,当浏览器创建页面的时候就会把接口定义的相关数据挂载到window.performance.timing和window.performance.navigation这两个属性上。我们可以打开一个网页看一下:
我们把这两个图对比一下,就可以很容易的排查出页面的加载链路问题。
静态资源链路
打开页面的第一步是请求页面的html,这里面涉及TTFB这个综合指标。同时如果有必要我们也可以统计DNS时间和TCP时间。
DNS时间:主要是根据请求域名查询到对应主机IP的时间。这个和DNS服务器有关系,也可能和本地缓存有关,如果这个很慢,可以找服务商排查下问题。
TCP时间:tcp是承接http协议的下层协议。主要是路由到主机ip,并建立tcp链接的时间。这个时间反应了服务器到用户客户端之间链路是否通畅,网络是否通畅。
请求完HTML之后,就开始解析html代码,按照从上至下、自然顺序解析,解析内联CSS代码或者加载外链CSS脚本,解析内联Javascript脚本,或者加载外链Javascript脚本。由于浏览器是单线程的,这些CSS和Javascript脚本很可能就会造成页面卡顿。参考 浏览器线程理解与microtask与macrotask。
CDN是内容分发网络,主要用于缓存静态资源。CDN服务商一般会在全国各地部署服务,而且带宽很大,这样访问CDN的资源时就可以有较短的路由路径,而且带宽也比较大,访问比较快。
加载完JS和CSS之后,浏览器开始解析执行。Chrome的渲染流程是这样的:(可以参考 高性能CSS动画)
为了让浏览器更快的解析渲染,我们需要考虑这几点:
介绍一下code split的方案: react-loadable
// 未处理 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> ); // 使用react-loadable按需加载 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );
这个也可以在打包工具统一配置,不用每个模块都自己写。
只有浏览器尽快渲染出来,用户才能尽快的可以交互。
上面我们梳理了加载到解析渲染过程应该做的事情,那么如果你这些都做好了,发现网页表现依然不尽人意,那么你就要考虑做一下数据埋点。其实数据埋点在企业项目中也是必不可少的,和性能体验优化构成闭环。通过数据来发现页面性能和体验的问题,更有针对的进行解决。
事实上数据埋点分为三类:
工程埋点,统计工程上的数据信息,比如页面秒开率,dns时间等,也就是我们上节课总结的性能和体验数据指标。
资源缓存
这一节我们单独介绍缓存,是的,利用好缓存可以解决很多问题,包括页面加载和渲染的问题都能得到很好的优化。
常见的h5缓存方案有很多种,
通常,与页面加载性能相关的,有下面几种缓存,
(1)MemoryCache
MemoryCache,资源存放在内存中,一般资源响应回来就会放进去,页面关闭就会释放。内存存取性能可达磁盘缓存性能的100倍,但这还不是MemoryCache的最大优势,MemoryCache最大的优势是离排版渲染引擎非常近,可以直接被读取,甚至无需经过线程转换。在真实的页面访问过程中,获取资源的时间,磁盘IO仅仅是其中的一部分,更多的时间往往消耗在各种线程抛转。
(2)ClientCache
ClientCache,客户端缓存,比如,手淘里的ZCache(离线压缩包缓存),本质上属于磁盘缓存。这类Cache的优点是能以相对可控的方式让资源提前缓存在磁盘,但它也有一系列的成本。比如,它需要一套服务器与客户端协同的下发更新逻辑,服务器端需要管理下发,客户端需要提前解压缩。我们可能觉得提前解压并不是什么弱点,但如果有一千个离线包,这个问题就比较严重了,如果不提前解压,就无法保证首次访问性能,如果提前解压会让IO非常繁忙,可能会造成客户端打开时严重卡顿。
(3)HttpCache
HttpCache,是历史比较悠久的缓存,它利用标准的 Cache-Control 与服务器端进行协商,根据标准的规则去缓存或更新资源。它应用非常广泛,是非常有效果的一种磁盘缓存。它的缺点是完全由浏览器按标准规则控制,其它端的控制力度非常弱。比如,某些被HttpCache缓存的静态资源出问题了,通常只能是改页面,不再使用出问题的资源,而无法主动清除出问题的资源。参考http请求缓存头,HTTP协商缓存VS强缓存原理
(4)NetCache
网络相关的Cache,一般是指DNS解析结果的缓存,或预连接的缓存。DNS预解析和预连接是非常重要的,创建一个Https连接的成本非常大,通常需要600ms以上,也就是说,页面如果有关键资源需要全新建连接,秒开基本是不可能了。
(5)CDN
CDN一般是通过负载均衡设备根据用户IP地址,以及用户请求的URL,选择一台离用户比较近,缓存了用户所需的资源,有较好的服务能力的服务器,让用户从该服务器去请求内容。它能让各个用户的缓存共享,缩短用户获取资源的路径,来提升整体的性能。
当然,还有其它非常多类型的Cache,比如,
JS相关,V8 Bytecode Cache,字节码缓存,能极大的减少JS解析耗时,甚至可以提升3-6倍的性能。参考:前端优化系列 – JS解析性能分析
渲染相关,图片解码数据缓存,是一块非常大的内存缓存,约100M,能保证页面滚动过程可以实时获取到图片解码数据,让滚动非常流畅。
页面相关,页面缓存,Safari的PageCache,Firefox的Back-Forward Cache,UC浏览器的WebViewCache,都是一样性质的缓存,将整个执行过的页面保存在内存。标准的页面缓存,进入的条件非常苛刻,大部分情况都无法进入,而且在前进后退的场景才允许使用。
前面介绍了很多理论层面的内容,我们接下来介绍一些实践优化案例。
(1)预置资源进MemoryCache
在页面的onPageFinished的回调里面去检查是否有资源可以预置,如果有,就通过相关接口把资源设置进内核的MemoryCache。我们并不知道用户即将会访问什么页面,如果把大量的资源都预置进内存,而用户却没有使用,那就会造成浪费。另外,资源在内核内存,仅仅是加快了资源的加载速度,页面的首屏包含非常多非常复杂的流程,某个流程的加速并不一定能带来整体性能的提升,比如,非关键的JS放在内存,可能就会先于一些关键JS被提前执行,反而让首屏更慢。所以,选择放那些资源进内存也是非常有讲究的,能预置的资源一般是 非常关键的更新频率较低的少量公共基础资源。
对于一般公司来说,没有能力自己定制webview渲染的内核,可以看下系统默认webview内核有没有这样的接口来实现操作MemoryCache预置数据的能力。
(2)预加载资源进HttpCache
预置资源进内存,对加载性能的提升是最明显的,但成本也是最大的,会占用用户手机宝贵的内存资源。另外一种预置资源的思路是,提前通过内核去预加载一些资源,资源加载回来之后就直接保存在标准的HttpCache。资源在HttpCache和在客户端缓存(比如,手淘ZCache)的性能差别不大。但如果资源不能放进ZCache,通过这种方式提前放到HttpCache,也是一种优化思路。
(3)使用WebViewCache极速切换页面
H5页面的加载流程是非常重的一套流程,即使同一个页面多次重复访问,也需要走比较完整的流程,耗时极长,这与用户的期望是不符的,通常用户期望访问过的页面就能快速展现出来。在一些特定的场景,H5也是可以做到极速展现的,比如,前进后退。其它的场景,比如页内几个TAB切换,是否也可以用上这类缓存呢?也是可以的。原理上也是比较简单的,在页面首次访问时,会将排版渲染好的页面放进WebViewCache里,WebViewCache是存储完整页面的一块内存。
用户再次访问该页面时,会将WebViewCache内存中的完整页面读取出来,直接绘制展现,而无需再进行加载解析排版渲染等流程,从而达到极速打开的效果。
除了内核提供WebViewCache基础技术之外,前端也需要与内核进行一定的交互,比如,通过JSAPI查询当前页面是否在WebViewCache,如果在则返回它在WebViewCache列表的位置,然后前端就可以使用JSAPI去跳转到相应位置的页面,内核就把页面从内存读取和展现出来。使用此类技术,页面一般能在500ms左右完全展现出来,具有非常好的用户体验。
当然这个也是需要浏览器内核提供这种能力,如果公司有自己的内核开发团队,可以做到定制。
(4)前端使用LocalStorage缓存HTML文档
当前前端渲染非常流行,页面大部分的逻辑都会由前端JS去执行,JS执行完才会生成完整的HTML文档,而JS执行的成本是非常大的,JS执行时间可能占据首屏时间的50%,有些甚至能达到80%。那么,我们有没有可能将JS执行生成的完整HTML文档缓存起来呢,下次访问时直接使用已缓存的页面,而无需重复执行JS?这也是可以的原理上也不复杂,首次访问页面时,JS执行完之后会生成完整的HTML文档,我们将HTML文档缓存到LocalStorage里面。
在后续的访问中,我们优先从LocalStorage里面读取HTML文档,解析排版渲染页面,而无需JS执行去生成页面,让页面展现速度得到极大的提升。
这种方案的关键在于前端能够实现一套DOM-Diff更新的机制,在从LocalStorage读取HTML页面的同时,前端还会发起请求去更新HTML文档,在新的HTML文档回来之后,会和旧的文档进行Diff,针对Diff来进行局部更新,这样能保证页面得到及时的更新。
(5) service worker
参考使用 Service Workers提升体验,这里附带介绍下这个方案,目前service worker 只有在android的webview中可用,ios还不支持。我们通过先注册一个serviceworker服务,指定哪些资源和数据需要存储,然后下次请求页面会自动激活这个service worker,页面请求时会先从service worker中返回缓存的数据。当然service worker中需要自己处理版本和维护数据更新。
*请认真填写需求信息,我们会在24小时内与您取得联系。