elican 是那些想要自我托管简单网站或博客的 Python 用户的绝佳选择。

如果你想创建一个自定义网站或博客，有很多选择。许多提供商可以托管你的网站并为你完成大部分工作。（WordPress 是一个非常受欢迎的选项。）但是使用托管方式，你会失去一些灵活性。作为一名软件开发人员，我更喜欢管理我自己的服务器，并在我的网站如何运行方面保持更多的自由。

然而，管理 Web 服务器需要大量的工作。安装它并获得一个简单的应用程序来提供内容是非常容易的。但是，维护安全补丁和更新是非常耗时得。如果你只想提供静态网页，那么拥有一个 Web 服务器和一系列应用程序可能会得不偿失。手动创建 HTML 页面也不是一个好选择。

这是静态网站生成器的用武之地。这些应用程序使用模板来创建所需的静态页面，并将它们与关联的元数据交叉链接。（例如，所有显示的页面都带有公共标签或关键词。）静态网站生成器可以帮助你使用导航区域、页眉和页脚等元素创建一个具有公共外观的网站。

我使用 Pyhton 已经很多年了，所以，当我第一次开始寻找生成静态 HTML 页面的东西时，我想要用 Python 编写的东西。主要原因是我经常想要了解应用程序如何工作的内部细节，而使用一种我已经了解的语言使这一点更容易。（如果这对你不重要或者你不使用 Python，那么还有一些其他很棒的 静态网站生成器 ，它们使用 Ruby、JavaScript 和其它语言。）

我决定试试 Pelican 。它是一个用 Python 编写的常用静态网站生成器。它支持 reStructuredText （LCTT 译注：这是一种用于文本数据的文件格式，主要用于 Python 社区的技术文档），并且也支持 Markdown ，这需要通过安装必需的包来完成。所有任务都是通过命令行界面（CLI）工具执行的，这使得熟悉命令行的任何人都可以轻松完成。它简单的 quickstart CLI 工具使得创建一个网站非常容易。

在本文中，我将介绍如何安装 Pelican 4，添加一篇文章以及更改默认主题。（注意：我是在 MacOS 上开发的，使用其它 Unix/Linux 实验结果都将相同，但我没有 Windows 主机可以测试。）

安装和配置

第一步是创建一个 虚拟环境 ，在虚拟环境中安装 Pelican。

$ mkdir test-site

$ cd test-site

$ python3 -m venv venv

$ ./venv/bin/pip install --upgrade pip

...

Successfully installed pip-18.1

$ ./venv/bin/pip install pelican

Collecting pelican

...

Successfully installed MarkupSafe-1.1.0 blinker-1.4 docutils-0.14 feedgenerator-1.9 jinja2-2.10 pelican-4.0.1 pygments-2.3.1 python-dateutil-2.7.5 pytz-2018.7 six-1.12.0 unidecode-1.0.23

Pelican 的 quickstart CLI 工具将创建基本布局和一些文件来帮助你开始，运行 pelican-quickstart 命令。为了简单起见，我输入了网站标题和作者的名字，并对 URL 前缀和文章分页选择了 “N”。（对于其它选项，我使用了默认值。）稍后在配置文件中更改这些设置非常容易。

$ ./venv/bin/pelicanquickstart

Welcome to pelicanquickstart v4.0.1.

This script will help you create a new Pelican-based website.

Please answer the following questions so this script can generate the files needed by Pelican.

> Where do you want to create your new web site? [.]

> What will be the title of this web site? My Test Blog

> Who will be the author of this web site? Craig

> What will be the default language of this web site? [en]

> Do you want to specify a URL prefix? e.g., https://example.com (Y/n) n

> Do you want to enable article pagination? (Y/n) n

> What is your time zone? [Europe/Paris]

> Do you want to generate a tasks.py/Makefile to automate generation and publishing? (Y/n)

> Do you want to upload your website using FTP? (y/N)

> Do you want to upload your website using SSH? (y/N)

> Do you want to upload your website using Dropbox? (y/N)

> Do you want to upload your website using S3? (y/N)

> Do you want to upload your website using Rackspace Cloud Files? (y/N)

> Do you want to upload your website using GitHub Pages? (y/N)

Done. Your new project is available at /Users/craig/tmp/pelican/test-site

你需要启动的所有文件都准备好了。

