玩 Blogger 很久了？你可能忽略了 Google 自家的 Firebase Hosting

如果你玩 Blogger 已經很多年，可能還記得以前 Google Drive 不只是拿來存放檔案，還曾經提供過網頁代管功能，可以放 HTML、CSS、JavaScript，甚至直接發布自己製作的靜態網頁。

對 Blogger 玩家來說，這其實非常方便。Blogger 負責文章與內容，Google Drive 則可以拿來放外部 CSS、JavaScript 或獨立製作的網頁，而且兩邊都是 Google 自家的服務。

不過 Google 後來決定停止 Google Drive 的網頁代管功能，並在 2016 年正式關閉。從那之後，如果 Blogger 使用者需要外部空間放 CSS、JavaScript 或靜態 HTML，就得另外尋找其他服務。

十年後重新回頭看這件事情，我才發現：其實 Google 自己早就有一個更正式的解決方案——Firebase Hosting。

而且對 Blogger 使用者來說，Firebase Hosting 並不一定要拿來做什麼複雜的 App 或大型網站。光是拿來處理 Blogger 的外部 CSS、JavaScript，以及發布自己寫的 HTML / CSS / JS 靜態頁面，就已經很實用了。

Firebase Hosting 是什麼？

Firebase 是 Google 旗下的 Web 與 App 開發平台，而 Firebase Hosting 則是其中專門負責網站代管的服務。

如果把事情講得簡單一點，你只要準備好：

index.html
style.css
main.js

Firebase Hosting 就可以負責把這些檔案發布到 Internet。

它支援 HTTPS、CDN、自訂網域，也提供免費使用額度。對只是放 HTML、CSS、JavaScript 的個人網站來說，入門門檻並不高。

它和當年的 Google Drive Hosting 有一個很重要的差異：

Google Drive 原本是雲端硬碟，只是附帶提供網頁代管能力；Firebase Hosting 從產品定位上，就是正式的 Web Hosting。

所以 Google Drive Hosting 當年停止服務，並不代表 Google 從此不提供 HTML、CSS、JavaScript 的網站發布工具，而是這類需求後來有了更正式、更符合網站部署邏輯的產品。

當然，Firebase Hosting 並不是傳統的虛擬主機。它不能直接拿來取代一般 PHP + MySQL 的主機環境，所以 WordPress、PHP 系統這類網站，仍然需要適合的伺服器環境。

但如果你的需求剛好就是純 HTML + CSS + JavaScript，那 Firebase Hosting 就非常值得研究。

用途一：當成 Blogger 的 CSS / JavaScript 外部主機

這是我認為 Blogger 使用者最值得注意的用途之一。

Blogger 本身可以修改 HTML，也可以直接在範本裡加入 CSS 和 JavaScript。剛開始修改 Blogger 時，把程式碼全部放進範本確實很方便。

但是網站使用久了、客製化內容愈來愈多，很容易變成：

Blogger Template
│
├── Blogger XML
├── HTML
├── CSS
├── JavaScript
├── 第三方程式
└── 各種客製化修改

所有東西全部塞在同一份 Blogger 範本裡。

短期使用可能沒有問題，但維護幾年之後，程式碼很容易變得愈來愈龐大。每次要修改一個 CSS 樣式或 JavaScript 功能，都得進 Blogger 後台，在整份 XML 範本裡尋找程式碼。

既然 CSS 和 JavaScript 本來就是獨立的前端資源，其實可以把它們抽離出來。

例如在 Firebase Hosting 裡建立：

css/
└── blogger.css

js/
└── main.js

然後 Blogger 範本只需要引用：

<link rel="stylesheet"
      href="https://static.example.com/css/blogger.css">

<script defer
        src="https://static.example.com/js/main.js"></script>

這時 Blogger 與前端程式就有了比較清楚的分工：

Blogger：負責文章、內容、分類與 CMS。

Firebase Hosting：負責 CSS、JavaScript 與其他靜態前端資源。

以後如果要修改網站樣式，可以直接使用 VS Code、AI IDE 或自己習慣的開發工具編輯 Style.css，完成後再重新部署到 Firebase Hosting。

Blogger 範本本身不需要跟著塞進大量 CSS 或 JavaScript。

對長期維護 Blogger 的人來說，這種做法會比把所有東西全部塞進 Blogger XML 範本乾淨很多。

Firebase Hosting 也可以成為多個 Blogger 網站的共用資源

如果自己同時維護不只一個 Blogger，還可以進一步把共用的 CSS 和 JavaScript 集中管理。

例如：

Firebase Hosting
│
├── shared/
│   ├── variables.css
│   ├── components.css
│   └── utilities.js
│
├── blog/
│   └── Style.css
│
└── news/
    └── news.css

共用元件放在 shared，不同 Blogger 再載入自己的專屬樣式。

這時 Firebase Hosting 的角色，就很接近 Blogger 的前端靜態資源主機。

