沒穿方服

使用 cloudflare/next-on-pages 的專案 feeders，上線快 5 個月了。

功能需求不複雜，所以想找低價、好開發、又能達到足夠品質的方案。但實際做下去，開發的不便還是有感，也在網站乏人問津的狀況下就超出了免費額度。

首先談 Next.js 14 App router

我算第一次用，小小意外：

• 點連結後有一段無反應的時間

  在 server 初始回應之前，瀏覽器是全無反應的，也就是比點擊原生 <a> 回饋更差，這個我很難接受。

  參考 Next.js App Router navigation indicator and the delay after onclick - DEV Community。

  文章有一些對策，我後來乾脆裝一個進度條元件，它今年轉生成新專案 BProgress。 這種 UI 本是多此一舉，現在為了遮醜不得不用。

• 使用 hash 的客戶端導覽 (client side navigation) 沒有處理

  一樣是基於 server 為重的設計，Next.js 對於使用 URL hash（#xxx 部分）做的導覽沒有理會。它不是一個 route，處理上一頁、下一頁時也會漏掉而出問題。框架和原生功能打架。

  類似這個 issue 說的情形：#56112: Server rendered routes with hashes do not work with browser back/forward navigation。

  解法是自己監測 hashchange 做反應；另外也要監測 popstate 事件（會發生於上一頁、下一頁），自己比對 URL pathname，需要時補做 router navigation，見 commit bootleq/feeders@c211ff7。

然後是 next-on-pages

• Runtime 與 API、產品線（D1、R2 等）的先天限制

  next-on-pages 只能用 edge runtime，一些 API 也跟 Next.js 的規格不太一樣。

  實際障礙例如不能做 ISR、考慮 cache 時要重新認識當時的 cache API（現在看，又不同了）。

  再說到 D1 等 edge 特化的產品（註：沒有強迫一定要用），有些限制像是不支援 transaction 如果在遇到時才發現，恐怕真的無解。

  註：後來出現了 OpenNext 可以在 worker 使用 node.js runtime。

• worker 限額

  壓縮後超過 1MB 就會超出免費額度（worker 部分，靜態檔不算），我一開始沒注意到，後來要減肥就來不及了（我真的努力過）。
  後來有人提報 1MB 連 starter 專案都不夠用，就在 11 月放寬到 3MB 了。

  CPU time 免費額度只有 10ms，付費則有 30s 也差太多了吧。
  看一些討論是只要有密碼學運算、解析 DOM、載入較大的資料，隨便就會超過 10ms。 我的 app 有做身分認證和載入大顆 JSON，峰值遠遠超過 10ms，或許努力調校可以壓下去，但要長期活在這條線下實在削足適履。

• git push 部署和 wrangler 上傳只能二選一

  假如想先用 wrangler pages deploy 指令部署，後期再換成跟 github 整合，照文件說法是只能開新的專案。
  Doc: Git integration | Direct Upload。

• 突然不能 deploy 的事件

  曾經發生過 vercel 上游變動，Pages 專案就突然無法 build，也就無法部署新版本的事件，issue #908。
  看 PR #909 勉強可以算 vercel 的問題，但確實需要等 cloudflare 這邊救火。

結論

速度和費用表現是真的不錯（雖然無法免費），但底層相容性的東西會帶來多餘工作，也有心理負擔。 適合真正 edge 特化的輕量功能，或小專案以積極冒險的心態進入。

去年十月普及的瀏覽器 text fragment（文字片段）功能，用 #:~:text=文字寫法深度連結到網頁特定位置，很實用，即使網站有轉址也能通，例如 立法院法律條文 https://www.ly.gov.tw/Pages/ashx/LawRedirect.ashx?CODE=03134#:~:text=中華民國104年2月4日公布
點進去會發現網址變了，但還是能把左邊欄「中華民國104年2月4日公布」這段字標亮。

:~: 規格： web.dev、 MDN

不過也發現有些網站用上去沒效果，有些自己寫的網頁竟然也不行！
要是被人發現網頁不友善卻渾然不知，那多丟臉啊。

簡單記一些踩點

• 目標文字在初次 render 就要出現，所以需要 SSR。
  如果是轉圈圈載入資料再顯示的架構大概就沒救了。

• 顯示之後重繪也會清掉效果，例如 react 能用卻沒用 useMemo 碰上多餘重繪，這關就不過。

• 主要內容的 HTML 節點最好提早出現，例如我有一些主文放在 <dialog>，原始碼卻放在靠近底部 </body> 的位置，這樣如果目標文字也出現在其他地方就會有問題，會優先抓到別處（較不重要）。

• 真的改不了的時候，想換條路自己解析網址再模擬「尋找、捲動、標亮」也做不到，因為安全隱私考量，# 開始的部分會被瀏覽器拆掉，不會暴露給程式，例如 location.href 就抓不到。

• 操作瀏覽器寫自動測試時，我找不到方法讓 headless chrome 啟用這個功能，最後只能用頭跑，或改用 Firefox。

• 雖然可以用 CSS ::target-text 改標亮部分的樣式，但實測只能動前景、背景色，也不能用漸層之類的值。
  那要改成怎樣才符合使用者預期？我想一般答案是先不要改吧。