quickstart 默认为欧洲/巴黎时区，所以在继续之前更改一下。在你喜欢的文本编辑器中打开 pelicanconf.py 文件，寻找 TIMEZONE 变量。

TIMEZONE='Europe/Paris'

将其改为 UTC。

TIMEZONE='UTC'

要更新公共设置，在 pelicanconf.py 中查找 SOCIAL 变量。

SOCIAL=(('You can add links in your config file', '#'),

('Another social link', '#'),)

我将添加一个我的 Twitter 账户链接。

SOCIAL=(('Twitter (#craigs55)', 'https://twitter.com/craigs55'),)

注意末尾的逗号，它很重要。这个逗号将帮助 Python 识别变量实际上是一个集合。确保你没有删除这个逗号。

现在你已经有了网站的基本知识。quickstart 创建了一个包含许多目标的 Makefile。将 devserver 传给 make 命令将在你的计算机上启动一个开发服务器，以便你可以预览所有内容。Makefile 中使用的 CLI 命令假定放在 PATH 搜索路径中，因此你需要首先激活该虚拟环境。

$ source ./venv/bin/activate

$ make devserver

pelican -lr /Users/craig/tmp/pelican/test-site/content o

/Users/craig/tmp/pelican/test-site/output -s /Users/craig/tmp/pelican/test-site/pelicanconf.py

-> Modified: theme, settings. regenerating...

WARNING: No valid files found in content for the active readers:

| BaseReader (static)

| HTMLReader (htm, html)

| RstReader (rst)

Done: Processed 0 articles, 0 drafts, 0 pages, 0 hidden pages and 0 draft pages in 0.18 seconds.

在你最喜欢的浏览器中打开 http://localhost:8000 来查看你的简单测试博客。

你可以在右侧看到 Twitter 链接，左侧有 Pelican、Python 和 Jinja 的一些链接。（Jinja 是 Pelican 可以使用的一种很棒的模板语言。你可以在 Jinja 的文档 中了解更多相关信息。）

添加内容

现在你又了一个基本的网站，试着添加一些内容。首先，将名为 welcome.rst 的文件添加到网站的 content 目录中。在你喜欢的文本编辑器中，使用以下文本创建一个文件：

$ pwd

/Users/craig/tmp/pelican/test-site

$ cat content/welcome.rst

Welcome to my blog!

###################

:date: 20181216 08:30

:tags: welcome

:category: Intro

:slug: welcome

:author: Craig

:summary: Welcome document

Welcome to my blog.

This is a short page just to show how to put up a static page.

Pelican 会自动解析元数据行，包括日期、标签等。

编写完文件后，开发服务器应该输出以下内容：

-> Modified: content. regenerating...

Done: Processed 1 article, 0 drafts, 0 pages, 0 hidden pages and 0 draft pages in 0.10 seconds.

在浏览器中刷新你的测试网站来查看更改。

元数据（例如日期和标签）会自动添加到页面中。此外，Pelican 会自动检测到 intro 栏目，并将该部分添加到顶部导航中。

更改主题

使用像 Pelican 这样流行的开源软件的好处之一是，非常多的用户会做出更改并将其贡献给项目。许多都是以主题形式贡献的。

网站的主题会设置颜色、布局选项等。尝试一个新主题非常容易，你可以在 Pelican 主题 中预览其中的许多内容。

首先，克隆 GitHub 仓库:

$ cd ..

$ git clone --recursive https://github.com/getpelican/pelicanthemes

Cloning into 'pelicanthemes'...

我喜欢蓝色，那么试试 blueidea 。

编辑 pelicanconf.py，添加以下行：

THEME='/Users/craig/tmp/pelican/pelican-themes/blueidea/'

开发服务器将重新生成你的输出。在浏览器中刷新网页来查看新主题。

主题控制布局的方方面面。例如，在默认主题中，你可以看到文章旁边带有元标记的栏目（Intro），但这个栏目并未显示在 blueidea 主题中。

其他考虑因素

本文是对 Pelican 的快速介绍，所以我并没有涉及一些重要的主题。

首先，我对迁移到静态站点犹豫不决的一个原因是它无法对文章评论。幸运的是，有一些第三方服务商将为你提供评论功能。我目前正在关注的是 Disqus 。

