WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下,WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論:提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好),然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候,宣稱失真壓縮的部份可以比 JPEG 小 25%~34%:(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%~34% 這個數字,是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg,而如果拿 MozJPEG 相比的話應該得不到這個結果,另外也把 AV1 的 AVIF 拉進來一起測試了:

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite,測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些,但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善),而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了:

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好,不過要注意演算法會把非重點部位的細節吃掉:

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說,WebP 另外一個痛點是在 Safari 上的支援度,在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了,就剩下 Safari 還不支援,所以目前在 iOS 上得降回 JPEG:

不過這點之後也改變了,在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了:「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...

Google Chrome 又要對 URL 搞事了...

上個禮拜鬧的頗兇的話題,Google Chrome 又要對 URL 搞事了:「Google resumes its senseless attack on the URL bar, hides full addresses on Chrome 85」。

這次是打算把整個 path 藏起來:

A few new feature flags have appeared in Chrome's Dev and Canary channels (V85), which modify the appearance and behavior of web addresses in the address bar. The main flag is called "Omnibox UI Hide Steady-State URL Path, Query, and Ref" which hides everything in the current web address except the domain name. For example, "https://www.androidpolice.com/2020/06/07/lenovo-ideapad-flex-5-chromebook-review/" is simply displayed as "androidpolice.com."

來繼續等 3rd-party browser 成熟...

Chrome Extension 的效能分析

在「2020 Chrome Extension Performance Report」這邊看到有人對 Chrome Extension 上前一千名的效能分析,作者有提到是在 GCP 上的虛擬機測試的,跑七次取中位數:

I ran these tests on an n2-standard-2 Google Cloud instance, the numbers in this report show the median of 7 runs.

在「Chrome Extension Performance Lookup」這頁可以直接互動查詢,像是丟入 block 找跟擋廣告有關的關鍵字可以看到:

只看一般性的 blocker (中間還有 VPN 與一些不是一般性的先跳過),沒什麼意外的 uBlock Origin 的表現很好。

文章內的說明也可以翻一下,看看有沒有哪些 extension 其實不是很必要,但卻榜上有名,可以考慮拔掉省時間與資源...

HTML 轉 SVG

在「html-to-svg」這邊看到的,專案在 GitHub 上的「as-a-service/html-to-svg」這邊。

整個服務的程式碼其實很短 (大約 50 行?),因為主要的業務是透過 Chrome (headless) 生出 PDF 檔,再用 Inkspace 把 PDF 轉成 SVG:「htmltosvg.js」。

主要是 Inkspace 可以做 PDF 轉 SVG 這件事情算是新知...

Cloudflare 改用自己的 CAPTCHA 服務 hCaptcha

CloudflareGooglereCAPTCHA 改用自家的 hCaptcha:「Moving from reCAPTCHA to hCaptcha」。

看起來其實就是錢的問題,reCAPTCHA 要收費了,而以 Cloudflare 的量會太貴:

Earlier this year, Google informed us that they were going to begin charging for reCAPTCHA. That is entirely within their right. Cloudflare, given our volume, no doubt imposed significant costs on the reCAPTCHA service, even for Google.

另外 hCaptcha 有提供免費版本給一般網站用,剛出來這幾天等白老鼠寫心得後,再決定要不要跳進去測試...

幫 2011 年的 Mac Mini 換 SSD

這台 Mac Mini 是我第一個蘋果產品 (退伍後在 PIXNET 的時候買的),當時本來想在上面寫些東西,不過後來就一直當個終端機在用而已,到這幾年他的定位就是放在客廳當個播放器 (像是開 Twitch 或是 YouTube 在看)。

不過每次用都覺得開 Google Chrome 開的很慢,就興起將硬碟換成 SSD 硬碟的念頭了。至於記憶體,當初在買 Mac Mini 的時候應該是已經升級過,裡面是兩條 4GB 了,網路上是有人提到可以支援兩條 8GB,不過以目前客廳的用法,應該是用不到...

