Blowfish 已經衰退
前一篇是Blowfish 正在衰退。
是說差一點要被我救活了#3121,但是 PR 卻被 closed,我對這個開源專案感到徹底失望,不是被 close,是被縱容 AI 這件事惹的。
PR 內容和 owner 回覆
Follows up on #3091
Fixes #3086
| v3.8.0 | This PR | |
|---|---|---|
| LCP | 12.3s | 1.7s |
| TBT | 150ms | 40ms |
| SI | 6.7s | 4.1s |
| Power Consumption | 14W | 3W |
| FPS | ~30 | ~90 |
Scope
- Blur:
site-background.svg, feature shortcode, stat shortcode, pill-style tag page links - Avoiding repaints:
hero-scroll-fade.js - WebP support: site logo, hero, homepage
- Network loading: defer Firebase with the
loadevent - JS: inline critical script
A Few Notes
The reasons for each change are in the commit messages. Some highlights:
- Animated SVGs are computed in real time at the pixel level, so they can be very resource-intensive.
site-background.svgwas the main source of power draw. At about 124 GFLOPS, it is in the same range as a ViT-L16 network. - Frosted-glass blur (
backdrop-blur) is also computed in real time, which makes it costly too. - Firebase used to be deferred with
requestIdleCallback, which only watches the main thread, not the network. Theloadevent is the better fit. - The LCP images now uses WebP.
- When generating UI with AI, it may help to steer away from frosted-glass effects. Most of the issues here came from it (
feTurbulenceandbackdrop-blur).
Screenshots
PageSpeed Insights
v3.8.0
This PR
Power consumption
v3.8.0
This PR
3W is still fairly high. For comparison, playing a YouTube video stays under 2W. An animated SVG background always carries a non-negligible power cost.
FPS
https://github.com/user-attachments/assets/1d4aa136-01f1-4c69-b1e7-137b4016e982
回應
Owner 的回應擺明就是 AI,標準的開頭感謝、無意義的重複列出 PR 改動、破折號、列表、粗體、無意義的 main branch 提醒,不會有人會覺得這是真人寫的吧。
Thank you so much for this, @ZhenShuo2021 - the investigation and the numbers here are fantastic (LCP 12.3s → 1.7s, ~14W → 3W), and the write-up on SVG filters and backdrop-blur costs is really valuable. I genuinely want these improvements in.
That said, this PR bundles too many independent changes to review and merge safely in one go, so I'm closing it and would love to see it split into smaller, focused PRs, e.g.:
- SVG background + blur removal (
site-background.svg, feature/stat shortcodes, term pills) - JS changes (
critical.jsinline split,hero-scroll-fade.js, mermaid/appearance moves, Firebase onload) - WebP /
<picture>images
A few things to address along the way:
backgroundImageWidthis a documented config option - the hardcoded 1320/1920 widths would silently ignore it. Please keep honoring it.- Keep the
tryfallback:functions/resize.htmlwraps.Resizeintryso unprocessable images degrade instead of failing the build; calling.Resizedirectly loses that. - Extract the resize +
<picture>block into a partial rather than repeating it in 9 templates (that would also fix the two points above in one place). .prettierignore:assets/js/appearance.jsstill contains Go template syntax so it needs to stay ignored, andappearance-switcher.jsdoesn't exist.- Minor: the media queries
(width >= 853px)/(width < 852px)leave a 1px gap; inlinecritical.jshas no SRI, which may matter for strict-CSP sites.
Also note main has moved since (#3107 touched hero/background.html, #3118 touched baseof.html and the compiled CSS), so please branch from latest main.
Thanks again for the great work - looking forward to the follow-ups! 🙏
內容引用到此為止結束。
關閉的理由
關閉的理由有這些:
- PR 太大了
- 沒了
這個 PR 只有六個 commits,600 行改動,一個標準的中等 PR。
這 PR 的 commits 全都是同一個任務,把 commits 拆分成獨立 PR,把 commits 當 PR 審,那 PR 的意義到底是什麼???這不就只是提交 commits 嗎???有沒有想過為什麼 PR 允許多個 commits 而不是一個???就算拆分那同檔案的 stacking commit 還不是一樣會看到前面的???同檔案的 inter-PR 甚至還會 merge conflict 這怎麼工作???技術討論完全錯誤的 AI,搭配沒有辨識能力的 owner,我真是快瘋了。
再來指出的問題有以下:
- 忘了 backgroundImageWidth 參數
- 忘了 .prettierignore
- media query 少寫 1px
- 沒有用 try fallback
- 要求我 refactor picture 標籤
- 指控我 inline JS CSP 問題
前面三個 typo miss,後面三個完全錯誤,這三個問題當初沒講,現在反而變成被 AI 拿錯誤的內容指控我,完整體現垃圾 AI 完全沒有思考能力,再搭配一個沒有思考能力的用戶就完全放飛危害他人。
甚至第一個寬度設定都不重要,因為那個參數設計上就不該存在,這是會虛化的背景圖片,因此這張圖不需要高解析,只要畫質合理(我設定的 1920)就沒必要動,其次一般用戶也沒有能力知道自己該用多大的圖片,比如我現在寫的這個 consideration 普通用戶就不會想到,再者,如果用戶要很小的解析度,那永遠不合理,還不如不要放圖片,用戶如果要放很大的圖片,那已經提供全局 disable resize 了,用戶如果要放適中的圖片,又回到用戶也沒有能力自行設定合適的參數,因為不是前端開發者就不會知道網路傳遞和視覺最佳化怎樣設定才合理。
再來講後面三個問題。try fallback 根本就不該用,silently fail 是永遠不該發生的情況,錯了就該報錯,不報錯怎麼知道哪裡有問題???這裡加上 warnidf、warnf 也毫無意義,因為圖片錯誤同一張圖片修了就再也不會發生了,也就是說這裡的 try 在任何情況下都毫無意義,連 CI fail 了你也不知道,誰沒事會盯著 CI log 看???除非你的想法是錯了沒差就算放 warnf 用戶也絕對不會修那張圖片,好,那我服你,你厲害,你邏輯我跟不上。
refactor 更扯,perf PR 叫我 refactor,我 perf PR 都不知道會不會被 accept,還要我發 refactor???反過來我真的先發了 refactor PR,我怎麼知道你會不會接受???等 refactor PR 被 merge 又要等到什麼時候才能做 perf PR???你是教授還是哪個慣老闆實際狀況毫不在乎,你怎麼搞你家的事,就只管你自己想要最好的結果???
inline JS CSP 技術錯誤,critical JS 本來就該 inline JS 而不是讓所有用戶都 blocking 等 network request。修正錯誤用法反而還被當成錯的人。
最後跟我說 main 記得更新,用錯的理由關閉 PR 之後還期待我 follow-up,完全不尊重人,當我連 Git 都不會用嗎??還讓 AI 指派我工作??到底是在搞什麼??
被 AI 批評已經夠糟糕了,AI 批評的內容是錯的更糟糕,要辯護 AI 錯誤的指控,還被 AI 指派任務更是令人感到被羞辱,完全不尊重人。
結尾
面對這些 AI 這些惡劣低級的回覆已經很糟心,最後一根稻草是無意義的 close PR 叫你重開一個而不是修改這個 PR,然後關掉 PR 又 order 我 follow-up PR,完全不尊重人,極度惡質的開源專案。
再說一次,我不反對 AI,這個 PR 我也使用大量 AI 協助完成,但是真正不尊重人的點就和剛才講的一樣。
- 被 AI 批評已經夠糟糕了
- AI 批評的內容是錯的更糟糕
- 作為人類,卻要花時間精力辯護 AI 錯誤的指控
- 被 AI 指派任務更是令人感到被羞辱
- 粗暴的 close PR
送這個專案幾個字,低劣,惡質,毫無尊重。
擷圖
整段 PR 的超長擷圖