接下来，上面的所有内容都是在我的本地机器上完成的。如果我希望其他人查看我的网站，我将不得不将预先生成的 HTML 文件上传到某个地方。如果你查看 pelican-quickstart 输出，你将看到使用 FTP、 SSH、S3 甚至 GitHub 页面的选项，每个选项都有其优点和缺点。但是，如果我必须选择一个，那么我可能会选择发布到 GitHub 页面。

Pelican 还有许多其他功能，我每天都在学习它。如果你想自托管一个网站或博客，内容简单并且是静态内容，同时你想使用 Python，那么 Pelican 是一个很好的选择。它有一个活跃的用户社区，可以修复 bug，添加特性，而且还会创建新的和有趣的主题。试试看吧！

via: https://opensource.com/article/19/1/getting-started-pelican

作者： Craig Sebenik 选题： lujun9972 译者： MjSeven 校对： wxy

本文由 LCTT 原创编译， Linux中国 荣誉推出

点击“了解更多”可访问文内链接

网页展现的更快，官方说法叫做首屏绘制，First Paint 或者简称 FP，直白的说法叫做白屏时间，就是从输入 URL 到真的看到内容（不必可交互，那个叫 TTI, Time to Interactive）之间经历的时间。当然这个时间越短越好。

但这里要注意，和首屏相关的除了 FP 还有两个指标，分别称为 FCP (First Contentful Paint，页面有效内容的绘制) 和 FMP (First Meaningful Paint，页面有意义的内容绘制)。虽然这几个概念可能会让我们绕晕，但我们只需要了解一点：首屏时间 FP 并不要求内容是真实的，有效的，有意义的，可交互的。换言之，随便 给用户看点啥都行。

这就是本文标题的玄机了：“看起来”。是的，只是看起来更快，实际上还是那样。所以本文并不讨论性能优化，讨论的是一个投机取巧的小伎俩，但的确能够实实在在的提升体验。打个比方，性能优化是修炼内功，提升你本身的各项机能；而本文接下来要讨论的是一些招式，能让你在第一时间就唬住对手。

这所谓的招式就是我接下来要谈的内容，学名骨架屏，也叫 Skeleton。你可能没听过这个名字，但你不可能没见过它。

骨架屏长什么样

这种应该是最常见的形式，使用各种形状的灰色矩形来模拟图片和文字。有些 APP 也会使用圆形，但重点都是和实际内容结构近似，不能差距太大。

如果追求效果，还可以在色块表面添加动画（如波纹），显示出一种动态的效果，算是致敬 Loading 了。

在图片居多的站点，这将会是一个很好的体验，因为图片通常加载较慢。如上图演示中的占位图片采用了低像素的图片，即大体配色和变化是和实际内容一致的。

如果无法生成这样的低像素图片，稍微降级的方案是通过算法获取图片的主体颜色，使用纯色块占位。

再退一级，还可以使用全站相同的站位图片，或者直接一个统一颜色的色块。虽说效果肯定不如上面两种，但也聊胜于无。

骨架屏完全是自定义的，想做成什么样全凭你的想象。你想做圆形的，三角形的，立体的都可以，但“占位”决定了它的特性：它不能太复杂，必须第一时间，最快展现出来。

骨架屏有哪些优势

大体来说，骨架屏的优势在于：

1、在页面加载初期预先渲染内容，提升感官上的体验。

2、一般情况骨架屏和实际内容的结构是类似的，因此之后的切换不会过于突兀。这点和传统的 Loading 动图不同，可以认为是其升级版。

3、只需要简单的 CSS 支持 (涉及图片懒加载可能还需要 JS )，不要求 HTTPS 协议，没有额外的学习和维护成本。

4、如果页面采用组件化开发，每个组件可以根据自身状态定义自身的骨架屏及其切换时机，同时维持了组件之间的独立性。

骨架屏能用在哪里

现在的 WEB 站点，大致有两种渲染模式：

前端渲染

由于最近几年 Angular/React/Vue 的相继推出和流行，前端渲染开始占据主导。这种模式的应用也叫单页应用（SPA, Single Page Application）。

前端渲染的模式是服务器（多为静态服务器）返回一个固定的 HTML。通常这个 HTML 包含一个空的容器节点，没有其他内容。之后内部包含的 JS 包含路由管理，页面渲染，页面切换，绑定事件等等逻辑，所以称之为前端渲染。

因为前端要管理的事情很多，所以 JS 通常很大很复杂，执行起来也要花较多的时间。在 JS 渲染出实际内容之前，骨架屏就是一个很好的替补队员。

