Tag: css

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 效果都儘量關掉，用起來會好一些。

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac，而不是講 app...

這次從高雄回來，在高鐵上想說用手機看看 Trac，發現桌機版的界面是會動，但在手機上不太好用，所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用)，標語是「A responsive, flat, blue theme using Bootstrap」，拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整：

裝好後用手機測了一下，還是有不滿意的地方，不過改善不少了，先這樣撐著...

MDN 上的 CSS Layout cookbook

在 MDN 上看到「CSS Layout cookbook」，目前整理了六種情境，包括了設計方式與瀏覽器的支援度。

看到「Center an element」有種苦笑的感覺啊... 以前弄這個都是 workaround，現在都有對應的 CSS 可以處理了。

Trac 關票時的資訊...

Trac 關票時一般都是由開票的人關 (i.e. Reporter)，今天遇到的情況是這樣，在關票時的畫面上你會不知道是誰開的：

只要往上一點拉就會看到 Reporter 資訊 XD 這通常會發生在螢幕沒打直的人，直接拉到最下方的情況 XD

試著用 CSS 的 position: sticky 但抓不太到要的效果，決定還是開 jQuery 下去解決 XD

        // Copy reporter information to action section
        if ($('#action_resolve_resolve_resolution').length > 0) {
            var reporter = $('#h_reporter').parent().find('.trac-author, .trac-author-user')[0].outerHTML;

            $('#action_resolve_resolve_resolution').each(function(){
                $(this).parent().append('<span class="hint">(This ticket is created by ' + reporter + ')');
            });
        }

當下寫得很隨性，之後也許會再改... (會更新到「Trac - Gea-Suan Lin's Wiki」這邊)