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 都加載完，注冊完，一起應用樣式，力求一次排列完成工作，不要反復重排?？雌饋頌g覽器的設計者經常出差，因為這是一個很正確的優化思路，但應用在骨架屏上就出了問題。

我們為了盡早展現骨架屏，把骨架屏的樣式從 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