后端渲染

在这波前端渲染流行之前，早期的传统网站采用的模式叫做后端渲染，即服务器直接返回网站的 HTML 页面，已经包含首页的全部（或绝大部分） DOM 元素。其中包含的 JS 的作用大多是绑定事件，定义用户交互后的行为等。少量会额外添加/修改一些 DOM，但无碍大局。

此外，前端渲染的模式存在 SEO 不友好的问题，因为它返回的 HTML 是一个空的容器。如果搜索引擎没有执行 JS 的能力（称为 Deep Render），那它就不知道你的站点究竟是什么内容，自然也就无法把站点排到搜索结果中去。这对于绝大部分站点来说是不可接受的，于是前端框架又相继推出了服务端渲染（简称 SSR, Server Side Rendering）模式。这个模式和传统网站很接近，在于返回的 HTML 也是包含所有的 DOM，而非前端渲染。而前端 JS 除了绑定事件之外，还会多做一个事情叫做“激活”（hydration），这里就不再赘述了。

不论是传统模式还是 SSR，只要是后端渲染，就不需要骨架屏。因为页面的内容直接存在于 HTML，所以并没有骨架屏出场的余地。

骨架屏怎么用

讨论了一波背景，我们来看如何使用。首先先无视具体的实现细节，先看思路。

实现思路

大体分为几个步骤：

• 往本应为空的容器节点内部注入骨架屏的 HTML。
• 骨架屏为了尽快展现，要求快速和简单，所以骨架屏多数使用静态的图片。而且把图片编译成 base64 编码格式可以节省网络请求，使得骨架屏更快展现，更加有效。

<html>
 <head>
 <style>
 .skeleton-wrapper {
 // styles
 }
 </style>
 <!-- 声明 meta 或者引入其他 CSS -->
 </head>
 <body>
 <div id="app">
 <div class="skeleton-wrapper">
 <img src="data:image/svg+xml;base64,XXXXXX">
 </div>
 </div>
 <!-- 引用 JS -->
 </body>
</html>

• 在执行 JS 开始真正内容的渲染之前，清空骨架屏 HTML
• 以 Vue 为例，即在 mount 之前清空内容即可。

let app=new Vue({...})
let container=document.querySelector('#app')
if (container) {
 container.innerHTML=''
}
app.$mount(container)

仅此两步，并不牵涉多么复杂的机制和高端的 API，因此非常容易应用，赶快用起来！

示例

我编写了一个示例，用于快速展现骨架屏的效果，代码在此。

• index.html
• 默认包含了骨架屏，并且内联了样式（以 <style> 标签添加在头部）。
• render.js
• 它负责创建 DOM 元素并添加到 <body> 上，渲染页面实际的内容，用来模拟常见的前端渲染模式。
• index.css
• 页面实际内容的样式表，不包含骨架屏的样式。

代码的三个文件各司其职，配合上面的实现思路，应该还是很好理解的。可以在 这里 查看效果。

因为这个示例的逻辑太过简单，而实际的前端渲染框架复杂得多，包含的功能也不单纯是渲染，还有状态管理，路由管理，虚拟 DOM 等等，所以文件大小和执行时间都更大更长。我们在查看例子的时候，把网络调成 "Fast 3G" 或者 "Slow 3G" 能够稍微真实一些。

但匪夷所思的是，对着这个地址刷新试几次，我也基本看不到骨架屏（骨架屏的内容是一个居中的蓝色方形图片，外加一条白色横线反复侧滑的高亮动画）。是我们的实现思路有问题吗？

浏览器的奥秘：减少重排

为了排除肉眼的遗漏和干扰，我们用 Chrome Dev Tools 的 Performance 工具来记录刚才发生了什么，截图如下：（截图时的网络设置为 "Fast 3G"）

我们可以很明显地看到 3 个时间点：

1、HTML 加载完成了。浏览器在解析 HTML 的同时，发现了它需要引用的 2 个外部资源 index.js 和 index.css，于是发送网络请求去获取。

2、获取成功后，执行 JS 并注册 CSS 的规则。

3、JS 一执行，很自然的渲染出了实际的内容，并应用了样式规则（随机颜色的横条）。

