08/06 今天處理AI自己捅出來的效能問題

必須說，現在AI越來越像是人，所以寫出來的程式，也是有BUG的，但至少沒有一些寫程式上的幻覺，這至少對開發上是一件好事情。但這也要考驗開發者自己的除錯能力。

昨天有旅人朋友在LINE社群反應網站進去怪怪的，但我打開是沒問題的，所以就得查案子了，首先就是用CLOUDFLARE的工具看一下網頁載入的狀況，的確非常不妙，因為載入時間太長了。

既然是AI寫的，還是得讓AI查，因為是前端造成的問題，所以我先鎖定的是幾個我自己寫，然後會大量干涉前端的外掛，以下就是請AI寫的白話文版本的結案報告。

發生了什麼問題

白海豚颱風帶來大量讀者，把網站平常看不出來的四個毛病同時放大了。 四個毛病彼此獨立，但都指向同一件事：「看起來有在運作」不等於「真的有在運作」。

2026-08-05，白海豚颱風接近沖繩，/airportweather/（機場氣象紅綠燈）的流量暴增。 讀者反映網頁打開很慢，實測發現「最大內容繪製時間」（LCP，簡單說就是畫面上最大的那張圖或那段文字要多久才出現）長到不能接受。

於是開始一項一項拆。結果拆出了四個問題。

廣告心跳問題

網站上有一個功能會統計「廣告被看到幾次」。原本的寫法是：每出現一個廣告位，就立刻回報一次。

聽起來合理，但 /airportweather/ 這一頁有 33 個廣告位。所以讀者只是「打開一個網頁」，網站內部就對自己發出了 28 次回報請求。

問題在於，這種回報完全繞過快取。快取就像便利商店的架上商品，拿了就走；沒有快取則是每次都要現點現做。所以那 28 次回報，等於把整個 WordPress 重新開機 28 次，還順便對資料庫的同一格數字做了 56 次讀寫。

更糟的是，所有讀者都在搶著改同一格數字。就像 100 個人同時要在同一張紙上把「100」改成「101」——

• 有人會漏算（兩個人都看到 100，都寫回 101，實際上該是 102）
• 大家還得排隊等前一個人寫完，這個隊伍長到連跟廣告無關的頁面都被卡住

修正方式

1. 改成累積後一次送出：讀者瀏覽期間先把數字記在腦子裡（瀏覽器記憶體），離開前才一次回報。28 次變成 1 次，減少 96%。
2. 統計改存專屬的資料表：不再跟所有人搶同一格。新做法用資料庫層級的「原子累加」，講白話就是由資料庫自己負責加法，不需要「讀出來、加一、寫回去」這三個步驟，所以不會漏算、也不會卡到別人。

手機讀者被迫下載電腦尺寸的大圖

同一張照片，網站其實可以準備好幾種尺寸：小的給手機、大的給桌機。瀏覽器會自己挑最適合的那一張。

但實測發現：

• 文章列表的縮圖，畫面上只顯示 483 像素寬，卻下載了 1366 像素的原圖（多載了 8 倍的資料量）
• 側邊欄的小圖，顯示 108 像素，下載 794 像素（多載了 54 倍）

用生活比喻：你只需要一張明信片，卻每次都寄一幅海報過來。網路好的時候感覺不出來，颱風天大家一起擠進來的時候就爆了。原因是尺寸階梯不夠用——中間缺了一階，瀏覽器找不到合適的，只好退回去拿原圖。

修正方式

1. 補上缺的那一階：新增 jct-large（1200 像素）。這個數字不是隨便挑的，是照著實際讀者的螢幕資料推算出來的（現在主流手機是 390~440 像素寬、螢幕密度 3 倍，所以需要約 1200 像素的圖才夠清晰）。
2. 做了一個「縮圖產生精靈」：媒體庫有幾萬張圖，要全部重新產生縮圖是個大工程，而且有先後順序、中間漏一步就前功盡棄。所以做成十個步驟的頁面，一步一顆按鈕，前一步沒做完就不給按下一步。
3. 加上主機負載監控：跑批次很吃 CPU，怕拖垮網站。所以在畫面上直接顯示主機忙碌程度，並依實測結果自動推薦「跑多快比較安全」。
4. 後來又改成「只補缺的、不重做已有的」：原本每張圖的所有尺寸都重新產生一遍，但這次其實只缺一種尺寸。改成智慧模式後，已經存在的尺寸直接跳過，速度快非常多。

縮圖做好了，但網頁上還是只出現原圖

縮圖都產生好了，網頁卻依然只寫著原圖的網址——等於前面兩週的工都白做。拿到整頁的原始碼之後，把頁面上 101 張圖片全部拆開比對，發現它們其實來自三條完全不同的產生管道：

判斷的關鍵很有趣：WordPress 在處理圖片時，會順手在標籤最前面加一個 decoding="async" 的記號。有這個記號、而且在最前面的，就代表 WordPress 有經手過。側邊欄那張有記號，另外兩群沒有。所以結論很明確：不是功能壞掉，是那些圖根本沒被送到會處理它們的地方。而且側邊欄那張圖還順便證明了一件事，它的設定值正是本外掛寫進去的原文，代表程式本身完全正常。

兩個各自獨立的原因

原因 A：處理順序太早（這是原本的猜測，猜對了一半）WordPress 處理文章內容有固定的先後順序，可以想成生產線：

