E.J. BLOG

Archive for April, 2011

[Research] HTML5’s Client-Side Storage Mechanism

5 comments

Image Credit

之前一直在研究 Chrome Extension,而其中頻繁地使用了 HTML 的 Client-Side Storage Mechanism,所以就花了一些時間去 survey 了一下資料並整理如下:

一開始我想要先了解一下為什麼有了 Cookie 的存在,卻又還要在 HTML specification 中提出新的機制來儲存資料?而根據 Wiki 的資料 顯示,Cookie 雖然只是一個純文字的文件檔,但其實在 Browser 與 Server 做溝通時,都會被附加在 HTTP Header 的 Cookie 欄位,這就是為什麼 Cookie 的資料在前後端都可以被存儲的原因。

就在我了解了其存在的意義後,我就想要了解為什麼都已經存在著 Cookie 這樣的存取機制,卻還要在 HTML5 的 Specification 中提出新的存取機制?這是一個好問題,在看了 Stack Overflow 的討論文之後得到了答案。

有的時候,我們並不需要與 Server 做太多的互動,只是需要一個前端可以互相使用的存取機制就好,哪怕只是傳遞一些簡單的識別代號。因為有了這樣子的需求,那 Cookie 在某種程度上來說就太大材小用了,甚至可以說是過於痴肥。所以在做了這樣的理解之後,就可以合理的推測前端「輕量級的存取機制」之必要性。(時間點就沒有考究了)

那在 HTML5 的 Specification 中到底提到了什麼樣子的新型存取機制?原本可以歸類為下面三類:

  1. Session Storage
  2. Local Storage
  3. Database Storage

之所以會說「原本」是因為 Database Storage 不知道因為什麼緣故就停止維護了(參閱下圖),所以我們就在此不做深入討論,只討論 Session 和 Local Storage。

如果要快速地了解兩者的差異,就是自己動手玩看看

接下來還是要說明一下:Session 的中文是叫「會期」,就是一段會議、對話的期間,而在 HTML5 下,如果我們採用 Session Storage ,則我們資料的生命週期(Persistence)及生存範圍(Scope)都只能在一個 tab / window 下。說實在的,一時真的想不到該機制能應用在什麼樣的情況下,但 W3C 有提到一個有趣的情況,就是當一個使用者在進行拍賣的交易的時,雙開了兩個同樣帳號的 tab 來做購買的動作(接下來是我個人的情境補完),如果我們是利用 cookie 來紀錄欲購買商品的編號,那其實就很有可能因為兩個 tab 存取相同的 cookie 檔(沒有 lock)而造成交易上的異常。所以在這種時候 Session Storage 就相當適用。

而另外一個 Local Storage 和 Session Storage 的差異就在於 Persistence 和 Scope ,它是一個可以長時間儲存的機制,即使是在關閉 tab / window 之後,先前所儲存的資料依然保留著,而範圍就是所有的 tab / window 都能夠存取使用,除此之外,還能夠允許同個 domain 間的資料互相存取,因此在資料的傳遞上面佔有很大的優勢。以我自己為例,我在 Google Chrome Extension 的開發時,就大量應用到 Local Storage 來幫助我的外掛記錄使用者的偏好設定,以便於在各個子腳本中做資訊的傳遞。

以上就是這次 Client-Side Storage Mechanism 的研究,歡迎留言指教 :]

Written by EragonJ

April 28th, 2011 at 11:31 pm

[Watch] What happened after publishing Facebook Blocker extension ?

leave a comment

Check : FBBK 的主介紹頁

這篇文章主要是要為我當初發佈 Facebook Blocker 做一個記錄,而其中我也觀察到了一些有趣的現象與數據,請大家待我娓娓道來。

一開始我們先看一下流量的部分,如果扣除掉前幾天的上線測試,可以發現在發佈後約 20 天其流量就有顯著的成長,而單日最高的造訪人次則發生在 4/4 號為 313 人。有趣的地方是在於「直接流量」佔了 96.67 % (=3524 人次的造訪)、「推薦連結的流量」只佔了 2.23 %(=71 人次的造訪)而那「搜尋引擎的流量」只有 0.80 %。所以除非你的 extension 是殺手等級的,要不然其實「推薦」及「搜尋引擎」所帶來的流量其實相當微小,像我還有 2 % 的流量是因為學姐在 Facebook 上轉貼所致的。