我们的骨架屏呢？按照预想，骨架屏应该出现在 1 和 2 之间，也就是在获取 JS 和 CSS 的同时，就应该渲染骨架屏了。这也是我们当时把骨架屏的 HTML 注入到 index.html， 还把 CSS 从 index.css 中分离出来的良苦用心，然而浏览器并不买账。

这其实和浏览器的渲染顺序有关。

相信大家都整理过行李箱。我们在整理行李箱时，会根据每个行李的大小合理安排，大的和小的配合，填满一层再放上面一层。现在突然有人跑来跟你说，你的电脑不用带了，你要多带两件衣服，你不能带那么多瓶矿泉水。除了想打他之外，为了重新整理行李箱，必然需要把整理好的行李拿出来再重新放。在浏览器中这个过程叫做重排 (reflow)，而那个馊主意就是新加载的 CSS。显而易见，重排的开销是很大的。

熟能生巧，箱子理多了，就能想出解决办法。既然每个 CSS 文件加载都可能触发重绘，那我能不能等所有 CSS 加载完了一起渲染呢？正是基于这一点，浏览器会等 HTML 中所有的 CSS 都加载完，注册完，一起应用样式，力求一次排列完成工作，不要反复重排。看起来浏览器的设计者经常出差，因为这是一个很正确的优化思路，但应用在骨架屏上就出了问题。

我们为了尽早展现骨架屏，把骨架屏的样式从 index.css 分离出来。但浏览器不知道，它以为骨架屏的 HTML 还依赖 index.css，所以必须等它加载完。而它加载完之后，render.js 也差不多加载完开始执行了，于是骨架屏的 HTML 又被替换了，自然就看不到了。而且在等待 JS, CSS 加载的时候依然是个白屏，骨架屏的效果大打折扣。

所以我们要做的是告诉浏览器，你放心大胆的先画骨架屏，它和后面的 index.css 是无关的。那怎么告诉它呢？

告诉浏览器先渲染骨架屏

我们在引用 CSS 时，会使用 <link rel="stylesheet" href="xxxx> 这样的语法。但实际上，浏览器还提供了其他一些机制确保（后续）页面的性能，我们称之为 preload，中文叫预加载。具体来说，使用 <link rel="preload" href="xxxx">，提前把后续要使用的资源先声明一下。在浏览器空闲的时候会提前加载并放入缓存。之后再使用就可以节省一个网络请求。

这看似无关的技术，在这里将起到很大的作用，因为 预加载的资源是不会影响当前页面的。

我们可以通过这种方式，告诉浏览器：先不要管 index.css，直接画骨架屏。之后 index.css加载回来之后，再应用这个样式。具体来说代码如下：

<link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet'">

方法的核心是通过改变 rel 可以让浏览器重新界定 <link> 标签的角色，从预加载变成当页样式。（另外也有文章采用修改 media 的方法，但浏览器支持度较低，这里不作展开了。我把文章列在最后了）这样的话，浏览器在 CSS 尚未获取完成时，会先渲染骨架屏（因为此时的 CSS 还是 preload，也就是后续使用的，并不妨碍当前页面）。而当 CSS 加载完成并修改了自己的 rel之后，浏览器重新应用样式，目的达成。

不得不考虑的注意点

事实上，并不是把 rel="stylesheet" 改成 rel="preload" 就完事儿了。在真正应用到生产环境之前，我们还有很多事情要考虑。

兼容性考虑

首先，在 <link> 内部我们使用了 onload，也就是使用了 JS。为了应对用户的浏览器没有开启脚本功能的情况，我们需要添加一个 fallback。（不过这点对于单页应用来说可能也无所谓，因为如果没有脚本，那页面实际内容也渲染不出来的）

<noscript><link rel="stylesheet" href="index.css"></noscript>

其次，rel="preload" 并不是没有兼容性问题。对于不支持 preload 的浏览器，我们可以添加一些 polyfill 代码（来使所有浏览器获得一致的效果。

<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

polyfill 的压缩代码可以参见 Lavas 的 SPA 模板第 29 行。

加载顺序

不同于传统页面，我们的实际 DOM 是通过 render.js 生成的。所以如果 JS 先于 CSS 执行，那将会发生跳动。（因为先渲染了实际内容却没有样式，而后样式加载，页面出现很明显的变化）所以这里我们需要严格控制 CSS 早于渲染。

<link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">

JS 对外暴露一个 mountApp 方法用于渲染页面（其实是模拟 Vue 的 mount）

