TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
LittleLink 自架連結頁實測：把 Linktree 換成自己的檔案
LittleLink 是一套 MIT 授權的開源連結頁系統，把 Linktree 這類代管服務上的個人頁面，換成一份自己擁有的靜態檔案。本文實測它的編輯流程、按鈕樣式的真實數量、零 JavaScript 架構的載入重量，以及自架之後要接手的三件維運責任。
用 AI 摘要這篇文章：
在 Linktree 這類代管服務上放個人連結頁，你擁有的其實是一個帳號：版型從平台的選單裡挑，點擊紀錄在別人的後台裡看，網址掛在對方的網域底下。LittleLink 走了一個極端的路線，它把同一件事壓縮成一份 460 行的 index.html，配上 CSS、字型和按鈕圖示，整包丟到任何靜態主機上，就是一個完全屬於你的連結頁。
我把官方倉庫完整抓下來讀過一遍，另外複製一份改成七顆按鈕的測試頁，在本機跑起來：換上中文標題與簡介、留下 LINE、Instagram、YouTube 這幾顆按鈕，用無頭瀏覽器渲染截圖，再逐個請求量測載入重量。這篇講檔案模式實際上手的樣子，以及接手之後你要負責的東西。
先把結論放前面：LittleLink 適合把連結頁當成自己的一個小網站在經營的人。改連結的動作從打開後台變成打開檔案，換到的是整頁不帶任何指令碼的輕、完整的版型控制權，以及一個不會因為某個平台改政策就消失的頁面。反過來說，靠點擊紀錄調整連結排序、或完全不想碰 HTML 的人，文末的生態段有更適合的選擇。
一份 460 行的 index.html，就是整個產品
打開原始碼，這個專案的本體小到有點不可思議。index.html 一個檔案 460 行，開頭是整套留好位置的 SEO 範本：標題、描述、canonical、Open Graph、twitter:card，連淺色深色兩套 theme-color 都各留一行中繼標籤，讓你換上自己的資料就好。正文結構是四個元素：頭像、名字 h1、一句簡介，然後是一個標了 aria-label 的按鈕堆疊。整份檔案讀完不需要任何背景知識，這是它敢說 DIY 的本錢。
出貨時的按鈕堆疊很有意思：總共 120 顆按鈕全部攤開在那裡，除了頁尾一顆連到擴充庫倉庫的官方推廣鈕，其餘 119 顆的連結都還是 #。它把整本型錄攤開，你的工作是刪，不是寫。其中 16 顆是搭配通用圖示的素面按鈕，涵蓋 RSS 訂閱、Email 聯絡、行事曆、地圖導航、折扣公告這類沒有品牌色可用的場景，想快速拼一頁夠用了。
我的實際編輯流程是這樣：複製整個資料夾，打開 index.html，把 h1 換成中文標題、簡介改成一段中文描述，然後從 120 顆按鈕裡刪到剩下七顆，再回頭把每顆的 # 換成真實網址。你會碰到的每一顆按鈕，長相都是這個樣子：
<a class="button button-line" href="#" target="_blank" rel="noopener">
<img class="icon" aria-hidden="true" src="images/icons/line.svg" alt="Line Logo">Line
</a>class 決定品牌色和文字色，href 換成你的連結，圖示路徑和替代文字都寫好了。改完存檔，用本機伺服器打開，中文標題、中文簡介、七顆按鈕全部正常渲染，淺色主題下每顆按鈕用自己的品牌色實心填滿，一眼就能辨認。頭像的替換也是同一個邏輯，把 images/avatar.png 換成自己的圖，替代文字記得一起改，高解析版 [email protected] 會在 retina 螢幕自動接手。
頁尾還藏了一個細節：倉庫附了一份 privacy.html 隱私頁範本，頁尾連結直接指向它。原因很簡單，部署之後這是你的網站，隱私頁要自己交代，官方把骨架先幫你準備好了。
按鈕的真實數量：核心 93 顆，擴充庫再 73 顆
README 說「超過 100 種品牌按鈕樣式」，我對著 CSS 實際數了一遍：核心的 brands.css 裡定義了 93 個按鈕 class，出貨 index.html 的 102 個品牌按鈕錨點用上其中 92 個，同一顆按鈕掛兩次的情況只有示範性質的 google-black，出現 11 次。嚴格說核心不到一百，README 的數字是把姊妹倉庫 LittleLink Extended 也算進去：那裡再放 73 個長尾服務的按鈕 class，兩邊相加 166 個。行銷數字和程式碼的差距不算欺騙，但你要的是核心那份檔案的輕，挑按鈕時心裡要有這個底數。
台灣使用者的角度看清單會比較安心：LINE 按鈕在核心清單裡，Instagram、YouTube、Twitch、Telegram、WhatsApp、Threads、TikTok 也都在，通訊和社群兩大類不用去擴充庫找。清單裡還有一批帶 -alt 後綴的變體，例如 Apple Music 和 Apple Podcasts 都有第二版，同一個服務給你白底和品牌底兩種視覺，讓按鈕牆的明暗節奏可以自己調。
自訂按鈕有官方工具接手。Button Builder 是一份獨立的網頁工具，左邊即時預覽按鈕長相，右邊讓你填文字、網址、背景色和文字色，畫面上直接顯示三組對比數值：淺色主題、深色主題、文字對按鈕底色各一組，我打開時的預設值是 5.59、3.35、5.59。調完按下複製，CSS 貼進 brands.css、HTML 貼進 index.html 就收工，對比不夠時它還會建議你加描邊。這個工具把「自製一顆不違和的按鈕」的門檻壓到不用懂色彩學。
零 JavaScript 名副其實，載入重量的大頭是字型
「不依賴任何框架或多餘的 JavaScript」是這個專案的核心宣稱，我對著原始碼驗證過：index.html 和 privacy.html 全文沒有任何一個 script 標籤，一個都沒有。互動效果全靠 CSS 完成，深淺主題跟著系統設定走也是 CSS 的媒體查詢在處理。這個宣稱和程式碼完全一致。
重量實測用我那份七按鈕測試頁，量出來的整頁載入是 254,956 bytes，拆開看結構比總數更有意思：三個 Open Sans 字重共 165,728 bytes，佔掉全部的 65%；頭像的高解析版 45,503 bytes；三份 CSS 合計 21,289 bytes；七顆按鈕圖示只有 10,909 bytes，因為圖示是逐顆載入，你留下幾顆才載幾顆；HTML 本身 11,527 bytes。也就是說，這個頁面真正的重量在字型，把字型換成系統字，整頁就能再砍掉一半以上，這是官方沒有明講但你自己動手就能拿到的優化空間。在意重量的讀者，部署前後可以拿 網站速度測試工具 再量一輪，對照字型砍掉前後的差距。
專案自己也在跟重量遺產作戰。2026 年 7 月底的 v3.11.0 一次刪掉約 1.2MB 的舊版 .eot、.svg、.ttf、.woff 字型檔，改成只留 woff2，順便把字型預載提示寫進 HTML。README 引以為傲的那組「範例頁在 Google PageSpeed 四個項目拿滿分」是作者自行測得的宣稱；從零 script 的結構和上面的重量拆解看，方向一致。
零 JavaScript 的另一面也要說清楚：頁面上沒有任何分析或統計程式，你的連結被點了幾次，這份檔案本身一無所知。想看統計要自己外接分析服務，或回頭看主機的存取紀錄。對把「不追蹤訪客」當賣點的人這是優點，對靠流量報表吃飯的人這是第一天就要面對的空缺。
有一個常見誤解順便拆掉：零 JavaScript 是出廠預設，不是能力上限。這終究是你的 HTML 檔，要嵌入訂閱表單、聊天小工具或任何第三方指令碼都貼得進去，瀏覽器不會因為這個專案的名字擋你。差別在於你貼進去的每一段程式都脫離了官方的維護範圍，頁面壞了要自己回溯，這份「乾淨」的持有權也就破了功。官方顧的是出廠那一版的輕與乾淨，你加料後的頁面是另一回事。
這種「整個產品就是一份靜態檔案」的路數，之前介紹過的 QRSVG 線上 QR Code 產生器 也是同一個物種：頁面行為完全透明，打開原始碼就懂全部。差別在 LittleLink 連部署後的主機都是你自己選的。
深色淺色都看得見，因為對比度有 CI 在顧
主題切換的實作樸素到可愛：html 標籤上有一個 class，theme-auto 跟著系統走，改成 theme-dark 或 theme-light 就固定住。我在測試頁上把這個 class 換掉重新截圖，深色主題立刻生效，黑底上每顆按鈕的文字都是白色粗體，品牌色實心鈕在兩種主題下都清晰可讀。
真正讓我覺得這個專案不一樣的，是它把「按鈕看得見」當成工程問題在管。倉庫裡有一條 CI 流程：只要有人送 PR 動到 brands.css，自動腳本會對每顆被改到或新增的按鈕計算 WCAG 的對比比值，門檻 4.5:1，總共查三組關係，文字對按鈕底色、按鈕對淺色主題背景、按鈕對深色主題背景。對比不過關但加了反色描邊的按鈕視為通過，用漸層當底色的按鈕機器算不了，直接退回人工審查。v3.11.0 還強化了這條流程，讓修改既有按鈕的 PR 也躲不過檢查。
這套邏輯在頁面上的長相是：官方範例頁的淺色主題下，Bluesky 和 Unsplash 這類淺色底的品牌按鈕，會自動出現一圈深色描邊，白底按鈕才不會融進白底頁面。Button Builder 介面上那三組對比數值，就是同一套判斷的圖形介面版。官方也誠實承認限制：品牌按鈕進倉庫時保留品牌原色，不是每顆都能達到無障礙標準，描邊機制就是為了補這個落差。
同一版的版本史還記著一整套標記層的重做：把連結按鈕上誤用的 role="button" 拿掉、按鈕堆疊改用帶 aria-label 的 nav 元素包住、整頁內容放進 main、修正原本寫錯成中繼標籤的 canonical、移除早就沒人用的關鍵字中繼標籤。這些改動讀者看不見，但對讀報軟體的使用者和搜尋引擎爬蟲都是實質改善，也說明維護者對「看得到的品質」和「看不到的品質」是同一個態度在顧。
部署不難，難的是你接手的三件事
把這份檔案送上線的路徑多到眼花：README 提供五個一鍵部署按鈕，Cloudflare、DigitalOcean、Vercel、Netlify、Amplify 各一個；倉庫裡有 Cloudflare Workers 的 wrangler.toml、DigitalOcean App Platform 的部署範本，還有一個以 nginx 為底的 Docker 設定，自己有主機或 NAS 的人可以照 Docker Compose 的習慣收進既有的服務堆裡，之前整理過的 NAS Docker Compose 模板合集 是順手的起點；最陽春的 GitHub Pages 也官方支援。Cloudflare 這條路之前介紹過的 SubsTracker 走過一遭，靜態工具放上 Workers 的門檻比想像中低。倉庫裡三份自架配置檔與一鍵部署文件都配齊，帳號層的部署流程各家畫面不同，照各平台文件走即可。
真正的成本不在部署，在部署之後你接手的三件事。
改連結這件事，等於改檔案。想到一顆新連結，流程是打開 index.html、貼上網址、存檔、重新部署。一年改兩次的人無感，一週改兩次的人會開始想念後台。
統計是第二個空缺。這種架構下頁面不會自己記錄任何東西，真正的成本是把「沒有數字」納入日常決策：要嘛外接分析服務，要嘛習慣憑感覺調整連結排序。
品牌按鈕的生死最隱性。版本史裡有三筆現成的例子，v3.11.0 移除 Kit 按鈕，因為 Kit.co 這個服務在 2026 年 5 月收攤了；同一版移除 Google Podcasts 的圖示，因為服務停產；更早的 v3.2.0 移除了正在收攤的 Read.cv。上游倉庫持續在清理死掉的服務，但你自己 fork 出去之後，這份清理工作就變成你的例行公事，頁面上掛一顆連到已消失服務的按鈕，是最常見的緩慢腐爛。
把兩種模式放在一起看會更具體：
| 面向 | 代管連結頁服務（Linktree 這類） | LittleLink 檔案模式 |
|---|---|---|
| 頁面放在哪 | 對方平台，掛在帳號底下 | 你自己的主機，一份靜態檔案 |
| 改一個連結 | 登入後台，選單點一點 | 編輯 index.html，重新部署 |
| 點擊紀錄 | 後台內建 | 頁面本身零統計，自己外接 |
| 版型控制 | 平台提供的範本與選項 | CSS 直接改，整份換掉也行 |
| 訪客追蹤 | 由平台決定 | 全頁零 JavaScript，你加了才有 |
| 服務收攤時 | 平台倒，大家一起搬家 | 倉庫還在，fork 之後自己續命 |
表中代管欄位寫的是這類服務的共同形態（2026 年 9 月），個別平台的功能與方案有差異。
想要後台的人，生態已經給了答案
LittleLink 的檔案哲學不是每個人都受得了，而這個專案最有趣的地方，是它長出來的生態比它自己還大。LinkStack 是接著 LittleLink Admin 脈絡發展出來的後台版，裝起來就有管理介面，在 GitHub 上有 3,879 顆星，比 LittleLink 本體的 3,084 顆還多。另一條路線的 littlelink-server 把整套東西包成 Docker 映像檔、連結與頁面內容全用環境變數配置，1,147 顆星，到 2026 年 9 月都還有提交活動。想要「連結頁加後台」的人，這兩條路比硬用檔案派工具舒服。
但選了後台路線，你接手的東西也換了一批：靜態檔案沒有資料庫可以被打，也沒有管理介面的密碼可以外洩；放著三年不更新，受攻擊面也不會長大，這些是檔案模式白拿的安全紅利。後台版多了方便，也就多了要定期更新的服務、要備份的資料，還有跑在哪台機器上的維運問題。說走就走的可攜性同樣沒了，靜態檔案今天不高興換一家主機，明天 DNS 生效前後就搬完，後台版的搬家是一個專案工程。
最後交代專案本身的健康狀態：MIT 授權，授權條款上寫著著作權人 Seth Cottle 從 2019 年起維護，倉庫 2019 年 12 月建立，累積 257 個提交，最新版 v3.11.0 在 2026 年 7 月下旬出版，沒有歸檔，issue 與社群 PR 都還有人處理。七年歷史、緩慢但持續的節奏，這是一個活著的專案。
誰該用一份檔案換掉一個帳號
整理成一個判斷：你已經有網域或熟悉的靜態主機、把連結頁當個人門面在經營、在意頁面重量與訪客追蹤，這幾個條件都成立的話，LittleLink 給你的每一樣都是代管服務給不了的。拿兩種人當例子：接案的攝影師，作品集連結一年換兩次，頁面想完全長成自己的樣子，用 LittleLink 一次設定可以放著不管；辦活動的單位，贊助商連結每場都要換、活動結束要看重播流量，這種節奏留在代管服務或後台版本裡會輕鬆得多。反過來說，連結常常在換、或聽到要打開 HTML 檔就頭痛的人，多半在第三次手動部署時就會放棄，上面生態段的後台版本或原本的代管服務都是更好的歸宿。
三個常見問題：
完全不會寫程式，用得起來嗎？ 需要會的全部是「找到那一行、把網址換掉、把不要的按鈕刪掉」這個層級的編輯，比想像中接近改文件而不是寫程式。但若連這個都想要圖形介面，LinkStack 那條路更適合你。
它本身要錢嗎？ 專案是 MIT 授權的開源軟體，不收費。成本在兩處：靜態主機的費用（多數平台有免費額度）和你自己維護的時間。
台灣常用的服務有按鈕嗎？ LINE 在核心清單，主要社群與影音平台也都齊。真的缺的服務，去 Extended 擴充庫找，或用 Button Builder 十分鐘自己做一顆。
LittleLink 賣的從來不是功能多，而是「這一頁是你的」這件事本身。想清楚你要的是帳號的方便還是檔案的擁有權，答案就出來了。
