Astro 7.4 在 10 月 15 日推出：astro build --timings 會列出建置各階段、Vite 外掛、Markdown、圖片與每一頁的耗時；預先產生與即時渲染的頁面可以用不同的圖片服務；自組進入點多了 notFound()；字型設定不合會發出警告；另有實驗性的多執行緒預先渲染與自訂轉址頁。給官網、內容網站與行銷頁團隊的升級筆記。
每個做網站的團隊，都經歷過這種對話：
「怎麼部署要等這麼久？」 「建置比較慢。」 「哪裡慢？」 「……整體都慢？」
這就像問醫生哪裡痛，你只回答「全身」。醫生很難幫你，工程師也很難幫自己。
10 月 15 日，Astro 團隊的 Matthew Phillips 發布了 Astro 7.4。這一版的主角很務實：一個能告訴你「建置時間到底花在哪」的 --timings 參數，外加幾個讓官網、部落格、行銷頁團隊少踩雷的改進。
先複習：Astro 是什麼？
Astro 是一個以內容為主的網站框架，很適合企業官網、品牌形象站、部落格、文件站這類「大部分頁面可以事先產生」的網站。它預設輸出靜態 HTML，需要互動的區塊才載入 JavaScript；也能搭配 React、Vue、Svelte 等元件，並部署到 Cloudflare、Vercel、Netlify 或自己的伺服器。
重點一：astro build --timings，建置時間明細表
只要加上一個參數：
astro build --timings
建置完成後，Astro 會列出時間都花去哪：建置各階段、Vite 外掛、Markdown 處理與語法上色、頁面渲染、圖片處理與整合套件，還有「最慢的頁面」排行榜。
官方文章示範了一個很常見的情境：在部落格範本的文章版型裡加一個留言元件，先抓留言，再為每一則留言抓留言者的個人資料。程式碼看起來沒問題，但個人資料要等留言回來才能開始抓，每一頁都在連續等兩次網路往返。
報表一跑就很清楚：
- 「產生頁面」佔了整體建置時間約 81%，而且幾乎都花在元件內部，不是 Astro 自己的流程。
- 最慢的頁面都是使用文章版型的那幾頁，
/blog和/rss.xml則只要幾毫秒。
線索直接指向版型裡的某個元件。改成用 Promise.all() 一次抓完留言和所有個人資料，再往下傳給每則留言之後，頁面產生時間從 2.10 秒降到 1.13 秒，每篇文章頁的時間也減半。
官方也建議：在嘗試平行預先渲染或增量建置這類加速手段之前，先用 --timings 確認到底是哪一段慢，再對症下藥。
重點二：建置時和執行時，可以用不同的圖片服務
一個網站常常同時有兩種頁面：事先產生好的靜態頁，以及每次請求才即時渲染的頁面。兩者對圖片處理的需求很不一樣：
- 建置時有充足的時間和完整的 Node.js 環境，用 Sharp 這類本機最佳化工具很適合。
- 即時渲染的頁面跑在伺服器或邊緣節點，很多環境跑不了 Sharp，交給圖片 CDN 通常比較好。
以前只能二選一，或讓部署轉接器幫你決定。Astro 7.4 起，image.service 可以分別設定 build 與 runtime：
// astro.config.mjs
export default defineConfig({
image: {
service: {
build: { entrypoint: 'astro/assets/services/sharp' },
runtime: { entrypoint: 'my-image-cdn-service' },
},
},
});
build 服務負責預先產生頁面的圖片（開發模式也用它），runtime 服務負責即時渲染頁面與正式環境的圖片端點。只設一個服務的舊寫法照樣能用。官方也重寫了建置時追蹤圖片的方式，@astrojs/cloudflare 現在會用和其他轉接器相同的流程處理預先產生頁面的圖片。
重點三：自己組伺服器進入點，也能顯示自訂 404
如果你用 astro/fetch 或 astro/hono 的組合式處理器自己拼伺服器進入點，過去只用 pages()、沒用整合式的 astro() 時，找不到路由的請求會回傳空白 404，而不是你精心設計的 404.astro。7.4 新增 notFound()，放在 pages() 前面即可。
重點四：字型設定不合，會先提醒你
很多人都遇過：設定了某個字重或子集，結果字型家族根本沒有，直到上線看到字長得怪怪的才發現。現在字型供應者可以回報實際提供的字重、樣式、子集與格式，設定不符時 Astro 會發出警告。內建供應者都已支援；自訂供應者在 Astro 7 是選用，官方說明 Astro 8 會改成必要。
兩個實驗功能：平行預先渲染、自訂轉址頁
平行預先渲染（experimental.parallelPrerender）：過去靜態頁雖然會並行渲染，但都在同一個執行緒上，大型網站再多核心也只用到一顆。開啟後，Astro 會用 Node.js worker threads 分散渲染，預設使用「全部核心減一」。每個 worker 都會增加記憶體用量，若建置記憶體不足或沒變快，可以調低 workers。如果轉接器有自己的預先渲染方式，這個設定不會生效；官方轉接器中只有 @astrojs/cloudflare 屬於這種情況。
自訂轉址頁（experimental.redirectPage）：靜態網站沒有伺服器可以送 HTTP 轉址標頭，Astro 會為每個轉址產生一個用 meta refresh 跳轉的小頁面，但樣式與文字以前都是固定的。開啟後可以建立 src/pages/3xx.astro，自己設計品牌化、在地化的轉址頁。注意：頁面裡一定要輸出指向目標網址的 meta refresh，否則 Astro 會在建置時警告。
升級前的檢查清單
- 先確認 Node.js 版本：Astro 與官方整合套件的最低需求提高到 22.22.0。CI、部署平台和同事的電腦都要檢查。
- 轉接器一起升：
@astrojs/cloudflare與@astrojs/markdoc的新版需要astro@^7.4.0，要和 Astro 一起升級。 - 有寫整合套件或自訂預先渲染器的團隊：注意
config.image.service的結構變化，以及getStaticPaths()、render()回傳圖片中繼資料的新方式；舊寫法雖然還能跑，但已不建議使用，且那些頁面的圖片不會被產生。 - 官方建議用
npx @astrojs/upgrade自動升級。
什麼樣的網站最該看這一版？
- 頁面數多的內容網站：新聞、部落格、文件站、商品型錄，每次發文都要重新建置，建置時間直接影響「按下發布到上線」要等多久。
- 在 CI 上按分鐘計費的團隊：建置時間越長，每個月的 CI 帳單越長；先找出最慢的環節，比盲目升級機器划算。
- 混合靜態與即時渲染的網站：例如官網大多是靜態頁，但會員、預約或搜尋頁是即時渲染，新的圖片服務分流設定正好派上用場。
- 正在搬家或改版的網站：大量舊網址需要轉址時，自訂轉址頁能讓體驗更一致。
給網站業主與工作室的實務建議
- 把
--timings放進例行檢查：每次改版前後各跑一次，記下總時間與最慢頁面，建置時間異常變長時就有比較基準。 - 小心元件裡「排隊」的資料請求：官方範例的問題在很多網站都看得到。能一起抓的資料就一起抓，建置與頁面回應都會受益。
- 網站搬家時善用自訂轉址頁：改版常伴隨大量舊網址轉址，品牌化的轉址頁能讓使用者知道「頁面搬家了」，而不是看到一閃而過的空白頁。
- 圖片策略分開想：靜態頁在建置時最佳化、動態頁交給 CDN，兩邊各取所長。
你可能會問
Q：不升級會怎樣？
A：網站照樣能跑。這版多半是開發與維運體驗的改進，但若建置時間已經困擾團隊，--timings 很值得一試。
Q：平行預先渲染可以直接用在正式專案嗎？
A：它目前是實驗性功能，官方提醒要注意記憶體用量。建議先在測試分支打開，比較建置時間與記憶體再決定。
Q：自訂轉址頁對 SEO 有影響嗎？
A：官方範例在轉址頁加了 noindex，並由 meta refresh 完成跳轉。如果主機支援伺服器端轉址設定，仍可依需求搭配使用。
Q：我們的網站是用 React 做的，跟 Astro 有關嗎？
A：Astro 可以嵌入 React 元件，不少團隊用 Astro 做官網、行銷頁，再用 React 做互動區塊。
結語
Astro 7.4 沒有翻天覆地的新概念，但它解決了一個很真實的問題：讓「建置好慢」從一句抱怨，變成一張可以逐項處理的明細表。
找到慢的原因，往往比換更快的機器更有效。
來源：Astro 7.4（Matthew Phillips，Astro Blog，2026/10/15）。
延伸參考：Releases · withastro/astro（GitHub）。