// render.js
function mountApp() {
 // 方法内部就是把实际内容添加到 <body> 上面
}
// 本来直接调用方法完成渲染
// mountApp()
// 改成挂到 window 由 CSS 来调用
window.mountApp=mountApp()
// 如果 JS 晚于 CSS 加载完成，那直接执行渲染。
if (window.STYLE_READY) {
 mountApp()
}

如果 CSS 更快加载完成，那么通过设置 window.STYLE_READY 允许 JS 加载完成后直接执行；而如果 JS 更快，则先不自己执行，而是把机会留给 CSS 的 onload。

清空 onload

loadCSS 的开发者提出，某些浏览器会在 rel 改变时重新出发 onload，导致后面的逻辑走了两次。为了消除这个影响，我们再在 onload 里面添加一句 this.onload=null。

最终的 CSS 引用方式

<link rel="preload" href="index.css" as="style" onload="this.onload=null;this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">
<!-- 为了方便阅读，折行重复一遍 -->
<!-- this.onload=null -->
<!-- this.rel='stylesheet' -->
<!-- window.STYLE_READY=true -->
<!-- window.mountApp && window.mountApp() -->

修改后的效果

修改后的代码在 这里，访问地址在 这里。（为了简便，我省去了处理兼容性的代码，即 <noscript> 和 preload polyfill）

Performance 截图如下：（依然采用了 "Fast 3G" 的网络设置）

这次在 render.js 和 index.css 还在加载的时候页面已经呈现出骨架屏的内容，实际肉眼也可以观测到。在截图的情况下，骨架屏的展现大约持续了 300ms，占据整个网络请求的大约一半时间。

至于说为什么不是 HTML 加载完成立马展现骨架屏，而是还要等大约 300ms 才展现，从图上看是浏览器 ParseHTML 所花费的时间，可能在 Dev Tools 打开的情况下计算资源有限，不过可优化空间已经不大。（可能简化骨架屏的结构能起一些作用吧）

多骨架屏的支持

一般来说一个站点的所有页面不太可能是同一种展示类型。例如说首页和内部页面就展示风格而言会很有区别，另外例如列表页和搜索页比较接近（可能都有列表展示），但和详情页（可能是商品，服务，个人信息，博客文章等等）就会很不相同。但单页应用的 index.html 只有一个，所有的变化都源自前端渲染框架在容器节点内部进行改变。所以直接将骨架屏注入到 index.html中会导致所有的页面都用同一个骨架屏，那就很难达成“和实际内容结构类似”的目标了，骨架屏就退化为 Loading 了。

为了要支持多种骨架屏，我们需要在 index.html 里面进行判断逻辑（独立于主体 JS 之外），具体来说：

1、把所有种类的骨架屏的 HTML 和样式全部写入 index.html

2、在 index.html 底下新增内联的脚本 <script>，根据当前路由判断应该展示哪一个骨架屏

这样会导致 index.html 体积变大一点，但整体感觉依然是收益大于付出，我认为是值得的。

后记

这个优化点最早由我的前同事 xiaop 同学 在开发 Lavas 的 SPA 模板中发现并完成的，Issue 记录在此。我在他的基础上，做了一个分离 Lavas 和 Vue 环境并且更直白的例子，让截图也尽可能易于理解，方便阅读。在此非常感谢他的工作！

另外骨架屏的编写我全部采用的是纯粹的手写 HTML 和 CSS，不止展现逻辑，包括开发流程也是独立于单页应用其他常规页面的。当然这可能给开发者带来一点不便，所以这时候需要推出 xiaop 同学的利器：vue-skeleton-webpack-plugin https://github.com/lavas-project/vue-skeleton-webpack-plugin。它的作用是把骨架屏本身也当成一个 Vue 组件，配上单独的路由规则来统一在 Vue 项目中的开发体验，最后使用 webpack 在打包构建的时候加以区分并注入，对于使用 Vue + webpack 开发的同学来说可以一试。

参考文章

• 让骨架屏更快渲染 https://zhuanlan.zhihu.com/p/34550387- xiaop 同学原作
• Loading CSS without blocking render https://keithclark.co.uk/articles/loading-css-without-blocking-render/- 使用修改 media 的方式达成目的。
• filamentgroup/loadCSS https://github.com/filamentgroup/loadCSS - 同样使用修改 rel 的方式，并提供了 preload polyfill