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

DigitalOcean 裁員

上個禮拜的消息了,DigitalOcean 決定裁員:「DigitalOcean is laying off staff, sources say 30-50 affected」。

推出新產品與新服務的速度不算快,不知道是不是因為組織龐大造成的... 如果是的話,這次的裁員未必是壞事,以 TechCrunch 拿到的內部消息知道是 30~50 人,大約是全體的 10%。

另外一個問題是 DigitalOcean 提供的 CPU 一向都是三家裡面最慢的 (另外常被拿出來比較的兩家是 LinodeVultr),在大家都是一樣的服務下,這個缺點就蠻明顯的...

OpenVZ 裡的 Docker

前幾天在公司弄 GitLabGitLab CI,前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體,動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變,不過最少丟個 1GB 差不多...

公司用的機器當然是還好,先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體,然後另外一台 t3a.small (2GB) 跑 CI 的 Runner,真的有需要的時候可以再往上拉...

不過自己也要弄的時候就會考慮到成本問題,畢竟也只有自己一個人用,如果在 Vultr 上面租類似的機器就要 USD$30/month,其他的 KVM VPS 也都差不多價錢。

OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少,但有不少限制。其中一個限制就是沒辦法跑 Docker,這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑,但我這邊偏好用 Docker)。

查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker),發現 OpenVZ 7 已經支援 Docker 了,而且在官方文件上面也都已經有說明了:「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。

然後順著找一下,發現市場上也已經有 OpenVZ 7 的 VPS,而且會宣傳支援 Docker,試著租一個月也確認可以跑,這樣代表之後又有更多選項啦...

Rasmus 的平價 VPS 測試

Rasmus Lerdorf 整理的資料 (就是生出 PHP 的那個 @rasmus),關於平價 VPS 的測試:「Low-Cost VPS Testing」。

因為是 PHP 的大頭,所以把編 PHP 當作是 benchmark 的項目之一也不算太意外。另外還是有比較常見的 dd 與 iperf3 測試資料可以看。

算是一個挖掘的點,之後也可以租幾台測試看看...

Bitbucket 放棄 Mercurial

Bitbucket 放棄對 Mercurial 的支援:「Sunsetting Mercurial support in Bitbucket」。

兩個時間點,一個是明年二月不能再新增,另外一個是明年六月完全停用:

February 1, 2020: users will no longer be able to create new Mercurial repositories
June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.

在 Mercurial 網站上的 wiki 也更新了:「Mercurial Hosting」,對於不想要搬到 Git 的人可以在這份列表裡找替代方案。

靜態網頁服務的選擇

Hacker News 上看到「Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains (github.com)」這篇,除了文章連結外,留言提到了不少工具...

一種是透過 GitHub Pages 的方式提供服務,或是透過 Netlify,需求真的需要動到 AWS 元件的情況其實還是考慮用傳統一點的架構 (EC2 或是 VPS) 會更有彈性。

算是提出一個雞肋後,其他人把真正有用的工具整理了出來...

DigitalOcean 買下 Nanobox

DigitalOcean 宣佈買下 Nanobox:「Nanobox Joins the DigitalOcean Family」。

Nanobox 是一個類似 Heroku 的服務,提供平台 (Platform) 讓開發者不需要自己架設伺服器,就可以直接把寫好的程式丟上去跑。

這次 DigitalOcean 買下 Nanobox 算是跟他們產品走向一致,提供更上層的應用,降低開發者要接觸營運這塊的門檻。另外之前提供了 PostgreSQL 的服務 (類似 Amazon RDS) 也是類似的想法。

不過 DigitalOcean 的機器速度不快,如果是因為價位而不想用 Heroku 的人,應該也會猶豫... 如果預算不是太大問題的話,其實 Heroku 還蠻好用的?目前想不到有什麼關鍵的優勢...

Packagist.org 要搬到 AWS 上...

Packagist 打算把服務丟上 AWS:「An Update on Packagist.org Hosting」。

We decided to migrate the packagist.org website to AWS as well, including the database, metadata update workers, etc. This makes it much easier to build a highly-available setup, where machines can be rebooted or even rebuilt safely without bringing down the whole site.

不知道會搬多少上去... 目前 .compackagist.com 已經上 AWS 了,但 packagist.org 與主要的流量來源 repo.packagist.org 看起來都還沒。

Linode 推出 Dedicated CPU Instances

Linode 決定要推出 Dedicated CPU Instances,看起來相當於 AWSEC2 裡一般性的 EC2 instance (指非 t 系列的),跟之前 CPU 共用而導致 CPU 可能時快時慢不同,這個方案讓 CPU resource 穩定輸出:「Introducing: Linode Dedicated CPU Instances」。

Dedicated instances are optimized for workloads where consistent performance is required or where full-duty work (100% CPU all day, every day) needs doing.

拿 EC2 裡的 c5.large (2vCPU + 4GB) 比較差不多是一半的價錢,但實際不知道差多少... 回台灣的時候測試看看好了。看起來如果真的要在 Linode 上跑 Kubernetes 的話反而要用這種機器?