相簿、燈箱、瀑布流、浮水印、密碼保護、客戶選片，甚至購物功能，幾乎都能找到現成外掛。對多數人來說，安裝 WordPress、選一個好看的佈景主題，再挑幾個相簿外掛，很快就能把作品放上網。
那我為什麼還要把網站放在自己的 Synology NAS 上，甚至自己寫一套照片網站？
答案不是「WordPress 不夠好」，而是當照片越來越多、需求越來越個人化之後，我開始想控制的已經不只是版面，而是照片到底怎麼被整理、傳送、搜尋、統計與觀看。
照片是內容，網站則是我整理、展示與保存照片的方法。
而且很多功能，往往不是一開始就想好，而是網站真的用了一段時間之後才發現：「原來這裡還少了一步。」像是 Tag 為什麼要跨相簿、手機版為什麼不能只是桌機版縮小、熱門照片為什麼不能每看一次就寫硬碟，甚至連「像 Facebook 一樣看看往年今天拍過什麼」這種看似簡單的功能，做到幾千張照片之後也會遇到新的問題。
這篇文章想分享的不是「自己寫一定比 WordPress 好」，而是當一個攝影網站從作品集慢慢變成長期使用的照片資料庫之後，我為什麼最後選擇走向自架與自行開發。
目錄
WordPress 能不能做攝影相簿？當然可以
如果問題只是「WordPress 能不能拿來做攝影網站？」答案其實很簡單：當然可以，而且做得很好。
很多攝影師、婚攝工作室與旅遊部落格都在使用 WordPress。它不只可以管理文章和照片，也能透過外掛加入相簿、燈箱、瀑布流、浮水印、密碼保護、客戶選片與購物等功能。
如果目標只是快速建立作品集，WordPress 幾乎一定比從零開始寫網站更省時間，教學與現成資源也更多。
所以，我最後選擇自己開發，並不是因為 WordPress 不好，而是我的需求逐漸變得很個人。
尤其當網站放在自己的 Synology NAS 上之後，我開始在意很多一般相簿外掛不一定會替我處理的事情：
- 照片匯入後要產生哪些尺寸？
- 首頁究竟該載入多大的圖片？
- 訪客切換下一張時，要不要預先載入？
- 哪些瀏覽是真的訪客，哪些只是搜尋引擎或社群預覽？
- 搜尋要依照相簿、國家、城市、地點，還是主題？
- 怎麼減少 NAS 硬碟與網路不必要的負擔？
當每一項需求都要另外找外掛，再確認不同外掛能不能共存時，我開始覺得：與其一直把不同功能拼在一起，不如自己掌握整個流程。
我不只想把照片排成一格一格
一般相簿網站最基本的任務很單純：顯示封面、相簿名稱，再把照片排好。
但我希望每張照片都不只是「一張圖」。
我想保留拍攝日期、相機、鏡頭、焦距、光圈、地點與座標，讓訪客除了按照一次旅行瀏覽相簿，也可以從國家、城市、拍攝地點與照片主題重新探索。
聽起來只是多幾個欄位，實際上卻會一路影響照片頁的導覽。訪客從相簿進來、從地圖進來、從搜尋結果進來，甚至從某個主題進來，看到的雖然是同一張照片，但「下一張」究竟應該接到哪裡，其實可能完全不同。
我就曾遇過一個很典型的錯誤：照片已經切換到另一個相簿，但上方分類仍然停留在第一張照片的資訊。
攝影網站真正困難的地方，不是把圖片顯示出來，而是當訪客正在看某一張照片時，頁面上的每一項資訊都必須同時指向同一張照片。
旅行是縱向的，Tag 則把照片橫向串起來
相簿通常是按照旅程整理的。一次瑞士旅行、一次義大利旅行、一次台灣高山旅行，各自有自己的時間與故事。
但看照片的人，不一定永遠只想沿著「一次旅行」這條路走到底。
例如我在不同年份、不同國家都拍過教堂。如果只能從相簿瀏覽，那法國的教堂永遠留在法國相簿，義大利的教堂留在義大利相簿，下一次旅程裡的教堂又被分到另一個地方。
所以我後來加入 Tag，真正想解決的就是這件事。
當一張照片被標記為「教堂」，訪客看完義大利的一座教堂後，可以繼續看到法國、奧地利、日本，甚至其他旅程中的教堂。相同概念也可以套用在「山岳」、「湖泊」、「夕陽」、「櫻花」、「夜景」等主題。
相簿保存的是一次旅程的脈絡，Tag 則讓不同旅程裡相似的照片重新相遇。
這也是我後來愈來愈重視 Tag 的原因。它不是替照片多貼幾個標籤，而是重新建立整個網站的第二條導覽方式。
從程式角度來看，這又帶來新的麻煩：當訪客從「教堂」主題開始瀏覽，按下一張時可能已經跨到另一個相簿。網站除了換照片，還要同步更新照片標題、相簿名稱、網址、返回按鈕與導覽文字，否則就會出現「照片已經到法國，上方還寫義大利」這類不一致的情況。
手機版不是把桌機版縮小而已
一開始做響應式網站時，很容易以為只要把桌機版縮小，就叫做手機版。
實際使用之後，我很快發現不是這樣。
桌機有大螢幕、有滑鼠，照片可以一次看到更多資訊，篩選列也有足夠空間橫向排開；手機卻是直向螢幕、手指操作，而且很多人是在行動網路下看照片。
因此我後來不只調整字體大小，而是讓兩種裝置在細節上採取不同策略：
- 桌機和平板、手機分別調整首頁 Hero 的高度、主標位置與留白。
- 手機版搜尋列、統計區與導覽元件重新排列，避免窄螢幕擠在一起。
- 篩選頁籤在桌機可用滑鼠拖曳，手機則保留原生左右滑動。
- 相簿標題在手機窄版會自動換行，不讓「返回」按鈕和相簿名稱互相搶空間。
- 相簿照片列表刻意使用較小的縮圖，避免 Retina 手機因高解析螢幕反而載入過大的照片。
- 單張照片頁則可以讓桌機載入較高解析版本，手機使用適合行動網路的尺寸。
這讓我對「響應式設計」的理解也改變了。
真正的手機版不是把桌機版縮成 50%，而是重新問一次：在這個螢幕、這種操作方式與這種網路環境下，什麼資訊最重要？
沉浸式觀看，反過來改變了首頁封面的設計
攝影網站和一般資訊網站有一個很大的不同：照片本身就應該是主角。
所以我後來加入更沉浸式的大圖觀看方式。當照片放大、進入滿版或全螢幕後，選單、按鈕與文字都應該退到第二線，讓視線先停在照片上。
有趣的是，這個想法後來反過來影響了首頁。
首頁原本可以放很多標題、副標、說明與裝飾，但當我愈來愈習慣讓照片自己說話之後，就開始覺得首頁封面上的文字也不應該太搶戲。
於是封面的設計一路調整：Hero 高度重新分配、桌機與手機分別微調主標位置，原本的副標也被拿掉，讓封面照片有更完整的觀看空間；首頁相簿的呈現方式則保留小卡、封面與清單等不同模式，最後選擇比較適合快速瀏覽的方式作為預設。
這段修改過程讓我發現，UI 設計其實不是一個頁面一個頁面各自決定。
當你決定「照片應該是主角」之後，這個原則會一路影響照片頁、首頁封面、按鈕位置，甚至哪些文字乾脆不要出現。
同一張照片，不能在所有地方都使用原始檔
現在的相機與手機可以拍出非常大的照片，單張十幾 MB 甚至更大並不稀奇。
如果首頁只需要一張小小的封面，網站卻把完整原圖傳給訪客，結果就是開啟速度變慢、手機流量增加，NAS 的上傳頻寬也白白被吃掉。
所以照片匯入網站時，我會先準備不同尺寸的版本：
- 相簿列表使用小縮圖
- 封面使用適合卡片顯示的尺寸
- 照片頁載入較清楚的版本
- 只有真正需要放大時，才讀取更大的照片
切換下一張時，我也希望網站能先在背景把照片準備好，等圖片載入完成後再切換，減少黑畫面，或是模糊圖片突然變清楚的閃爍。
但預先載入也不是越多越好。如果訪客只想看一張照片，手機卻已經在背景下載後面五、六張大圖，那只是把「速度最佳化」變成「流量浪費」。
對攝影網站來說，畫質越高不一定越好；真正重要的是在清楚、速度與流量之間找到平衡。
像 Facebook「往年今日」一樣重新遇見舊照片
照片網站如果只是把照片按照年份與相簿收藏起來，很容易變成一個「存進去之後就很少再翻」的地方。
所以我後來很喜歡一個概念：像 Facebook 的「過去的這一天」一樣，在今天重新看到不同年份同一天拍過的照片。
它讓相簿不再只是依靠使用者主動搜尋，而是每天都可能重新遇見一段過去的旅行。
但這個功能真正做起來後，又遇到很典型的「資料量問題」。
有些日期可能只有兩、三張照片，全部展開很自然；有些日期卻因為剛好是旅行中的某一天，累積多個年份後可能一次出現很多張。如果一進首頁就把所有「往年今日」照片全部展開，這個原本只是回憶的小區塊反而會把整個首頁拉得很長。
所以後來我替它加入數量規則：
- 照片數量不多時，可以直接展開全部。
- 超過 20 張時，先顯示前 20 張。
- 真的想繼續看的人，再使用「更多」展開後面的照片。
這看起來只是「多一個更多按鈕」，但背後其實是另一個我反覆遇到的設計原則：
少量資料時最直覺的介面，到了幾千張照片的規模，往往就不再適合。
網站明明更新了，為什麼 Chrome 還顯示舊版？
自架網站後，我遇過一個非常惱人的情況：伺服器明明已經換上新版，Chrome 打開後卻還是看到舊按鈕、舊版面，甚至舊資料。
最簡單的做法當然是叫訪客按強制重新整理，或者清除瀏覽器快取。
但如果網站每次更新都要教訪客「請先 Ctrl + F5」，那顯然不是正常的更新流程。
後來我把不同檔案分開看待。容易變動的內容，例如頁面資料，需要經常向伺服器確認有沒有更新；程式與樣式檔則可以在網址裡加入版本資訊。
例如網站版本從 7.85.3 更新到 7.85.4，瀏覽器看到的資源網址也跟著改變，它自然就會下載新版，不必要求使用者手動清除快取。
反過來，照片通常不會今天上傳、明天又換成另一張內容完全不同的檔案，因此大型圖片反而可以放心快取久一點，讓再次瀏覽時更快。
快取不是「開」或「關」兩種選擇，而是先分辨哪些東西會改、哪些東西幾乎不會改。
熱門照片，可能根本不是人選出來的
網站加入「熱門相簿」與「熱門照片」之後，我一開始以為瀏覽次數就是訪客喜好的直接反映。
後來才發現，網路上會打開頁面的不只有人。搜尋引擎、社群網站的連結預覽、網站檢查工具，以及各種自動程式，都可能讀取公開頁面。
如果全部照單全收，熱門排行最後顯示的可能不是「大家最喜歡的照片」，而是「最常被機器讀取的照片」。
所以後來我的統計功能加入了幾層判斷：
- 已知搜尋引擎與自動工具不列入熱門排行
- 社群網站為了產生連結預覽而讀取頁面時不計數
- 同一瀏覽器短時間重複查看同一相簿或照片，不重複累加
- 短時間大量送出統計請求時進行限制
這些自動程式仍然可以正常讀取公開網站，因此不會因為「不計入熱門排行」就阻止搜尋引擎收錄。
當然，這類辨識不可能百分之百準確。有些自動程式會偽裝成一般瀏覽器，但至少可以排除大部分明顯不是人類的瀏覽。
少寫一次硬碟，也是一種網站最佳化
我的網站跑在 Synology NAS 上，所以「網站效能」不只代表頁面開得快不快，也包括一件很現實的事：能不能不要為了一個很小的統計，就一直把硬碟叫醒。
如果每位訪客每看一張照片，系統就立即把「瀏覽次數 +1」寫進硬碟，少量使用時可能沒什麼感覺，但請求增加後，硬碟就會不斷出現零碎寫入。
更麻煩的是，NAS 原本可能已經進入休眠，結果只是有人打開一張照片，就因為統計資料要寫回檔案而把硬碟喚醒。
所以後來我把熱門相簿與熱門照片的統計先暫存在記憶體裡，再定期批次寫回，而不是每一次瀏覽都立即落盤。同一個瀏覽器在短時間內重複看同一張照片，也不必一直增加瀏覽數；真正的點擊互動則仍然保留。
網站總流量的統計也盡量只保存真正需要的摘要，例如每日總量以及不同圖片尺寸的流量類型，而不是為每一張照片、每一個檔案、每一個 IP 都留下大量明細。
這有點像每收到一封信就立刻跑一趟郵局，改成先把信放在桌上，累積一批再一起寄出。
管理者打開熱門排行時，系統可以把尚未正式寫入的統計一起算進來，因此畫面上看起來仍然接近即時。
這種做法當然不適合銀行交易或不能遺失的重要資料。但熱門照片排行不一樣：即使伺服器意外關機而少掉最近一小段統計，通常也比讓 NAS 硬碟長時間為了零碎計數不停工作更可以接受。
這也是自架 NAS 之後我才真正開始在意的事情：
最佳化不一定是讓 CPU 跑得更快。有時候，少做一次沒有必要的硬碟寫入，就是最有價值的最佳化。
我的網站其實同時用了兩種做法
有些網站會先在伺服器把完整頁面做好，再交給瀏覽器；也有些網站只先傳一個基本框架，等瀏覽器取得資料後，再把畫面組合起來。
我的攝影網站其實同時使用這兩種思路。
第一次打開相簿或照片頁時，伺服器會先準備好頁面標題、照片說明、分享資訊，以及搜尋引擎需要理解的內容。
這樣 Google 或社群網站讀取頁面時，不需要等瀏覽器執行一大堆程式，才能知道這一頁究竟在介紹什麼。
真正進入頁面之後，切換照片、按讚、留言與滿版瀏覽則交給瀏覽器處理，如此一來，訪客不必每按一次「下一張」就重新載入整個頁面。
對訪客來說，第一次進入時內容完整，之後切換照片也很流暢；對開發者來說，真正麻煩的是伺服器與瀏覽器兩邊的資料必須一直保持一致。
自己寫網站，真的比較省事嗎？
如果只計算「把網站做出來」所需要的時間，那答案很明確：不會。自己開發一定比 WordPress 麻煩。
WordPress 安裝完成後，很快就能選佈景主題、建立頁面與上傳照片；自己開發卻要處理登入、相簿管理、照片轉換、搜尋、留言、安全性、備份、快取與搜尋引擎設定。
但自己開發最大的好處，也恰好就在這裡：每一個功能都可以依照自己的使用方式調整。
我不需要為了顯示一個地點，就安裝一整套龐大的外掛；也不用讓照片資訊散落在不同外掛各自建立的資料結構裡。
當相簿改名時，我可以一起處理網址、照片資料夾、封面與熱門統計；網站速度變慢時，也能直接回頭檢查是哪一段流程造成，而不是先猜「是不是某個外掛又衝突了？」
AI 時代，為什麼自架網站仍然值得分享？
所以，這不是一篇勸大家放棄 WordPress 的文章。
如果你的目標是快速建立攝影作品集、偶爾更新照片，而且不想長期維護程式，WordPress 或其他現成服務通常更合適。
我的選擇比較像是把網站本身，也當成另一件長期作品。
照片是作品，程式則是我決定這些照片要如何被整理、被找到、被觀看的方式。
從一開始只能顯示相簿，到後來慢慢加入地圖、Tag 主題、不同圖片尺寸、手機版介面、沉浸式瀏覽、往年今日、搜尋、熱門排行與搜尋引擎最佳化，每一次修改幾乎都不是「突然想到一個炫技功能」，而是實際使用之後發現：「這裡還可以更順一點。」
AI 現在確實可以幫忙寫程式、檢查錯誤、比較做法，也大幅降低自行開發網站的門檻。
但 AI 無法替我決定照片應該怎麼被探索、Tag 要怎麼把不同旅程串起來、手機版哪些資訊該先顯示、哪些瀏覽應該算進熱門排行、NAS 資源應該如何取捨，也無法代替網站真正上線後累積的使用經驗。
也正因如此，我覺得在 AI 時代，自架網站反而更值得分享。
因為真正有價值的，不只是「AI 幫我把程式寫出來」，而是我為什麼要這樣設計，以及實際用了之後，又發現了什麼。
常見問題
WordPress 適合做攝影網站嗎？
適合。若需求是作品集、相簿展示、部落格或客戶選片，WordPress 已有大量成熟的佈景主題與外掛，可以很快完成網站。
自己在 Synology NAS 上架攝影網站有什麼優點？
最大的優點是可以完全依照自己的照片管理方式設計，包括縮圖尺寸、搜尋、Tag 主題、手機版介面、瀏覽統計、快取策略與 NAS 資源使用方式，不必受限於現成外掛的資料結構。
為什麼攝影網站不應該全部使用原始照片？
因為原圖通常很大。首頁縮圖、相簿封面與一般照片瀏覽其實需要不同尺寸，如果全部傳原始檔，會增加載入時間、手機流量與 NAS 上傳頻寬。
Tag 對照片網站有什麼作用？
相簿通常按照一次旅行整理，Tag 則能把不同相簿裡相同主題的照片重新串在一起。例如從一張教堂照片出發，可以繼續探索其他國家與其他年份拍攝的教堂，而不必受單一相簿限制。
為什麼熱門照片統計要先放在記憶體？
因為每一次瀏覽都立刻寫入硬碟，會造成大量零碎 I/O，甚至讓休眠中的 NAS 硬碟被頻繁喚醒。對熱門排行這類非關鍵資料，先暫存再批次寫入通常更適合。
AI 已經可以寫網站，還需要自己懂網站架構嗎？
仍然需要。AI 可以加快寫程式、除錯與比較方案的速度，但照片如何整理、快取如何設計、手機版怎麼取捨、統計哪些瀏覽、NAS 資源如何分配，仍然要根據網站真正的使用方式決定。
延伸閱讀：攝影網站建置學習順序
這篇文章已有 36 次瀏覽
發佈留言