web前端

深入理解前端性能监控

页面的性能问题是前端开发中一个重要环节,但一直以来我们没有比较好的手段,来检测页面的性能。直到W3C性能小组引入的新的API window.performance,目前IE9以上的浏览器都支持。它是一个浏览器中用于记录页面加载和解析过程中关键时间点的对象。放置在global环境下,通过JavaScript可以访问到它。

使用性能API

你可以通过以下方法来探测和兼容performance:

var performance = window.performance || 
    window.msPerformance || 
    window.webkitPerformance;
if (performance) {
    // 你的代码
}
复制代码

先来了解一下performance的结构

performance.memory是显示此刻内存占用情况,它是一个动态值,其中: usedJSHeapSize表示:JS 对象(包括V8引擎内部对象)占用的内存数 totalJSHeapSize表示:可使用的内存 jsHeapSizeLimit表示:内存大小限制 通常,usedJSHeapSize不能大于totalJSHeapSize,如果大于,有可能出现了内存泄漏。

performance.navigation显示页面的来源信息,其中:

        

浏览器原生的图片懒加载

在这篇文章中,我们将看看为网络loading带来原生<img><iframe>懒惰加载的新属性。对于好奇的人来说,这里有一个实际的预览:

<img src="celebration.jpg" loading="lazy" alt="..." />
<iframe src="video-player.html" loading="lazy"></iframe>

我们希望能够为loadingChic 75提供支持,并正在深入研究我们即将发布的功能。在那之前,让我们深入了解它的loading工作原理。…

浏览器缓存看这一篇就够了

浏览器缓存作为性能优化的重要一环,对于前端而言,重要性不言而喻。以前总是一知半解的,所以这次好好整理总结了一下。

1、缓存机制

首先我们来总体感知一下它的匹配流程,如下:

  1. 浏览器发送请求前,根据请求头的expires和cache-control判断是否命中(包括是否过期)强缓存策略,如果命中,直接从缓存获取资源,并不会发送请求。如果没有命中,则进入下一步。
  2. 没有命中强缓存规则,浏览器会发送请求,根据请求头的last-modified和etag判断是否命中协商缓存,如果命中,直接从缓存获取资源。如果没有命中,则进入下一步。
  3. 如果前两步都没有命中,则直接从服务端获取资源。

2、强缓存

强缓存:不会向服务器发送请求,直接从缓存中读取资源。

2.1 强缓存原理

强制缓存就是向浏览器缓存查找该请求结果,并根据该结果的缓存规则来决定是否使用该缓存结果的过程,强制缓存的情况主要有三种(暂不分析协商缓存过程),如下:

  • 第一次请求,不存在缓存结果和缓存标识,直接向服务器发送请求

  • 存在缓存标识和缓存结果,但是已经失效,强制缓存是啊比,则使用协商缓存(暂不分析)

  • 存在该缓存结果和缓存标识,且该结果尚未失效,强制缓存生效,直接返回该结果

那么强制缓存的缓存规则是什么?
当浏览器向服务器发起请求时,服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器,控制强制缓存的字段分别是ExpiresCache-Control,其中Cache-Control优先级比Expires高。

2.1.1、 Expires

缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点。也就是说,Expires=max-age + 请求时间,需要和Last-modified结合使用。Expires是Web服务器响应消息头字段,在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。

Expires 是 HTTP/1 的产物,受限于本地时间,如果修改了本地时间,可能会造成缓存失效。

2.1.2、

深入了解浏览器存储–从cookie到WebStorage、IndexedDB

前言

随着移动网络的发展与演化,我们手机上现在除了有原生 App,还能跑“WebApp”——它即开即用,用完即走。一个优秀的 WebApp 甚至可以拥有和原生 App 媲美的功能和体验。WebApp 优异的性能表现,有一部分原因要归功于浏览器存储技术的提升。cookie存储数据的功能已经很难满足开发所需,逐渐被WebStorage、IndexedDB所取代,本文将介绍这几种存储方式的差异和优缺点。

 一、Cookie

1.Cookie的来源

Cookie 的本职工作并非本地存储,而是“维持状态”。 因为HTTP协议是无状态的,HTTP协议自身不对请求和响应之间的通信状态进行保存,通俗来说,服务器不知道用户上一次做了什么,这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中,用户浏览了几个页面,买了一盒饼干和两瓶饮料。最后结帐时,由于HTTP的无状态性,不通过额外的手段,服务器并不知道用户到底买了什么,于是就诞生了Cookie。它就是用来绕开HTTP的无状态性的“额外手段”之一。服务器可以设置或读取Cookies中包含信息,借此维护用户跟服务器会话中的状态。

