fetch事件

在页面发起http请求时,service
worker可以通过fetch事件拦截请求,并且给出自己的响应。
w3c提供了一个新的fetch
api,用于取代XMLHttpRequest,与XMLHttpRequest最大不同有两点:

1.
fetch()方法返回的是Promise对象,通过then方法进行连续调用,减少嵌套。ES6的Promise在成为标准之后,会越来越方便开发人员。

2. 提供了Request、Response对象,如果做过后端开发,对Request、Response应该比较熟悉。前端要发起请求可以通过url发起,也可以使用Request对象发起,而且Request可以复用。但是Response用在哪里呢?在service
worker出现之前,前端确实不会自己给自己发消息,但是有了service
worker,就可以在拦截请求之后根据需要发回自己的响应,对页面而言,这个普通的请求结果并没有区别,这是Response的一处应用。

下面是在中,作者利用fetch
api通过fliker的公开api获取图片的例子,注释中详细解释了每一步的作用:

JavaScript

/* 由于是get请求,直接把参数作为query string传递了 */ var URL =
”;
function fetchDemo() { // fetch(url,
option)支持两个参数,option中可以设置header、body、method信息
fetch(URL).then(function(response) { // 通过promise
对象获得相应内容,并且将响应内容按照json格式转成对象,json()方法调用之后返回的依然是promise对象
// 也可以把内容转化成arraybuffer、blob对象 return response.json();
}).then(function(json) { // 渲染页面 insertPhotos(json); }); }
fetchDemo();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* 由于是get请求,直接把参数作为query string传递了 */
var URL = ‘https://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=your_api_key&format=json&nojsoncallback=1&tags=penguins’;
 
function fetchDemo() {
  // fetch(url, option)支持两个参数,option中可以设置header、body、method信息
  fetch(URL).then(function(response) {
    // 通过promise 对象获得相应内容,并且将响应内容按照json格式转成对象,json()方法调用之后返回的依然是promise对象
    // 也可以把内容转化成arraybuffer、blob对象
    return response.json();
  }).then(function(json) {
    // 渲染页面
    insertPhotos(json);
  });
}
 
fetchDemo();

fetch
api与XMLHttpRequest相比,更加简洁,并且提供的功能更全面,资源获取方式比ajax更优雅。兼容性方面:chrome
42开始支持,对于旧浏览器,可以通过官方维护的polyfill支持。

戏说HTML5

2015/12/23 · HTML5 ·
HTML5

原文出处:
木的树的博客   

如果有非技术人员问你,HTML5是什么,你会怎么回答?

 

新的HTML规范。。。

给浏览器提供了牛逼能力,干以前不能干的事。。。(确切地说应该是给浏览器规定了许多新的接口标准,要求浏览器实现牛逼的功能。。。
这里感谢红枫一叶)

给浏览器暴露了许多新的接口。。。

加了很多新的效果。。。

问的人其实并不明白他想问的真正问题,回答的人貌似明白,但又好像少了点什么。牛逼的能力、新的接口、炫酷的效果,首先回答的人自己就是晕晕乎乎。什么是HTML、什么是CSS、什么是DOM、什么是JavaScript,大部分的前端开发每天都在用这些,但很少会有人去思考一下他们之间的关系。

首先,HTML的全称是超文本标记语言,是一种标记形式的计算机语言。将这种标记语言给专门的解析器,就能够解析出一定的界面效果。浏览器就是专门解析这种标记语言的解析器。我们说他最终的效果是在屏幕上展示出特定的界面,那么浏览器肯定要把一个个的标记转换成内部的一种数据结构,这种数据结构便是DOM元素。比如,一个<a>标签在浏览器内部的世界中就是一个HTMLAnchorElement类型的一个实例。

一个HTML文件就好比用超文本标记语言写的一篇文章,文章通常是有结构的,在浏览器眼里它就是DOM。DOM描述了一系列层次化的节点树。(但这时候的DOM还是存在于浏览器内部是C++语言编写的)

 

随着历史的发展,当人们不在满足简单的显示文本,对于某些文本需要特殊强调或者给添加特殊格式的需求,慢慢的冒了出来。面对人们需要控制显示效果的需求,最先想到的也最简单的方式就是加标记。加一些样式控制的标记。这时候就出现了像<font>、<center>这种样式控制的标记。但是这样一来,所有的标记就会分为两大类:一种是说我是什么,一种是说我怎么显示。这还不是大问题,标记简单,但是浏览器要解析标记可就不那么简单了。想一想,这样干的话DOM也就要分成两大类,一类属于描述元素的DOM节点,一类属于描述显示效果的DOM节点。一个DOM节点可能代表一个元素,也可能是代表一种显示效果。怎么看都觉得别扭呀。

最后人们决定废弃样式标签,给元素标签添加一个style特性,style特性控制元素的样式(最初的样式声明语法肯定很简单)。原来的样式标签的特性,现在变成了样式特性的语法,样式标记变成了样式特性。这样逻辑上就清晰多了。那么问题来了:

  • 一篇文章如果修辞过多,必然会引起读者的反感。如果把元素和显示效果都放在一个文件中,必然不利于阅读。
  • 如果有10个元素都需要一个效果,是不是要把一个style重复写十遍呢
  • 父元素的设置效果对子元素有没有影响,让不让拼爹
  • 。。。。。。。。。

类似的问题肯定有很多,所以出来了CSS,层叠样式表,带来了css规则、css选择器、css声明、css属性等,这样以来就解决了以上痛点。标记语言这层解决了,但是浏览器就不能干坐着玩耍了,必然得提供支持。所以浏览器来解析一个静态html文件时,遍历整个html文档生成DOM树,当所有样式资源加载完毕后,浏览器开始构建呈现树。呈现树就是根据一系列css声明,经历了层叠之后,来确定一个个个DOM元素应该怎么绘制。这时候其实页面上还没有显示任何界面,渲染树也是浏览器内存里面的一种数据结构。渲染树完成之后,开始进行布局,这就好比已经知道一个矩形的宽高,现在要在画布量一量该画在哪,具体占多大地方。这个过程完了之后就是绘制的过程,然后我们便有了我们看到的显示界面了。

给标记加点效果的问题解决了,历史的车轮又开始前进了。慢慢的人们不再满足简单的显示效果,人们希望来点交互。那个时候写HTML的大部分并不懂软件开发,开玩笑嘛,我一写活动页的你让我用C++?C++干这事的确是高射炮打蚊子——大材小用。那正规军不屑干的事就交给游击队吧,这时候网景公司开发出了JavaScript语言,那时候的JavaScript根本没有现在这么火,一土鳖脚本语言,哪像现在这么牛逼哄哄统一宇宙。

JavaScript本是运行在浏览器的语言,HTML文本是静态的,不可能让JavaScript修改静态文件,但可以跟浏览器内部打交道。可是这个时候的DOM并不是今天的DOM,他们是C++对象,要么把JavaScript转换成C++指令操作这些C++对象,要么把这些C++对象包装成JavaScript原生对象。历史选择了后者,这时候也就标志着现代DOM的正式诞生。不过历史有时候会出现倒退,历史上总会出现几个奇葩,比如IE,IE奇葩他全家,包括Edge!

马克思是个江湖骗子,但恩格斯是个好同志。自然辩证法与历史唯物主义是好东西。从历史的角度我们可以看到。CSS、DOM、JavaScript的出现于发展最终的源头都在HTML,超文本标记语言。人们对web的需求最终都汇集在HTML上。所以只要历史产生新的需求,最终的变化都首先发生在HTML规范上。

当交互性不能在满足人们需求时,web迎来了新的需求:webapp。要迎合新的需求,首先要改变的就是HTML规范,这个时候已有的HTML4.0,已经无法满足人们日益增长的需求,所以HTML5迎着历史的需求,经过八年的艰苦努力,终于在2014年正式定稿!HTML5肯定是要加入新标签,然对于传统HTML而言,HTML5算是一个叛逆。所有之前的版本对于JavaScript接口的描述都不过三言两语,主要篇幅都用于定义标记,与JavaScript相关内容一概交由DOM规范去定义。而HTML5规范,则围绕着如何使用新增标记定义了大量JavaScript
API(所以其中有一些API是与DOM重叠,定义了浏览器应该支持的DOM扩展,由此可以看到HTML5也必定不是HTML的最终版)。

 

后记——
本文只是一个旁观者以线性的方式来翻阅HTML的发展史,但历史更像是晴空上突然的晴天霹雳,一声过后,有人哀嚎遍野,有人高歌入云。以此纪念曾红极一时的Silverlight、Flex,以此纪念广大一线开发者活到老学到老的不懈精神、曾经耗费的精力、曾经逝去的青春。

1 赞 1 收藏
评论

澳门微尼斯人手机版 1

资源

这里是丰富的有用资源,让你深入了解网站性能。

  • 深入谷歌PageSpeed
  • SpeedCurve
  • WebPagetest
  • 我的网站耗费的流量有多少?
  • 网页设计师和前端开发人员需要关注的前端性能
  • 如何让RWD网站的速度飙起来
  • 提升Smashing
    Magazine的性能:案例学习
  • 网站更庞大并不意味着更多的等待时间
  • 优化性能
  • RWD 膨胀 第一部分 和
    第二部分
  • 谷歌PageSpeed模块
  • 负责任的社交分享链接
  • 首次访问的内联关键CSS
  • async 和
    defer属性的比较
  • 使用字体事件加载字体
  • 使用字体事件再次加载字体
  • 关于字体加载后续——仿文本闪动
  • 播客——通往高性能网站

    1 赞 9 收藏 1
    评论

问题2. 权限太大

当service worker监听fetch事件以后,对应的请求都会经过service
worker。通过chrome的network工具,可以看到此类请求会标注:from service
worker。如果service
worker中出现了问题,会导致所有请求失败,包括普通的html文件。所以service
worker的代码质量、容错性一定要很好才能保证web app正常运行。

 

参考文章:

1. 

2. 

3. 

4. 

5. 

1 赞 3 收藏
评论

澳门微尼斯人手机版 1

JavaScript

JavaScript也会导致render-blocking因此它的加载也应该优化可以使用以下的方法:

  1. 小的内联脚本。
  2. 在文档底部加载外部脚本。
  3. 使用defer属性推迟执行脚本。
  4. 使用async属性异步加载的脚本。

XHTML

<head> <script> // small inline JS </script>
</head> <body> … <script
src=”/path/to/independent-script.js” async> <script
src=”/path/to/parent-script.js” defer> <script
src=”/path/to/dependent-script.js” defer> </body>

1
2
3
4
5
6
7
8
9
10
11
<head>
  <script>
    // small inline JS
  </script>
</head>
<body>
  …
  <script src="/path/to/independent-script.js" async>
  <script src="/path/to/parent-script.js" defer>
  <script src="/path/to/dependent-script.js" defer>
</body>

在解析HTML时 defer推迟下载脚本,一旦页面渲染完成执行脚本。defer支持很不错,但据报道存在不一致和不可靠性,所以最好同时使用defer并把脚本放置在文档底部。

在HTML解析和执行时异步下载脚本文件。这允许多个脚本文件并发下载和执行;然而,他们不能保证在一个特定的顺序加载。如果相互依赖可能需要在这些场景下修改任意脚本。

async支持大不如defer,这就是为什么我选择使用loadJS,用来异步加载JS文件的脚本。它支持老式浏览器,同时有一个有用的特性,即根据条件加载脚本。

XHTML

<head> <script> // small inline JS </script>
</head> <body> … <script> // inline loadJS function
loadJS( src, cb ){ .. } // then load your JS
loadJS(“/path/to/script.js”); </script> <script
src=”/path/to/parent-script.js” defer> <script
src=”/path/to/dependent-script.js” defer> </body>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<head>
  <script>
    // small inline JS
  </script>
</head>
<body>
  …
  <script>
    // inline loadJS
    function loadJS( src, cb ){ .. }
    // then load your JS
    loadJS("/path/to/script.js");
  </script>
  <script src="/path/to/parent-script.js" defer>
  <script src="/path/to/dependent-script.js" defer>
</body>

生命周期

先来看一下一个service worker的运行周期

澳门微尼斯人手机版 3
上图是service
worker生命周期,出处

图中可以看到,一个service worker要经历以下过程:

  1.  安装

2.
 激活,激活成功之后,打开chrome://inspect/#service-workers可以查看到当前运行的service
worker

澳门微尼斯人手机版 4

  1. 监听fetch和message事件,下面两种事件会进行简要描述

  2. 销毁,是否销毁由浏览器决定,如果一个service
    worker长期不使用或者机器内存有限,则可能会销毁这个worker

关于作者:cucr

澳门微尼斯人手机版 5

新浪微博:@hop_ping
个人主页 ·
我的文章 ·
17

澳门微尼斯人手机版 1

问题1. 运行时间

service
worker并不是一直在后台运行的。在页面关闭后,浏览器可以继续保持service
worker运行,也可以关闭service
worker,这取决与浏览器自己的行为。所以不要定义一些全局变量,例如下面的代码(来自):

JavaScript

var hitCounter = 0; this.addEventListener(‘fetch’, function(event) {
hitCounter++; event.respondWith( new Response(‘Hit number ‘ +
hitCounter) ); });

1
2
3
4
5
6
7
8
var hitCounter = 0;
 
this.addEventListener(‘fetch’, function(event) {
  hitCounter++;
  event.respondWith(
    new Response(‘Hit number ‘ + hitCounter)
  );
});

返回的结果可能是没有规律的:1,2,1,2,1,1,2….,原因是hitCounter并没有一直存在,如果浏览器关闭了它,下次启动的时候hitCounter就赋值为0了
这样的事情导致调试代码困难,当你更新一个service
worker以后,只有在打开新页面以后才可能使用新的service
worker,在调试过程中经常等上一两分钟才会使用新的,比较抓狂。

快速提升前端性能

2015/09/26 · HTML5,
JavaScript · 1
评论 ·
性能

本文由 伯乐在线 –
cucr
翻译,唐尤华
校稿。未经许可,禁止转载!
英文出处:Jonathan
Suh。欢迎加入翻译组。

去年,我写了一篇文章Need for
Speed,分享了在开发我的网站中使用的工作流程和技术(包含工具)。从那时起,我的网站又经过了一次重构,完成了很多工作流程和服务器端改进,同时我对前端性能也给与了额外关注。以下就是我做的工作,为什么我要这么做,以及我在网站上用来优化前端性能的工具。

利用service workder缓存文件

下面介绍一个利用service worker缓存离线文件的例子
准备index.js,用于注册service-worker

澳门微尼斯人手机版,JavaScript

if (navigator.serviceWorker) {
navigator.serviceWorker.register(‘service-worker.js’).then(function(registration)
{ console.log(‘service worker 注册成功’); }).catch(function (err) {
console.log(‘servcie worker 注册失败’) }); }

1
2
3
4
5
6
7
if (navigator.serviceWorker) {
    navigator.serviceWorker.register(‘service-worker.js’).then(function(registration) {
        console.log(‘service worker 注册成功’);
    }).catch(function (err) {
        console.log(‘servcie worker 注册失败’)
    });
}

在上述代码中,注册了service-worker.js作为当前路径下的service
worker。由于service
worker的权限很高,所有的代码都需要是安全可靠的,所以只有https站点才可以使用service
worker,当然localhost是一个特例。
注册完毕,现在开始写service-worker.js代码。
根据前面的生命周期图,在一个新的service
worker被注册以后,首先会触发install事件,在service-workder.js中,可以通过监听install事件进行一些初始化工作,或者什么也不做。
因为我们是要缓存离线文件,所以可以在install事件中开始缓存,但是只是将文件加到caches缓存中,真正想让浏览器使用缓存文件需要在fetch事件中拦截

JavaScript

var cacheFiles = [ ‘about.js’, ‘blog.js’ ];
self.addEventListener(‘install’, function (evt) { evt.waitUntil(
caches.open(‘my-test-cahce-v1’).then(function (cache) { return
cache.addAll(cacheFiles); }) ); });

1
2
3
4
5
6
7
8
9
10
11
var cacheFiles = [
    ‘about.js’,
    ‘blog.js’
];
self.addEventListener(‘install’, function (evt) {
    evt.waitUntil(
        caches.open(‘my-test-cahce-v1’).then(function (cache) {
            return cache.addAll(cacheFiles);
        })
    );
});

首先定义了需要缓存的文件数组cacheFile,然后在install事件中,缓存这些文件。
evt是一个InstallEvent对象,继承自ExtendableEvent,其中的waitUntil()方法接收一个promise对象,直到这个promise对象成功resolve之后,才会继续运行service-worker.js。
caches是一个CacheStorage对象,使用open()方法打开一个缓存,缓存通过名称进行区分。
获得cache实例之后,调用addAll()方法缓存文件。

这样就将文件添加到caches缓存中了,想让浏览器使用缓存,还需要拦截fetch事件

JavaScript

// 缓存图片 self.addEventListener(‘fetch’, function (evt) {
evt.respondWith( caches.match(evt.request).then(function(response) { if
(response) { return response; } var request = evt.request.clone();
return fetch(request).then(function (response) { if (!response &&
response.status !== 200 &&
!response.headers.get(‘Content-type’).match(/image/)) { return response;
} var responseClone = response.clone();
caches.open(‘my-test-cache-v1’).then(function (cache) {
cache.put(evt.request, responseClone); }); return response; }); }) ) });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 缓存图片
self.addEventListener(‘fetch’, function (evt) {
    evt.respondWith(
        caches.match(evt.request).then(function(response) {
            if (response) {
                return response;
            }
            var request = evt.request.clone();
            return fetch(request).then(function (response) {
                if (!response && response.status !== 200 && !response.headers.get(‘Content-type’).match(/image/)) {
                    return response;
                }
                var responseClone = response.clone();
                caches.open(‘my-test-cache-v1’).then(function (cache) {
                    cache.put(evt.request, responseClone);
                });
                return response;
            });
        })
    )
});