而絕對不重覆訪客的則是 719 人,平均一天有 24 個人使用 / 得知這個 extension。這其實是有原因的,因為外掛的同質性很高,在 Chrome extensions 上可以發現與 Facebook / Blocker 之類有關的外掛非常多,所以像我們這些後輩其實發展的空間就很有限。不過我覺得我的外掛在一個月之內從無到有還能有這樣的市場主要是因為具有差異性,雖然沒有主流 blocker 這麼的 powerful,但是就是因為小巧且能做到他們做不到的事情(Regex + keyword matching + block groups / your own / friends’ walls),所以才會一直有所成長。

那因為這個本身就是 Chrome extension,所以 95.18 %(=3459 人次) 是 Chrome 用戶、 0.55 %(=10 人次)則是 Rockmelt 用戶,其他的就不知道是怎麼連進來的了=_=,更難以置信的就是 IE 還有 3.88 %(=141 人次)。所以這邊可以發現,來看這個 Chrome 外掛介紹的使用者第二多的就是 IE 用戶,所以 IE 的用戶真的是「很多」,非常的多,多到你無法想像,所以做 Web 的雖然討厭 IE series … 但是使用者是無知的,為了這廣大的市場,也只能下海去了。

接下來有個很值得探討的就是使用者的分佈,我想主要的原因是因為我是台灣人,而且該外掛的資訊曾在 Facebook 傳遞了一下子,再加上外掛介紹有配上中文,所以用戶第一多是從台灣(=664 人次)來的應該是可以接受,但是有趣的地方不是在這邊,是在除了台灣以外的使用者,因為有關 Facebook Blocker 的介紹真的是少之又少,能夠得知這個外掛的方法就只能透過 Chrome Extensions 的平台,儘管如此,2 ~ 8 名的國家分別是泰國(=551 人次)、丹麥(=380 人次)、波蘭(=296 人次)、美國(=279 人次)、德國(=200 人次)、義大利(=146 人次)及埃及(=108 人次),其實這裡我只有做一個小小的動作,那就是國際化,整個外掛的主要語言設定是用「英文」,而外掛介紹也是先用「英文」再用「中文」。所以就算是英文不好的開發者,在介紹自己產品的時候就算逼不得已 Google Translator 也是要給他用下去,即使文法或是單字意思不太對。因為這對於以英文為母語或是第二外語的使用者來說,他們會覺得非常親切甚至是試用你的產品。英文真的是你傳播資訊最好的媒介,如果當初我沒有做這個決定,那現在這個外掛大概也就只能停留在小小的台灣了。

所以,

  1. 不要忽略你的蠢主意,因為你不知道你的一個小小的想法,會因此為你帶來多大影響。
  2. Release Early、 Release Often,比起已經搶佔市場的先行者來說,你能做的只有提早釋出你的想法並與以實作,然後持續與使用者互動並以他們的意見及建議來更新版本,讓他們認為參與其中並對這個專案有所貢獻,以建立第一批的擁護者。
  3. i18n(Internationalization、國際化),這邊的國際化其實是指想法上的國際化,因為如果一個專案只是單純的中翻英或是引入多國語系只能說是國際化的一個手段而已,我想表達的是在你在構思產品或專案時候,要想的寬廣一點,不要只是限制在自己所居住的區域或是先預設了使用者的立場,這樣子不僅會縮減你可能的市場也跟不上這個世界的腳步,導致最後的失敗。以我的 Facebook Blocker 為例,我的目標就是 Facebook 上面的使用者,但是使用者使用的語言很不一致,所以除了以英文為主軸來介紹這個 Extension 之外,整個外掛不會讓使用者因為先天上語言的差異而無法使用,這是因為一開始整個 Extension 就設計的非常簡單,用簡單的色塊及小圖示來提示使用者整個操作的流程,如此而已。
  4. Web,它是一個很棒的戰場,就算是個人也能夠站在 Web 上與全世界競爭,也是一個很適合曝光自己的平台,所以無論如何,Please be involved。