先對價錢做了一些功課,如果是自己處理,打算換成美光的 Crucial MX500,在 24h 是賣 $2,099 (不過後來是剛好有去光華一趟,就在光華買回來),然後打電話問一下有提供更換服務的店家,500GB SSD 是 $3,500 換到好,1TB SSD 則是 $6,000。

以 500GB 的價錢倒是沒有到不能接受,但也不是能馬上就說 ok 的價位,還是得看一下有多麻煩才能決定要怎麼做。

所以就跑去看了一下 YouTube 上換 SSD 的影片,看起來只要有對應的螺絲起子,應該是可以自己換完。而我之前就有準備六角螺絲起子,應該是可以換下來:

實際拆的時候才發現,不只需要正六角的螺絲起子 (H 系列),還需要星狀的螺絲起子 (T 系列),本來想在 24h 下單隔天再來弄,突然想到這種東西在水電五金行應該有,當時才晚上八點,就跑去外面找了一組 (價錢也比 24h 便宜),回來繼續拆...

有了正確的工具,拆開就簡單不少,反倒是裝回去折騰一陣子... 在裝有 WiFi 天線的那塊板子的四顆螺絲時卡了一個小時 (一直都只鎖的上去三顆),最後本來是打算少鎖一顆螺絲,結果在準備放棄的時候突然暴力法把四個孔位都卡進去了,就順利把四顆螺絲都鎖上去...

接下來就是先開機進入 macOS Recovery 確認硬碟有被抓到,確認有被抓到以後,就可以準備重裝系統,這時候我拿 MBPR 下載 10.13 (High Sierra,這台 Mac Mini 能支援的最新版),生出 USB 隨身碟裝機,然後插回 Mac Mini 重開機就可以裝系統了:

裝完後的開機速度很明顯快不少,裝軟體的速度也是,另外再打開一些網站看一看,冷啟動的速度都改善很多。

算是趁連假的時候整理一下硬體,還蠻有趣的...

Chrome 與 Chrome OS 最近不會更新新功能

這邊看到的消息,ChromeChrome OS 會避免在最近推出新功能,以維持軟體的穩定性,最近更新的主力會放在安全性上:「Google halts upcoming releases of Chrome and Chrome OS to keep things stable for everyone working from home」。

報導引用自 Twitter 上的宣佈:

呃,突然想到 Windows 的更新情況...

Pale Moon 呼籲不要使用 Google 主導的 WebComponents

Pale Moon 官方論壇的公告區「An Open Letter to Web Developers」這邊。

While, as a software developer ourselves, we understand very well that new features are exciting to use and integrate into your work, we ask that you please consider not adopting Google WebComponents in your designs.

話說回來,Pale Moon 用起來有種懷念感,而且比起現在的 Firefox 好用不少,只是上面套件有點少...

Brave 出手檢舉 Google 沒有遵守 GDPR

Brave (從 Chromium 分支出來的瀏覽器) 檢舉 Google 沒有遵守 GDPR 的規定:「Formal GDPR complaint against Google’s internal data free-for-all」。

主要是「purpose limitation」這個部份,出自「REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016」:

1. Personal data shall be:

(b)

collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

比較重要的是 specified 與 explicit 這兩個詞,GDPR 規定必須明確指明用途,而可以從整理出來的文件「Inside the black box」裡的「Purported processing purpose」看到大量的極為廣泛的說明。

Google 應該會就這塊反擊認為這樣的描述就夠用,就看歐盟決定要怎麼做了...

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts,作者想要改善這塊,加速網頁的速度:「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧,只要加上 preconnect 預先把 HTTPS 連線建好,就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異:

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect,但從前後比較可以看出,整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的):

另外一個技巧是增加 swap,讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖,然後突然字都冒出來的情況,也就是把一般在用的:

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家,差異就更大了:

另外一個好處是改善 privacy,不過好像沒特別提到...