Tag: css

MVP.css

看到「MVP.css — Minimalist stylesheet for HTML elements」這個，目標是只需要寫 semantic html，剩下的就交給 css 處理：

No class names, no frameworks, just semantic HTML and you're done.

這種專案主要是看樣式喜不喜歡，畢竟選這種方案主要目的就是「懶」而不是要做太多效果，之後有機會來用看看...

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

把 BOOKWALKER 的書名完整顯示出來

從剛開始工作就有在看輕小說，但是現在住在外面租屋，實在不方便買一堆實體書，所以就弄了 iPad 在看電子書 (yeah，我對電子紙的材質還是不太喜歡，不過那是另外一回事了...)，平台的話主力就是 BOOKWALKER。

然後每次買書都會遇到很討厭的問題，最重要的集數給我顯示出來啊啊啊 (上排中間的書名，與下排左二與中間的書名)：

看起來是被 height + overflow 幹掉了，所以寫了一個 www.bookwalker.com.tw.user.css 處理，讓他不受到 height 限制冒出來 (需要安裝 Stylus (Chrome) 或是 Stylus (Firefox) 之類的套件)：

這樣總算是好了點...

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論，無論是 HTTP/1.1 時代，或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push)，各種讓下載速度最佳化的技巧以及造成的複雜度：「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧，也就是 JavaScript 的 bundle，或是 CSS 的 Image sprites，甚至是 API 的合併，像是很多人會考慮的 GraphQL。

雖然在 HTTP/2 年代我們常說可以省下來，但這並不代表「打包」在 HTTP/2 情境下沒有效果，只是改善的幅度比較少，所以這個最佳化的技巧比起 HTTP/1.1 年代，可以放到後面一點再做，先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了)，其實繼續使用沒有太大問題...

另外是 Server Push 的情境，意外的反而可以提昇不少速度，看起來主要是少了請求的時間，所以快不少。

再來是跨網域時 CORS 的問題，在 Flash 的年代是一個 crossdomain.xml 解決，但現在的解法是多一個 OPTIONS request，反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制：「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的：

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

延遲載入 CSS 的方式

在「Simpler way to load CSS asynchronously」這邊看到的技巧，利用了 onload 與 <noscript> 的方式，達成延遲載入 CSS 的效果：

<link rel="stylesheet" href="/path/to/my.css"
      media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

對於非必要的 CSS 可以用這樣的方式加強，看起來頗不賴... 這邊提到的方式，作者是引用「Smashing Newsletter: Issue #234」，不過查了一下發現 2015 的時候有人在 StackOverflow 上回答過：「How to load CSS Asynchronously」，不確定有沒有更早的資料...

另外一個比較新的語法是使用 rel="preload"，但支援度就不太好了，需要靠 polyfill 之類的方式補上 (於是又多了一些東西要 load)，反而不如前面提到的方式來的簡單。

自產生程式的 HTML 版：看到的頁面就是 HTML 程式碼

自產生程式，或是更常用的英文名 Quine 指的是「程式輸出的結果」與「程式碼本身」相同的程式，算是一種趣味性的程式...

在 Hacker News 上看到「Show HN: This page is a truly naked, brutalist HTML quine (secretgeek.github.io)」這個連結，裡面是 HTML 版的 Quine，原始網頁在「This page is a truly naked, brutalist html quine.」，頁面長這樣 (取前面的部份)：

你在網頁上看到的所有文字，就是程式碼本身 (有一個小地方例外，可以直接看原始碼確認)，而且這個 HTML 還說明怎麼做到這件事情。

裡面是一層一層解，第一個提到的是 * { display:block; }，這使得所有的元素都會顯示出來，包括了像是 <title> 這樣本來放在 <head> 裡的元素。

唯一的例外是 <style> 本身避不開：

The only other style that is special is "style" itself, which has to include an escape character to avoid being taken literally.

翻了一下 Hacker News 裡的討論，大家都還蠻欣賞的，主要是有些感嘆很有趣，像是說這個網站的可讀性反而比其他新聞站台好很多：

This is more readable than many news websites I've come across

話說回來，我對新聞類的網站還蠻喜歡關掉 javascript 的，通常效果都很好...

儘量不使用 JavaScript 的前端設計...

在「A JavaScript-Free Frontend」這邊看到的，目前看起來還是很辛苦啊...

首先是可以看到他對 Asana 的抱怨：

First, I live in a rural area with only 2 Mbit/s down Internet connection. With a warm cache it takes 14 seconds for the Asana UI to become usable. Second, you can see below that the app is comprised of over 10MB of uncompressed JavaScript. That is a huge amount of code to execute. How is this acceptable?

現在前端頁面的 JavaScript 愈來愈大，除了下載時間之外，其實最卡的應該還是瀏覽器要處理編譯的時間。作者試著用現有的元素開發他的產品 Slimvoice，然後把心得整理出來... 其實還蠻考驗對 CSS 的基本功，有些東西是你根本不知道存在，另外有些東西是支援度的問題。

這個概念應該就是十多年前倡導的 Unobtrusive JavaScript，不過在這幾年前端框架雨後春筍般冒出來後就不太有人在管了 (一堆站台關掉 js 就不會動)，而這也大幅「促進」了瀏覽器對 js 執行速度的改善...

用 CSS 貼 3D 場景的圖

看到一個 demo 展示瀏覽器內 CSS 的處理能力，看起來已經足夠到可以處理不少貼圖與光線效果的部分了：「CSS FPS」。

This is demo of a CSS powered 3D environment. Geometry is created with HTML elements and CSS transforms. Textures and lightmaps are composed by layering multiple background-images and colour is applied using CSS blend-modes.

不過遊戲應該會需要更多種類的效果，這部份目前應該還是得靠 javascript 來產生... (如果要在瀏覽器裡面跑)

用 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.

另外一套將新版 Gmail 介面改回舊版的 CSS

先前是用「Gmail Old 2018 Nov」撐著，後來在「shellscape/gmail-classic」這邊看到另外一組 css，看起來這組好一些... 拿作者的圖片：

圓框與各種浮誇的 hover 效果都儘量關掉，用起來會好一些。