2025年8月8日 星期五

靜態資源快取怎麼做?

前言

很難得一天發兩篇文,還都不是我的本業文(算了我也不是第一天不務正業

總之後端反應為什麼前端會重複下載靜態資源,請我去查(乾~這又關前端什麼事

我再度拿我的專案去問gemini-cli,他給我的檢查方式是看network,靜態資源檔的size,如果顯示為disk cache或memory cache,那就是正常快取,如果為容量,那就是沒有快取(我以為是看status301,問了才知道301是轉址,好在不是問維運不然一定被嗆爆

這邊有個要注意的點,注意network頁的disabled cache不要打勾,不然你永遠看不到快取(我就這樣犯傻浪費了些時間

以下這張圖就是有拿到快取


假設沒有快取,如果你想在nginx上設置,可以加上以下配置,時間可以自訂

location ~* \.(jpg|jpeg|gif|png|svg|ico|webp)$ {
# 快取有效期設為一天
expires 1d;
# 明確設定 Cache-Control 標頭
# public: 可被任何快取(包括 CDN 和代理伺服器)快取
# immutable: 告訴瀏覽器這個檔案內容絕對不會改變,不需要為了驗證而重新發送請求
add_header Cache-Control "public, max-age=86400, immutable";
# 可選:關閉這個 location 的存取日誌,減少 I/O
access_log off;
}

這樣應該就可以做到一天快取

小結

結果在我們站上,我把nginx設定拉掉,快取還是在啊,強烈懷疑那位後端把disabled cache打溝了,但我沒有證據......好拉快點讓我下班吧==

2025年8月7日 星期四

原來前端資源讀取阻塞是Http協議的問題

前言


圖片有點小,簡而言之他們說api載入速度慢是因為前面一堆東西要載阻塞了,請前端協助確認

原來loading組塞也規前端管,三更半夜收到這種消息想必正常人都要睡不好了!

好在我11點就調勿擾,且我已經睡了。珍惜生命,遠離手機,特別是三更半夜還有同事在加班的公司。

總之言歸正傳,我之前一直以為瀏覽器的升級讓資源載入不會阻塞,所以我壓根不用考慮這件事,所以我問一下ai獲得以下答案


A:1. (強烈建議) 啟用 HTTP/2 或 HTTP/3
這是解決此問題最現代、最有效的方法。
* 原理:HTTP/2 和 HTTP/3 支援「多路復用 (Multiplexing)」,允許在單一的 TCP 連線上同時處理多個請求,完全繞過了 HTTP/1.1 的隊頭阻塞 (Head-of-line blocking) 問題。
* 如何做:這需要在伺服器端進行設定。您需要與後端或維運團隊合作,在您的 Web 伺服器(如 Nginx, Apache)或 CDN 服務商上為 api.ktkdf.xyz (或 bb.025674.com) 域名啟用 HTTP/2 或 HTTP/3
支援。
* 優點:一勞永逸,不僅解決 Stalled 問題,還能提升整體網站的載入效能和反應速度。

Q:接著我問我該如何得知目走的是HTTP多少

A:方法一:使用瀏覽器開發者工具 (最推薦)
這是在您自己的開發或生產環境中,最快也最準確的確認方式。
1. 打開您的網站:在 Chrome、Edge 或 Firefox 中打開您要檢測的頁面。
2. 打開開發者工具:
* 在 Windows/Linux 上按 F12 或 Ctrl+Shift+I。
* 在 macOS 上按 Cmd+Opt+I。
3. 切換到 Network (網路) 標籤:在開發者工具面板中,點擊 "Network""網路"
4. 重新整理頁面:保持開發者工具開啟,然後按 Ctrl+R 或 Cmd+R 重新載入頁面。你會看到所有的網路請求都列了出來。
5. 查看 Protocol (通訊協定) 欄位:
在請求列表的表頭中,找到名為 "Protocol" 的欄位。
* 如果沒有看到 "Protocol" 欄位:在表頭(例如 "Name", "Status", "Type" 的那一行)上按一下右鍵,然後在彈出的選單中勾選 "Protocol"
6. 判讀結果:
* 如果顯示為 `h2` 或 `http/2`,恭喜,您的網站正在使用 HTTP/2。
* 如果顯示為 `h3`,代表正在使用 HTTP/3 (更新、更快)。
* 如果顯示為 `http/1.1`,則代表您還在使用舊的 HTTP/1.1,這就是造成 Stalled 問題的元兇。

方法三:使用 curl 指令 (進階)
如果您熟悉使用終端機,可以用 curl 指令來檢查。
打開您的終端機並執行以下指令 (將 your-website.com 換成您的域名):
1 curl -Is https://your-website.com | head -n 1
* 如果回應是 HTTP/1.1 200 OK,代表是 HTTP/1.1。
* 如果回應是 HTTP/2 200,代表是 HTTP/2。

檢查結果


方法二要用工具太麻煩就忽略吧

至於http protocol之間差異在哪,gemini解釋太長了我直接放上連結

用人話來說就是http1.1一次只能載6個檔案,所以會組塞,http2跟3速度更快


小結

所以最終結論就是,真的不關我的事,後端跟維運要處理,AI萬歲,半小時搞定,準時下班~



2025年7月23日 星期三

你知道vscode也可以做到ngrok的效果嗎?

通常我們要把電腦的網頁分享給別人

一般人都會下指令

ngrok http 80 // or 8080 or ....

前提是你有ngrok指令,這樣就會產生一段網址,可以連到你電腦的某個port

但近期看到一篇奶綠茶大大的文章

詳情大家可以自己去看,簡單來說vscode也有類似的功能,但實際操作起來狀況挺多的,我作一下紀錄

我初次在嘗試一直卡在開啟的部分(我現在試正常,可惡,而且似乎只有我遇到),等了十分鐘也沒下文,我想說不應該啊,一個服務啟動這麼久,好意思說要取代人家,後來show log點進去,滑到最上面,有看到一些網址,找到device後綴那個網址,先別急著點,再往後面一點,有一串八碼的代碼,先複製起來,再打開該網址

首先會看到要用github帳號繼續,接著會要求輸入八碼代碼,然後就是認證什麼的繼續點,最後才成功開啟服務,看到他給的網址

記得把port visibility改成public,修改方式是按右鍵,找到port visibility,下拉選單進行選擇(這點實在很不直覺),這樣可以讓你朋友在連網址可以少一個動作,但還是有機率會先進到微軟畫面,要點一下繼續(這情況大概兩三個人會遇到一個,我拿學生作實驗)

結論:
所以論爽度ngrok還是稍爽一些

2025年4月29日 星期二

好文分享,人人都需要http-proxy來debug

網路文章


safari的header延伸,踩坑系列

 故事發生在一天下午,被開出了bug,請參考下圖

動態島nav bar的部分被延伸了,有趣的是,在另一個平行專案,底色是藍色卻不會發生。

詢問AI說是safari為了給你滿滿的沉浸式體驗,有了這相設計,我咧甘霖良!能不能不要這麼假掰,還有這BUG位啥要算在前端頭上,你應該算在庫克頭上啊==

但,藍色不會發生代表他有可能可以克服的吧,我比對了一個晚上的程式碼,發現不管顏色你寫在是body, header還是最上面的div背景顏色,都可能會影響到nav bar,然而可能比較潛顏色不會(所以平行專案的淡藍色才沒有),靠悲,這樣我怎麼搞啊!這時AI大神也救不了我了

最終,我還是在同個專案中找到了答案,我發現它header背景顏色如果是漸層,nav bar就沒有延伸了....如法炮製了一下還真的是,所以只要把單一色改漸層(漸層兩邊放同一個色碼就好),成果如下,只能說,握草~~

2025年4月28日 星期一

placeholder突然變粗了?css踩坑系列

事情是這樣的,在案發當天晚上十點左右,UI突然敲我說為什麼input所有placeholder字體都變粗了,我到底改了什麼,叫我退版。

問題是我根本什麼也沒改,被UI被PM被測試追殺已經很煩了誰還有空亂加東西,我矢口否認,但UI開始瘋狂跳針叫我退版,我一氣之下回他:「小姐你知道我今天上了多少版嗎?你要我退版好歹也要讓我知道哪一版啊!」

然後我就被吉了!

但這不是今天重點,總之後來我使用下面這語法暫時瞞過主管趕上線

input::placeholder {
@apply font-light;
}



硬把字體調細了。然後我仔細去看UI給我的對比,確實這頁的placeholder比較粗....這就神奇了。但礙於當時已經很晚了,趕快做完保命要緊!

然後就過了兩週,今天心血來潮想要一探究竟,最終發現最外的.page裡面有個語法

-webkit-font-smoothing: antialiased;

把這語法點掉就變粗了,但因為這在很外層所以當天沒找到,礙於時間壓力也沒心思慢慢看。

但為什麼這頁會出事呢?根據css說法這語法是用來消除鋸齒,讓文字更平滑,看起來也會更細,

那為什麼這頁會突然變粗呢,原因是因為頁面中底部的popup我是使用React.createPortal去創建在body下面的,所以他根本沒吃到.page的css

所以UI口中的突然壞掉要我退版,就是我手刻了這個popup導致的,但~鬼會知道啊~

唉~總之~又是個美好的一天~


補充:

事後在另外一個專案又發生類似的事情,結果不是出在這css,查詢結果問題發生在字體...好一個博大精深


2025年4月16日 星期三

在網頁作動畫現在有更好的選擇requestAnimationFrame

網頁作動畫應該很直覺都是使用setTimeout()或setInterval(),但timer其實不是這麼精準的

但記載前幾天叫grok幫我寫程式時他給了我一個方法

requestAnimationFrame()

激起我的興趣我去查了一下

出自網站

https://ithelp.ithome.com.tw/m/articles/10186735

我直接附上裡面的程式碼,有時間再研究囉,據說可以依照機器的好壞把時間控制在微秒,然後這竟然還是八年前就有的東西我的天啊


function startAnimation() {
var start = null;
var limit = 2000;
var count = 0;
requestAnimationFrame(animation);
function animation(t) {
count++;
if(start === null) start = t;
if(t-start < limit) {
console.log(t, start, count);
requestAnimationFrame(animation);
} else {
console.log('done.');
}
}
}