以上就是我把從這次製作 Extension 所得到的一些數據及觀察到的現象做一個總結,希望能對有心要寫 Extension 的人會有一些幫助。

Written by EragonJ

April 10th, 2011 at 3:00 pm

[News] How Fast Is Your Site? Measure It With Google’s Page Speed Online

leave a comment

原文 From TechCrunch , Image Credit

在 2011/03/31 的時候 Google 發佈了一個新的玩具叫做「Page Speed Online」,它提供了一個快速又簡單的方法來測量連結你的個人網站時的速度。原本這個功能是要透過 Google Chrome 的擴充功能才能夠測試的,不過現在 Google Labs 發佈了一個全新的方式,讓你在任何地方都可以分析你的網站並接受最即時的回饋資訊供你參考,讓你知道要如何調校網站並使其變得更快。

雖然在網路上有各式各樣的工具,不過它們都只有測量伺服器回應速度(Server Response Time),而且測量結果也和真實情況有所落差,都不夠正確。例如說速度極快的伺服器可能在極短的時間內就能夠回傳 HTML ,不過您的網站訪客可能還是要花許多時間在等待圖片的下載或是 Javascript 的執行。相較之下,Page Speed Online 使用了以 webkit 核心為基礎的輸出呈現器(Renderer)來測量所有網站上的元件的效能。

Page Speed Online 非常容易使用,只要在它的頁面下輸入你的網址就可以得到即時的建議回饋,告訴你要改進網站上的哪些部分來提昇效能。而 Page Speed Online 會給你的網站一個分數(滿分是 100 分),而分數的高低則取決自其建議出現的優先順序。除此之外,Page Speed Online 還可以從行動裝置的角度來測量效能,提供不同的效能提昇建議,這是因為行動裝置的 CPU 多比桌機的 CPU 無力,所以在評分上著重的部分就會有所不同。

效能是一個非常重要的關鍵,因為我們都知道,每個人都會把挫折感和等待網頁載入的時間聯想在一起,所以網站的擁有者特別需要關注效能的問題。近年來「盈收和網站連線速度之間的關聯性」一直不斷的被人們提出、強調。改進網站效能是一個提昇 網站瀏覽量(Pageviews)網站轉換率(Conversions)還有銷售率(Sales)最簡單的方法。以下提供幾個實例以供參考:

  • Yahoo 發現 400 (ms) 的改善能夠提昇 9% 的 pageviews
  • Firefox 減少了 2.2 (s) 的平均頁面載入時間就提昇了 15.4 % 的 download conversions
  • Shopzilla 減少了 5 (s) 的載入時間就提昇了 25 % 的 pageviews 還有 7 ~ 12 % 的盈收

Google 一直都致力於讓整個網路變得更快速,這不只是因為它是最快速的搜尋引擎,還因為它在它的排名演算法中引入了網站速度來當做評比的其中一個因素,以鼓勵其它網站也變得更快。而創投家 Fred Wilson 也在一文中提到「網站的連線速度」是創業者必需考慮的首要目標

【評】
剛看到這個玩具的時候感覺還蠻新鮮的,因為以前的檢測工具都只有做到效能的評比,提供了一堆搭配專有名詞的數據給你,而你卻不知道要從何下手去做改進,有種幫忙只幫一半的感覺,比完全沒幫忙還糟。但是 Page Speed Online 就不一樣了,(下圖是我檢測 http://eragonj.hax4.in 的結果),從圖中可看出拖累效能的各種因素,以重要程度由大到小排序,如此一來我就可以知道就我網誌來說,我最需要解決的就是圖片的問題。

而 Page Speed 也很貼心的為我找出產生問題的頁面並提供改善的方法,甚至是為我計算出可以節省的頻寬,真的是非常的方便。

這個小工具其實對於 startup 來說非常的重要,因為就像 Fred Wilson 所說,「網站的連線速度」是創業者必需考慮的首要目標,如果初期就因為 loading 的問題讓 visitors 留下不好的印象,那網站做的再棒、再豐富也是惘然。如果大家有興趣也可以自己測試一下自己的網站,看你能拿到幾分吧 ;]

Written by EragonJ

April 3rd, 2011 at 5:57 pm