Tag: page

Android 規劃 16KB Page Size

Hacker News 上看到 Android 在規劃 16KB Page Size 的消息：「Adding 16 kb page size to Android (googleblog.com)」，原文是「Adding 16 KB Page Size to Android」。

Android 目前主力是 4KB Page Size，但因為 ARM 有支援 16KB Page Size，所以測試後發現雖然會多用 9% 記憶體，但效能會增加不少：

Most CPUs today support a 4 KB page size and so the Android OS and applications have historically been built and optimized to run with a 4 KB page size. ARM CPUs support the larger 16 KB page size. When Android uses this larger page size, we observe an overall performance boost of 5-10% while using ~9% additional memory.

雖然說 overall performance 有提升，但在「Benefits and performance gains」這邊可以看到目前列出來的項目都是特定的行為 (像是 app 啟動，camera 啟動，或是開機時間)，這點可能要再看看其他的評測。

16KB Page Size 應該是個取捨，畢竟手機不像伺服器隨便就是上百 GB RAM 甚至到 TB RAM，跑一些吃記憶體的應用用 Huge Page 拉到 MB 等級的 Page Size 比較划算...

Amazon SESv2 的 Deliverability Dashboard

其實是看到「Amazon SES V2 now supports email size of up to 40MB for inbound and outbound emails by default」這篇才注意到寄信的 Amazon SES 服務有了 SESv2，原文主要是講放寬信件的大小限制：

With this launch, the default message size limit in Amazon SES V2 increases from 10MB for email sending and 30MB for email receiving, to 40MB for both sending and receiving .

不過我跑去「Amazon SES pricing」看的時候意外翻到這個貴貴的東西：

The Deliverability Dashboard (via the SES API V2) is available for a fixed price of USD $1,250 per month. This charge includes reputation monitoring for up to five domains and 25 predictive email placement tests.

然後我試著去找 Deliverability Dashboard 是什麼，卻沒有專文介紹？(還是我找錯關鍵字...)

倒是在 2018 年的時候 Amazon Pinpoint 有個公告提到 Deliverability Dashboard，價錢也是 US$1,250/mo：「Amazon Pinpoint Announces a New Email Deliverability Dashboard to Help Customers Reach their Users' Inboxes」。

本來以為是 Amazon Pinpoint 的服務轉移掛到 SESv2 下，但看「Amazon Pinpoint Pricing」這邊，好像還是在啊...

雖然用不太到，但還是一頭霧水 XDDD

維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個，維基基金會相關服務的官方狀態頁：「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生)，另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量，可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去，不知道有沒有後端 PHP loading 的數字...

網頁本身是個合法的 JSON 的展示

在 Hacker News Daily 上看到「Web Data Render」這個有趣的東西，這個網頁本身是個 JSON，透過一些技巧載入 javascript 後就可以讀取資料 render...

不過網頁本身就不是合法的 HTML 了：「Showing results for https://webdatarender.com/」，只能算是個有趣的作法...

把 HTML 資料都塞到 URL 裡的服務

如標題說的，專案叫做「URL Pages」，是一個把 HTML 的原始碼都放到 url string 裡的服務。服務本身可以在 http://jstrieb.github.io/urlpages 這邊使用。

現在網路上有很多地方可以塞 demo page (像是 GitHub 自己提供的 GitHub Pages)，這個方式需要依賴 JavaScript 提供各種轉換機制，應該會有不少 side-effect bug，看起來會有不少技術瓶頸，就當作是個實驗性質的專案來看，真的需要放 demo page 的還是可以隨便找空間放比較簡單，像是前面提到的 GitHub Pages 其實可以直接在 GitHub 的網頁上操作...

Mercury Web Parser 開源

看到「Mercury Goes Open Source!」這篇，Postlight 的團隊開源了 Mercury Web Parser，程式碼在 GitHub 上的 postlight/mercury-parser 可以取得。

這個版本是用 Node.js 寫的，可以從範例看出用法以及結果：

import Mercury from '@postlight/mercury-parser';
Mercury.parse(url).then(result => console.log(result););
{
  "title": "Thunder (mascot)",
  "content": "<div><div><p>This is the content of the page!</div></div>",
  "author": "Wikipedia Contributors",
  "date_published": "2016-09-16T20:56:00.000Z",
  "lead_image_url": null,
  "dek": null,
  "next_page_url": null,
  "url": "https://en.wikipedia.org/wiki/Thunder_(mascot)",
  "domain": "en.wikipedia.org",
  "excerpt": "Thunder Thunder is the stage name for the horse who is the official live animal mascot for the Denver Broncos",
  "word_count": 4677,
  "direction": "ltr",
  "total_pages": 1,
  "rendered_pages": 1
}

先前其他的軟體與服務可以參考「Evaluating Text Extraction Algorithms」這篇的整理與比較，不過這篇連原網站都不見了... 只能從 Internet Archive 上翻出來。

這個主題有不少團隊都做過 (給一個 html 網頁，抓出實際的內容塊落)，但也死了不少團隊... 比較有印象的是 Readability，在 2016 年收掉了：「The Readability bookmarking service will shut down on September 30, 2016.」。

要撈資料可以拿來用...

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外，在「Preload Scripts」這邊看到的技巧，可以跟 browser 說明哪些資源比較重要，請儘快先下載：

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法，這個技巧應該用在會卡住頁面呈現的部分，確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面，理論上會更快：

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助，建議可以跑 A/B test 看看效果：

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

讓 Chrome 開新 Tab 時不要出現搜尋頁

Google Chrome 的新 tab 現在預設都會出現 search engine 頁面 (即使你設為 about:blank)，但我從來就沒有在這頁搜尋過東西 (都是直接在 location bar 輸入)，所以想要拿掉這個「功能」。

找到由 thakis@chromium.org 提供的 extension，而且是在 2013 年就發佈了：「Empty New Tab Page」，他給的截圖意思就很清楚了：

看了一下 source code 也的確是乾乾淨淨的，先裝這個...

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt，參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇)，但測了一下不是我想要的效果，就找了一下網路上的資源，結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt，會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係，可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME，一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理，而且有蠻多 header 可以設定，其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的)，可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header，當設定 HSTS 之後，SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day)，不過只拿來做 redirect 應該還好...

PS：如果有人要推薦其他的組合也歡迎...