Blogger 繼續負責內容發布，而 CSS、JavaScript 的開發與維護，可以回到比較正常的前端開發流程。

用途二：取代「為了嵌入 HTML 而使用 Google Sites」

另外一個我自己覺得非常實用的情境，就是 Google Sites（Google 協作平台）。

Google Sites 當然很好用。

如果今天只是要快速建立活動資訊、社團網站、簡單介紹頁或內部資訊頁，而且負責維護的人不會 HTML，Google Sites 的確非常方便。

不用買主機、不需要寫程式，也不必理解網站部署，只要用視覺化介面就可以建立網站。

問題出現在另外一種情況：

你明明已經會 HTML、CSS、JavaScript，甚至已經把網頁寫好了，卻只是因為需要一個地方發布，所以先建立 Google Sites，再把自己的 HTML 嵌進去。

這時候事情就開始有點奇怪了。

「嵌入 HTML」不等於真正的 HTML Hosting

Google Sites 雖然可以嵌入 HTML，但這並不等於真正的 HTML Hosting。

它比較接近「在 Google Sites 的頁面裡，放入一個受到控制的嵌入內容」。

整體架構比較像：

Google Sites
│
├── Google 控制的網站架構
├── Google 控制的版面
├── Google 控制的導覽
│
└── Embed
    │
    └── 你的 HTML / CSS / JS

你可以在 Google Sites 裡面寫出一個很漂亮的 HTML 區塊，但它終究只是 Google Sites 頁面裡的一塊內容。

外面的網站架構、頁面邏輯與許多版面行為，仍然是 Google Sites 決定的。

真正的 HTML Hosting 則完全不同：

Browser
   ↓
你的 index.html
   ↓
你的 CSS
   ↓
你的 JavaScript

整個網頁就是你的。

這也是為什麼本來就會 HTML / CSS 的人，在 Google Sites 裡製作比較複雜的網站時，很容易開始覺得綁手綁腳。

因為你不是完全在設計自己的網頁，而是在 Google Sites 已經決定好的網站架構裡，想辦法塞進自己的設計。

如果只是為了嵌入 HTML，其實可以直接用 Firebase Hosting

如果你使用 Google Sites 的主要原因，只是因為：

我需要一個地方放自己寫好的 HTML / CSS / JavaScript。

那 Firebase Hosting 幾乎可以直接取代這個用途。

因為改成 Firebase Hosting 之後，你的 index.html 就是網站本身，而不是另外一個網站裡面的 Embed。

你可以自己控制：

<head>
SEO Meta
Open Graph
HTML 結構
CSS
JavaScript
Responsive Design
Web Font
CSS Animation
Navigation
Footer
PWA

甚至整個網站的 DOM 結構，都可以由自己決定。

如果本來就懂 HTML / CSS，這種自由度與 Google Sites 是完全不同的體驗。

例如：用 Firebase Hosting 製作數位音樂會手冊

我以前曾經使用 Google Sites 製作數位音樂會手冊。

Google Sites 確實可以完成，而且製作速度很快。如果只是要把文字、圖片、節目資訊快速整理成一個可以用手機瀏覽的網站，它是一個很方便的工具。

但如果今天重新做一次，我會考慮直接用 IDE 建立一個真正的靜態網站：

concert/
│
├── index.html
│
├── css/
│   └── style.css
│
├── js/
│   └── main.js
│
└── assets/
    ├── images/
    └── icons/

完成之後，再透過 Firebase Hosting 發布。

如果有自己的網域，甚至可以直接使用：

concert.example.com

觀眾從實體海報、邀請卡或紙本節目單掃描 QR Code：

實體海報 / 節目單
        ↓
      QR Code
        ↓
concert.example.com
        ↓
數位音樂會手冊

這時候整個網站就可以真正按照手機數位手冊的 UX去設計。

例如可以加入：

Sticky Navigation
演出者介紹
曲目展開與收合
節目流程
CSS 動畫
場地資訊
Google Maps
YouTube 演出影片
社群分享
贊助單位資訊
Responsive Design

設計時思考的問題，也會從：

「Google Sites 能不能讓我這樣做？」

變成：

「我希望這個網站怎麼呈現？」

對會 HTML / CSS 的人而言，這兩種思考方式的差異其實非常大。

Blogger + Firebase Hosting 其實很搭

重新整理整個架構之後，我反而覺得 Blogger 與 Firebase Hosting 並不是互相取代的關係。

它們可以各自負責自己擅長的事情：

Blogger
│
├── 文章
├── 新聞
├── 分類
└── CMS
        │
        │ 引用
        ▼
Firebase Hosting
├── CSS
├── JavaScript
├── Landing Page
├── 活動網站
├── 數位手冊
└── 獨立 HTML

Blogger 繼續當 Blogger。

Firebase Hosting 也不需要取代 Blogger。