通过监听fetch事件,service worker可以返回自己的响应。

首先检缓存中是否已经缓存了这个请求,如果有,就直接返回响应,就减少了一次网络请求。否则由service
workder发起请求,这时的service workder起到了一个中间代理的作用。

service worker请求的过程通过fetch
api完成,得到response对象以后进行过滤,查看是否是图片文件,如果不是,就直接返回请求,不会缓存。

如果是图片,要先复制一份response,原因是request或者response对象属于stream,只能使用一次,之后一份存入缓存,另一份发送给页面。
这就是service worker的强大之处:拦截请求,伪造响应。fetch
api在这里也起到了很大的作用。

 

service
worker的更新很简单,只要service-worker.js的文件内容有更新,就会使用新的脚本。但是有一点要注意:旧缓存文件的清除、新文件的缓存要在activate事件中进行,因为可能旧的页面还在使用之前的缓存文件,清除之后会失去作用。

 

在初次使用service worker的过程中,也遇到了一些问题,下面是其中两个

最小化请求

所有在你的网站加载时用来渲染页面(外部CSS或JS文件、web字体、图片等等)的资源,都是不同的HTTP请求。一般的网站平均有 93个请求!

我的目标是减少HTTP请求。一种方法是分别编译或连接(组合、合并)CSS和javascript到一个文件中。让这个过程自动化(例如使用构建工具 Grunt 或 Gulp)是理想的效果,但至少也应该在生产环境下手动完成。