我们可以把Cookie 理解为一个存储在浏览器里的一个小小的文本文件,它附着在 HTTP 请求上,在浏览器和服务器之间“飞来飞去”。它可以携带用户信息,当服务器检查 Cookie 的时候,便可以获取到客户端的状态。

在刚才的购物场景中,当用户选购了第一项商品,服务器在向用户发送网页的同时,还发送了一段Cookie,记录着那项商品的信息。当用户访问另一个页面,浏览器会把Cookie发送给服务器,于是服务器知道他之前选购了什么。用户继续选购饮料,服务器就在原来那段Cookie里追加新的商品信息。结帐时,服务器读取发送来的Cookie就行了。

2.什么是Cookie及应用场景

Cookie指某些网站为了辨别用户身份而储存在用户本地终端上的数据(通常经过加密)。 cookie是服务端生成,客户端进行维护和存储。通过cookie,可以让服务器知道请求是来源哪个客户端,就可以进行客户端状态的维护,比如登陆后刷新,请求头就会携带登陆时response header中的set-cookie,Web服务器接到请求时也能读出cookie的值,根据cookie值的内容就可以判断和恢复一些用户的信息状态。

如上图所示,Cookie 以键值对的形式存在

典型的应用场景有:

  • 记住密码,下次自动登录。
  • 购物车功能。
  • 记录用户浏览数据,进行商品(广告)推荐。

3.Cookie的原理及生成方式

Cookie的原理

第一次访问网站的时候,浏览器发出请求,服务器响应请求后,会在响应头里面添加一个Set-Cookie选项,将cookie放入到响应请求中,在浏览器第二次发请求的时候,会通过Cookie请求头部将Cookie信息发送给服务器,服务端会辨别用户身份,另外,Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

Cookie的生成方式主要有两种:

            

H5解决m3u8视频直播流问题

作者:蒲小花
链接:https://www.zhihu.com/question/21087379/answer/252216119
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

最近接触了这一块,简单说下吧。

m3u8 是一种基于 HTTP Live Streaming 文件视频格式,它主要是存放整个视频的基本信息和分片(Segment)组成。目前 由 Apple.inc 率先提出的 HLS 协议在 Mac 的 Safari 上原生支持,你可以直接通过

video.src = 'xxx.m3u8'

来实现。

如果你希望兼容所有的浏览器的话, 你需要知道 Chrome 和 Firefox 支持的 Media Source Extensions( 非常不理想,在IE和国内具备兼容模式的极速浏览器下) 的情况:

目前 Youtube 和 Netflix 等主流视频网站,即使

        

讲讲PWA

一、背景

文章2017 前端大事件和趋势回顾,2018 何去何从?中提到了2017年前端值得关注的十大事件,其中就提到了PWA。

大家都知道Native app体验确实很好,下载到手机上之后入口也方便。它也有一些缺点:

  • 开发成本高(ios和安卓)
  • 软件上线需要审核
  • 版本更新需要将新版本上传到不同的应用商店
  • 想使用一个app就必须去下载才能使用,即使是偶尔需要使用一下下
                    

简单了解HTML5中的Web Notification桌面通知

一、传统的通知实现

通知可以说是web中比较常见且重要的功能,私信、在线提问、或者一些在线即时通讯工具我们总是希望第一时间知道对方有了新的反馈,这个时候,就需要页面给予即使的通知。

在以前,我们的通知实现主要是通过闪烁页面的标题内容来实现,实现原理其实很简单,就是定时器不断修改document.title的值。…

    

JS工具库封装:Video转换成Canvas

在PC端,IE9+浏览器对原生视频的支持还是很不错的,然而一到了移动端就会各种兼容性的坑爹问题。

在移动端,各大浏览器厂商对视频会植入许多他们自定义的交互方式(如默认全屏播放、视频不能初始化播放、窗口置顶等等),更坑爹的是这些被植入的交互还无法去掉。移动端的视频行内自动播放看起来确实很棘手。

目前主流有两种方法处理移动端的视频播放问题:

一种是改设计和说服需求方,即使视频不能自动播放或者置顶也不影响页面展示的主要体验;

另一种便是使用canvas来替代video。…