只是把原本 Blogger 不擅長管理的前端靜態資源抽出來，交給真正適合發布 HTML、CSS、JavaScript 的 Hosting。

這樣反而可以讓 Blogger 專心負責內容，前端程式則回到自己熟悉的 IDE 裡維護。

Firebase Hosting 不需要拿來放大量圖片

如果只是 Blogger 外連 CSS、JavaScript，以及自己製作的 HTML 靜態頁面，Firebase Hosting 的使用量通常不會太大。

但是我不會因為 Firebase Hosting 有免費額度，就把它當成免費圖床或影音空間。

原因很簡單：

HTML、CSS、JavaScript 通常很小；照片、音訊、影片才是真正吃流量的東西。

所以如果原本就有自己的圖片媒體主機、圖床或其他媒體服務，可以繼續讓 Firebase Hosting 專心負責前端。

例如：

Firebase Hosting
↓
HTML / CSS / JavaScript

圖片媒體主機
↓
JPG / WebP / AVIF

YouTube
↓
影片

各種服務負責自己擅長的工作，反而比把所有東西全部塞進同一個 Hosting 更合理。

如果要長期使用，我會建議綁自己的網域

Firebase Hosting 本身會提供類似下面的網址：

xxxxx.web.app

直接使用當然沒有問題。

但如果準備長期拿 Firebase Hosting 當 Blogger 的 CSS / JavaScript 來源，我會更建議使用自己的子網域，例如：

static.example.com

然後 Blogger 引用：

https://static.example.com/css/blogger.css

而不是讓 Blogger 範本大量寫死：

https://xxxxx.web.app/css/blogger.css

這麼做的原因很簡單：

沒有任何網路服務能保證永遠存在。

當年的 Google Drive Hosting 就是一個很好的例子。

Google Drive Hosting 曾經很好用，但 Google 最後仍然決定停止服務。

所以真正重要的並不是猜測 Firebase Hosting 未來會不會有政策變化，而是降低自己更換 Hosting 的成本。

假設未來真的需要搬家，只要 HTML、CSS、JavaScript 原始檔還掌握在自己手上，就可以把檔案搬到其他 Static Hosting。

然後只要把：

static.example.com

DNS 改指向新的 Hosting。

因為 Blogger 從頭到尾引用的都是自己的網域：

https://static.example.com/css/blogger.css

所以 Blogger 裡面的網址甚至可以完全不用修改。

真正應該掌握在自己手上的，是自己的網域、HTML、CSS、JavaScript，以及完整的原始檔。

Hosting 可以更換。

自己的網址與程式碼，才是應該長期掌握的資產。

Google Sites 也不是從此沒有用途

使用 Firebase Hosting 並不代表 Google Sites 從此就沒有存在價值。

兩者解決的問題其實不太一樣。

如果網站需要讓不懂程式的人快速修改內容，例如行政人員、活動工作人員或一般使用者，那 Google Sites 的視覺化編輯方式仍然非常方便。

但如果負責網站的人本來就會 HTML、CSS、JavaScript，甚至已經使用 IDE 開發完整的前端，那麼再建立一個 Google Sites，只為了把 HTML 嵌進去，就未必是最合理的做法。

可以簡單理解成：

Google Sites：適合快速建立、不想寫程式的網站。

Firebase Hosting：適合已經寫好 HTML、CSS、JavaScript，需要一個地方正式發布的人。

工具沒有誰一定比較好，重點是它原本要解決什麼問題。

Google Drive Hosting 消失了，但需求其實沒有消失

回頭看十年前的 Google Drive Hosting，我覺得這件事情很有意思。

以前的做法是：

Google Drive
↓
HTML / CSS / JavaScript
↓
公開網址

今天則可以變成：

IDE
↓
HTML / CSS / JavaScript
↓
Firebase Hosting
↓
自己的網域

需求其實一直都存在。

改變的只是工具。

Google Drive 終究是一個雲端硬碟，讓它同時肩負 Web Hosting 並不是最合理的產品定位。

Firebase Hosting 則從產品設計上，就是用來發布網站與靜態前端資源的服務。

所以如果你跟我一樣，是玩 Blogger 很多年、自己會一些 HTML / CSS / JavaScript，又曾經懷念 Google Drive 可以代管網頁的年代，那麼 Firebase Hosting 的確值得重新認識一次。

尤其現在有 VS Code、各種 AI IDE 與 AI 程式開發工具協助之後，製作一個完整 HTML / CSS / JavaScript 靜態網站的門檻，又比十年前低了不少。

Blogger 可以繼續負責內容，Firebase Hosting 負責前端靜態資源；需要完整 HTML 網站時，也不必再為了找一個容器，而把自己寫好的網頁塞進 Google Sites。

有時候我們缺的並不是新的技術。

只是十年後才發現：原來 Google 早就把適合的工具放在另一個地方了。

搜尋此網誌

SHIQUAn Notes