Service Worker实现浏览器端页面渲染或CSS,JS编译

这篇文章发布于 2018年04月24日，星期二，22:49，归类于 JS实例。阅读 36194 次, 今日 3 次 15 条评论

by zhangxinxu from http://www.zhangxinxu.com/wordpress/?p=7488
本文可全文转载，但需要保留原作者和出处，摘要引流则随意。

Service Worker提供了一种能力，可以fetch请求的资源，然后后Service Worker中进行编译或转化，返回处理后的其他资源，这种特性可以用来实现各种资源的在线的客户端编译，本文就将抛砖引玉，通过两个应用案例，展示未来web开发可能的面貌。

一、Service Worker与直接数据和HTML模板渲染页面

现在很多网站的页面是基于Node.js直接渲染输出的，以实现完全的前后端分离，而这种渲染本质上还是在服务端进行的，只是渲染的语言是JavaScript。

实际上，有了Service Worker，我们可以直接在客户端，也就是浏览器里面直接进行渲染，优点是……乍一想，其实没什么特别的优点，无非是传输的HTML页面的体积小了，不过这点优化的体积就像是隔靴搔痒，杯水车薪，不值一提。但后来有一想，不对啊，这HTML编译全在客户端执行，岂不是省了很多服务器，为公司省了很多钱，因为烧的都是用户的电。

而且，毕竟是另外的一种解决思路，保不准某些场景下能大放异彩呢，抛砖引玉嘛，重在能力展示。

我们先看实际例子，您可以狠狠地点击这里：Service Worker与客户端渲染HTML渲染页面demo

打开一看，就是个列表，而且数据还是2012年北京蔬菜价格什么鬼？首先，数据什么的不是重点，只从为了节约时间从这篇文章“基于HTML模板和JSON数据的JavaScript交互”弄过来的，

这个页面玄机的要看开发文件源代码才行（右键页面源代码都不行）：https://github.com/zhangxinxu/https-demo/tree/master/online-render

可以看到，index.html文件源代码列表明明是模板语法：

html开发源代码

但是我们右键页面，查看HTML源代码的时候确是真实的列表内容：

html在线编译后的页面源代码

为什么会发生这么神奇的事情？玄机就是Service Worker在背后做了HTML的数据渲染。

首先，注册Service Worker，代码如下：

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('./sw-reader.js', {
        scope: './'
    });
}

然后关键就是sw-reader.js（访问点击这里），做了两件事情：

内置极简模板渲染引擎，采用的是老版本的artTemplate，大小仅2.3K。截图如下：

捕获.html的请求，并对获取到的的HTML字符内容进行模板渲染，并返回输出。完成JS代码如下：

self.addEventListener('fetch', function(event) {
  event.respondWith(async function () {
    if (/\.html/.test(event.request.url)) {
      let res = await fetch(event.request);
      let text = await res.text();
      
      var data = {};
      // 过滤JSON数据，使不暴露给用户
      text = text.replace(/([\w\W]*?)<\/script>/, function (matchs, $1) {
        // 获取页面渲染的JSON数据
        data = JSON.parse($1);
        return '';
      });
      // 模板text和数据data进行渲染并重新返回给浏览器
      return new Response(template.compile(text)(data), {
        headers: {
          'content-type': 'text/html; charset=utf-8'
        }
      });
    }
    return fetch(event.request);
  }());
});

也就是变量text是原始的HTML代码，而在Service Worker中返回的是template.compile(text)(data)渲染后的HTML代码，于是，浏览器中呈现的就是最终的列表数据而非原始模板HTML。

在本demo中，我是将页面需要的JSON数据放在了模板页面头部，并使用<script type="text/json">进行标示，截图如下：

JSON数据标识

sw-reader.js中就是匹配<script type="text/json">获取JSON数据来进行渲染的。当然，你也可以使用其他标识，例如，前后都3个美元符号包起来进行识别，例如：

$$${
   list: []
}$$$

就是不怎么雅观。OK，小例子，抛砖引玉，下面看另外一个对静态资源进行编译的例子。

二、Service Worker与浏览器直接CSS编译

CSS一些预编译工具，例如，Less，Stylus都是使用JavaScript进行编译的，而这些编译工具都是有web版的，因此，理论上我们是可以把Less，Stylus的编译直接搬到浏览器客户端里面，然后我们就不用加载CSS文件了，直接加载less文件，Service Worker中编译成CSS并返回，页面也是可以正常访问的。

然后，问题在于，Less，Stylus的web版解析器体积有些大，压缩后还有150多K，个人觉得成本有点高了。

Less的JS尺寸

为了快速书写，我自己弄了个名为Qcss的编译工具，可以讲CSS声明自定义为缩写，以实现写CSS代码如马踏飞燕，例如：

.class-a { dib; w100; tc; }

可以实时转换成：

.class-a {
  display: inline-block;
  width: 100px;
  text-align: center;
}

而这个编译的JS方法提及非常小，仅2K多一点，和less的JS代码量相比简直就是毛毛雨，因此非常使用用在Service Worker实现一个可以在线编译CSS的功能。

先看例子，您可以狠狠地点击这里：Qcss和Service Worker在浏览器中编译成CSS demo

我们打开控制台查看网络请求，会发现，页面请求的是qcss文件，而不是传统的css文件：

请求的是qcss文件

而这个qcss文件原始代码是这样的：

qcss原始代码

全是一些CSS属性和属性值的缩写，但是，我们在demo页面查看qcss.test的请求数据，却是正统的CSS代码，截图示意如下：

源代码是CSS代码

同样的，也是Service Worker在浏览器背后编译的功劳，注册Service Worker的JS文件的核心代码如下：

var qcss=function(b){ /*qcss编译为css方法* /};

self.addEventListener('fetch', function(event) {
  event.respondWith(async function () {
    if (/\.qcss/.test(event.request.url)) {
      let res = await fetch(event.request);
      let text = await res.text();
      return new Response(qcss(text), {
        headers: {
          'content-type': 'text/css; charset=utf-8'
        }
      });
    }
    return fetch(event.request);
  }());
});

对吧，通俗易懂，一路了然。

这种在线编译有什么好处呢？例如省流量，test.qcss文件为7K多，而test.css文件则14K多，相比传统CSS文件传输体积小了50%，注意，这已经是压缩后的CSS再减小50%体积，根据自己测试，减小的体积在30%~50%之间（选择器越简洁压缩率越高）。

想想看，要是公司产品所有CSS都变成Qcss，传输小30%~50%，估计可以给公司省不少流量钱。

为此，我特意又写了个Node.js工具，可以把CSS文件转换成QCSS文件：https://github.com/zhangxinxu/gulp-qcss/blob/master/css2qcss.js

一个压缩器，一个解析器，外加Service Worker，就可以颠覆目前的CSS资源加载策略，对于一些无关紧要的小项目活动页面之类的，大家其实可以试试这种新技术，验证其价值。

关于QCSS解析及压缩，以后时机成熟我会专门介绍，这里，抛砖引玉，为大家的技术选项实践提供更开阔的思路。