第 9 站   把「區塊」展開成真正的 HTML
第 11 站  把「短代碼」展開成真正的 HTML
第 12 站  ← WordPress 在這裡才處理圖片

原本的程式站在第 9 站。問題是短代碼要到第 11 站才會變成圖片，所以站在第 9 站的人根本還沒看到那些圖。已改成第 11 站。

原因 B：圖片網址跟資料庫對不起來（這個跟順序完全無關）

WordPress 判斷「這張圖有沒有其他尺寸」的方式，是拿資料庫記錄的檔案路徑，去比對網頁上的圖片網址。對得上才處理，對不上就整個放棄，而且不會有任何錯誤訊息。

你的圖片放在 Cloudflare R2，實際網址是：

https://imagecdn.jesselin.com/2024/05/28010636/weather.webp
                                       ^^^^^^^^^ 多了這一段

資料庫記的卻是 2024/05/weather.webp。中間多了一段時間戳資料夾，所以永遠對不上。更麻煩的是，時間軸那 60 幾張圖和文章的精選圖片，走的是完全不經過文章內容的另一條管道。這條路無論把處理順序調到多後面都沒有用——它根本不在那條生產線上。以張數來說，這一群才是拖慢速度的大宗。

修正方式

1. 處理順序從第 9 站移到第 11 站
2. 新增一道很後面才執行的補網（第 9999 站），等所有元件都輸出完畢才掃描一次，把漏掉的補上
3. 針對「不經過文章內容」那條管道，另外掛一道專屬的補網
4. 改用圖片的實際網址去組裝，不再依賴資料庫路徑比對——直接繞開 R2 網址對不上的問題

補上去的尺寸會自動排除「裁切過的方形縮圖」（因為長寬比不同，硬塞進去會讓圖片變形），而且候選少於 2 個就不動作，寧可維持原樣也不要弄出一半殘的結果。

廣告位置卡在「Advertisement Loading…」的灰盒子

前台廣告的位置變成一個灰底方塊，中間寫著「Advertisement Loading…」，而且永遠不會消失。第一直覺會以為是 Google 沒有廣告可放。但那個灰盒子是我們自己畫的——是廣告還沒載入時的佔位圖（業界叫「骨架屏」），本來應該在廣告載入後由程式自己拿掉。它一直留著，只代表一件事：負責「拿掉它」的那段程式，根本沒有被執行到。數一數整頁：28 個廣告位，只有第 1 個成功，其他 27 個原封不動。

三個疊在一起的原因

原因 A：後台的「延遲載入」被關掉了

程式對廣告有兩種處理路線：

• A 路線（前 2 個廣告）：立刻載入
• B 路線（第 3 個以後）：等讀者捲到附近才載入

B 路線做得很完整，有監看機制、有逾時保險。但 A 路線只有「一口氣全部載入」。

後台把「延遲載入」關掉之後，28 個廣告全部被推到 A 路線——那條沒有任何保險的路。

所以這不是程式退化，是設定改變讓程式走進了一條沒鋪柏油的路。

原因 B：唯一的保險寫在錯的地方

程式裡確實有一道「3 秒後強制載入」的保險。但它被寫在這樣的位置：

先處理 A 路線的廣告
檢查有沒有 B 路線的廣告 → 沒有的話，直接結束
（保險寫在這一行的後面）    ← 永遠執行不到

而且那道保險查的還是 B 路線的廣告。所以就算執行到了，也抓不到 A 路線的任何一個。

等於 A 路線完全裸奔，卡住就永遠卡住。

原因 C：28 個廣告共用一條繩子，第一個絆倒全部跌

原本的寫法是把 28 個廣告放進同一個迴圈，中間沒有任何防護。只要其中一個出錯，整個迴圈立刻中斷，後面的一個都不會被處理。

「只有第 1 個成功、第 2 個之後原封不動」正是這個形狀。

原因 D（很可能才是最初的元兇）：改了程式，但讀者拿到的還是舊版

網頁載入 JS 檔案時，網址後面會帶一個版本號：

jct-ad-inserter.js?ver=1.1.0

這個版本號的用途是告訴快取「檔案換新的了，別再給舊的」。

但它是寫死的。檔案本身早就改到 1.1.2 了，版本號卻還停在 1.1.0。結果就是 LiteSpeed、Cloudflare、讀者的瀏覽器全部繼續餵舊檔案——不管把程式改成什麼樣子，讀者都看不到。

而「由程式自動拿掉灰盒子」這個功能，正好是後來的版本才加的。所以：新版 PHP 畫出了灰盒子，舊版 JS 卻不知道要拿掉它。 現象完全吻合。

修正方式

1. 每個廣告獨立包一層防護：一個出錯只影響它自己，不會拖垮其他 27 個
2. 保險移到最前面無條件註冊，而且同時涵蓋 A、B 兩條路線
3. 新增 8 秒最終清場：到這時候還沒載入的，一律把灰盒子移掉、把佔位高度收掉——寧可留白，也不要卡一個假的 Loading
4. 版本號改用「檔案的最後修改時間」：以後每次存檔，版本號自動變動，快取自動失效，不會再發生「改了沒反應」

處理完畢

效能上有一定的修復，但因為颱風頁面本身的長度就很長，所以會造成載入時間比較久。

小技巧

請在CHROME安裝CLAUDE外掛，這樣除錯更方便。