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,不過好像沒特別提到...

Google Chrome 78 又要搞事把 www 開頭拿掉了...

剛剛改回用 beta channel 的 Google Chrome (78 版),結果發現網址列裡的 www 被拿掉,而且本來可以關掉的方式 (omnibox-ui 系列的設定) 從 chrome://flags 裡面也拔掉了,代表你現在關不掉了...

搜了一下資料,發現在 Reddit 上有人討論過 78 版的這個問題 (當時還在 dev channel):「Chrome 78 dev hide 'www' again」。

裡面有人提到可以安裝 Suspicious Site Reporterwww 重現,當初看到還半信半疑,結果裝了發現真的會動,WTF...

看了一下 extension 的 source code 發現好大一包,以後應該會有人生一個小的 extension 出來專門做這件事情?

Internet 上的 3rd party js 的情況

Twitter 上看到這則:

裡面提到了「patrickhulce/third-party-web」的分析 (作者是從 HTTP Archive 的資料分析),裡面依照不同種類的 3rd party js (像是 ad,或是 social element,或是分析工具) 需要執行的時間,以及使用的站台數量。

Social 那邊意外看到 PIXNET 有上去,然後速度只比 Disqus 快一些,應該是沒有 optimize 的關係。

如果整體一起看的話 (總和花費時間),可以看到 Google 各項產品都在最前面,畢竟裡面每個項目都是被廣泛使用的。

用 2018 的技術讓網頁更像 2000 年的網站...

看到「jjkaufman/wiv.js」這個專案,然後點開他的 Demo Site「The web site of coughdrop」後笑出來,這把 2000 年網站的特色做到極致了... XD

看程式碼可以看到主體是在 canvas 上操作,然後用 requestAnimationFrame 產生。

Mixnode:又一個可以搜尋整個 Web 的服務

看到「Turn the web into a database: An alternative to web crawling/scraping」這篇,在介紹自家 Mixnode 這個產品,看起來是提供 SQL 界面分析整個 Web 的服務...

這類服務最重要的反而不是搜尋界面 (有可以讓程式接的 API 其實就 ok 了),重要的是後面的資料庫有多豐富...

在「用 PublicWWW 分析網站」這邊有提到類似的服務 PublicWWW,而且也一樣有提供 API,先把 Mixnode 丟著記錄起來就好,等有需要的時候再去申請 trial account...

關閉新版 Google Chrome 網址列雞婆省略 www 的行為...

因為平常用的 Google Chrome 是 beta channel,前陣子出新版後網址遇到 wwwm 時就會不見,像是網址輸入 https://www.google.com,在連上後會變成這樣:

這樣讓人很不習慣,當時在網路上找了一些資料都沒找到,結果剛剛找資料時意外發現找到解法了:「Chrome address bar no longer shows protocol or www subdomain」。

把這個選項改成 Disabled 後,重開瀏覽器就恢復原來的行為了...

ALB 支援 Slow Start 了

這個功能在 ELB Classic 年代時有跟 AWS 提過,到 ALB 支援了 (總算...):「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。

Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.

然後時間可以設定,從 30 秒到 15 分鐘:

Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.

就之前的經驗來說,這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣,可能不會這麼吃這個功能。

主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時,儘量將 CPU 留給 opcache,把常用的頁面 compile 完並且放進 cache,而不是讓大量的連線灌進來,這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久,造成每個連線都很慢才跑完)

AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...

用 PublicWWW 分析網站

在「Keylogger Found on Nearly 5,500 Infected WordPress Sites」這邊看到的網站服務 PublicWWW

雖然原文是說 WordPress 被感染的情況,但注意到的反而是他提到的網站 PublicWWW。

在 PublicWWW 上面目前收錄了兩億個網站的資料,有些東西頗不賴的,像是可以搜尋有哪些是使用同樣的 Google Analytics 帳號:

Sites with the same analytics id: "UA-19778070-"

這拿來找誰是內容容場後面的人超棒的啊,而且可以拿來補內容農場的清單,像是「UA-31425034 - 19 Websites - PublicWWW.com」這個 XD

免費版只能搜 Top 3M 的部份,付費版 (USD$49/month) 則是可以搜所有的資料。

Million Dollar Homepage 上的網站存活率

作者在分析 2005 年炒熱話題的 Million Dollar Homepage,上面所列的網站的存活比率:「A Million Squandered: The “Million Dollar Homepage” as a Decaying Digital Artifact」。

這是作者在 2017 年抓的截圖:

而這是分析圖:

作者跑程式分析,其中大約一半的 pixel 已經失效:

The 547 unreachable links are attached to graphical elements that collectively take up 342,000 pixels (face value: $342,000). Redirects account for a further 145,000 pixels (face value: $145,000).

不過如果以網站數量來看,則大約還有 63% 活著:

Of the 2,816 links that embedded on the page (accounting for a total of 999,400 pixels), 547 are entirely unreachable at this time. A further 489 redirect to a different domain or to a domain resale portal, leaving 1,780 reachable links.

突然有種「銀河的歷史又翻過了一頁」的感覺 XDDD