第三方脚本是增加额外请求最常见的罪魁祸首,很多获取额外的文件如脚本、图像或CSS的请求都不止1个。浏览器内置的开发者工具可以帮助你发现这些元凶。

澳门微尼斯人手机版 7
Google Chrome开发者工具的网络选项卡

例如,Facebook的脚本发起3次请求。测试环境中使用一些来自著名社交网站的社交分享脚本,可以看到他们快速增加:

站点 文件 大小
Google+ 1 15.1KB
Facebook 3 73.3KB
LinkedIn 2 47.7KB
Pinterest 3 12.9KB
Tumblr 1 1.5KB
Twitter 4 52.7KB
Total 14 203.2KB

来源:更有效的社会分享链接

这有额外的14个HTTP请求,共203.2KB。相反,我看看 “share-intent” 这个url,它基本上是通过传递和构建数据来生成一个共享,可以只使用HTML来创建社交共享链接。它让我丢掉用于共享的第三方脚本,这些脚本需要7次请求。我在Responsible
Social Share
Links这篇文章有更多的阐述。

评估每一个第三方脚本并确定其重要性。也许存在一种不依赖第三方的方法来完成它。你可能会失去一些功能(例如like、tweet、分享数量),但是请问一下自己:“像数量统计就那么重要吗?”

发表评论

电子邮件地址不会被公开。 必填项已用*标注