[prerender-spa-plugin]–微型Vue專案的靜態化利器

最近和同事寫了個公司的PC官網，綜合個人開發習慣、週期以及需求，我最終選擇用vue-cli來快捷開發（因為之前已經寫好了基於vue-cli的二次定製腳手架）。上線之後，老大說了一句，還是改回靜態頁吧，SPA的SEO太差啦。這…

本文會涉及到的內容–

• 使用prerender之前的境況介紹
• 使用prerender的姿勢(踩坑)
• 小插曲:nginx的重定向
• 總結

使用prerender之前

我們的官網是特別“純正”的vue-cli專案，也就是說這是個用webpack進行打包的單頁應用。

在路由方面選擇的是vue-router，mode是hash模式，因為並不需要考慮IE瀏覽器以及移動端瀏覽器(特別是微信這個小妖精)，所以並沒有特別注意路由這一塊的配置。

在頁面開發方面，由於是兩人開發，所以我傾向單個頁面分離成多個元件的開發模式，這樣既不互相干擾，後續改動或複用也相對靈活。

balabala…沒過幾天，我們的官網順利上線啦，除了url裡面會帶一個”#”之外，貌似沒啥不妥的地方。直到老大在群裡吐槽url醜&非靜態頁，然後讓我改用靜態頁T T

這讓我陷入沉思…

• 改用HTML/CSS/JS重寫一次？
• 用Nuxt進行SSR?
• 還有啥辦法…

也不知道為啥，突然想起來之前看過一個預渲染的webpack外掛:)

prerender-spa-plugin登場

prerender-spa-plugin是什麼？不太瞭解的童鞋可以傳送門傳走看看–prerender-spa-plugin Github && vue服務端渲染中的介紹

history模式

將原來的hash模式改成了history模式，拋棄了醜醜的”#”並且也為prerender做鋪墊，如果是hash模式的話可能沒有辦法正常的進行預渲染。

webpack配置

因為我們用的是新版的vue-cli，webpack配置檔案已經沒有暴露出來了，我們需要通過修改vue.config.js來更改我們的webpack配置（其中應該是藉助了webpack-merge外掛來實現配置的整合）

const path = require(`path`)
const PrerenderSpaPlugin = require(`prerender-spa-plugin`)
// ...
// ...
configureWebpack: {
    plugins: [
        new PrerenderSpaPlugin(
            // npm run build的輸出目錄
            path.resolve(__dirname, `./raw`),
            // 需要進行預渲染的頁面
            [`/`, `/about`], {
                captureAfterTime: 5000,
                maxAttempts: 10,
            }
        )
    ]
}
複製程式碼

上述配置大意是到相應的目錄，根據router的資訊將有關的頁面預先載入渲染成靜態頁面，並且將靜態頁面以獨立資料夾的形式儲存下來。

下圖是沒有prerender的檔案目錄↓

可以看到，和普通的單頁應用打包輸出一樣，一個index.html入口，動態渲染各個頁面。

使用prerender之後的目錄則是這樣的↓

多出了一個about資料夾，裡面有一個index.html檔案，這裡就是`/about`頁面的靜態頁，這樣我們通過url訪問時就是直接訪問about的靜態頁，而不需要再讓瀏覽器編譯這個頁面。

這樣一來，搜尋引擎就可以直接爬到我們頁面的所有內容，而不是一個單頁應用的啟動頁！

然後在根目錄的index.html也變成`/`頁面的靜態頁，這樣一來就完成了我們官網頁面的靜態化，就是這麼簡單~

因為prerender-spa-plugin的核心人員也是vue的核心人員，所以在vue專案裡面用起來顯得十分順暢，不過如果是大型專案的話可能還是要往SSR方向去走。

下圖為chrome中訪問官網首頁的原始碼–

小插曲:nginx的重定向

在完成某個線上專案的重構之後需要注意一些”蝴蝶效應”–

以我們的官網為例，之前一些公司介紹被百科收錄了，收錄的來源連結是舊的靜態頁連結–“xxx/about.html”，一訪問就涼了，頁面已經不存在了。

一開始打算寫個空的html負責跳轉，但是後面想想這樣不利於頁面的seo，所以就想到是不是可以利用nginx的重定向解決這個問題。

這裡其實花了不少時間，剛開始寫的時候是在location裡面對相應的路徑進行重定向，但是發現效果不理想。後面，東查查西查查，發現可以用rewrite來解決這個問題。

server {
    listen ......
    ......

    rewrite ^about.html https://targetlink.com/about/ permament;

    location / {...}
}
複製程式碼

在nginx裡面加入rewrite這行就可以將”xxx/about.html”這個連結永久重定向至目標url了，就不需要再寫一個“跳板”頁面了。

總結

關於SPA的SEO是永恆的話題，解決的方案其實不多，因為既然決定了使用SPA就代表該專案對SEO並沒有強需求，但是如果是本文的背景下，我們就需要思考最便捷、無痛的解決方案。

SSR自然是首當其衝的方案，但是實在是傷筋動骨，得不償失，不如重寫成靜態頁。後面發現預渲染這個方案十分適合我們，所以就嘗試了一下這個方案，在嘗試這個方案的過程中，我也試了下gitlab的自動部署這又是另外一個坑了，在近期應該會有另外一篇文章來講講這個坑~