Firefox 預定在 11 (現在是 8) 支援 SPDY Protocol:「(SPDY) Implement SPDY protocol」,除了 Google Chrome 自家瀏覽器支援外,總算有個大的也要支援了...
所以現在除了 Chrome、Kindle Fire 以外,又多了 Firefox 支援...
幹壞事是進步最大的原動力
Firefox 預定在 11 (現在是 8) 支援 SPDY Protocol:「(SPDY) Implement SPDY protocol」,除了 Google Chrome 自家瀏覽器支援外,總算有個大的也要支援了...
所以現在除了 Chrome、Kindle Fire 以外,又多了 Firefox 支援...
jQuery 1.7 前幾天丟出來了,可以看到很多對 event 操作的改善,包括效能與功能 (新增了 .on()
與 .off()
):「jQuery 1.7 Released」。
另外今天又看到瘦身計畫:「Building a Slimmer jQuery」,希望把一些「應該要拿掉」或是「應該要被修正」的問題處理掉... 所以在 jQuery 1.7 標為 Deprecation,預定在下個主版本就會處理掉這些問題。
目前 (對我家) 最主要的影響應該是 .live()
會被拔掉,以及之前有使用 .attr('value')
取 current value (要 current value 應該用 .val()
取得)。
看起來是往好的方面進行...
在「Google +1 Button Performance Review」這篇中,Aaron Peters 對 Google +1 按鈕所提供的方法感到疑惑,因為官方所提供的方法效率其實並不好。
首先先拿出官方的 sample:
<!-- Place this tag in your head or just before your close body tag -->
<script type="text/javascript" src="http://apis.google.com/js/plusone.js"></script><!-- Place this tag where you want the +1 button to render -->
<g:plusone></g:plusone>
即使 Google 給了建議「Place this tag in your head or just before your close body tag」,但這仍然會延遲 onload 的時間。
另外一個更糟的是,目前 Google 的伺服器會把使用者從 http://apis.google.com/js/plusone.js
導到 https://apis.google.com/js/plusone.js
,多一個重導又使得 onload 時間又更久了。接下來是噴飯的「Cache-Control: private, max-age=360
」,這使得 proxy server 無法 cache,而且因為 cache 的時間過短而經常要向 server 要資料。
再來是這個 js 沒有 minified,造成 gzip 後仍有 628bytes 的差距。然後在這個 script 裡面還可以看到特地為 Blogger「減速」使用 sync loading (喔喔)。
從以上的情況,可以看出來 Google +1 這個產品符合了不少產品成功的要件... XD
Anyway,真正的重點在文章最後面,他有引用一段 async loading 的程式碼讓大家用,雖然不能解決所有問題,但至少可以讓 onload 事件儘快觸發... (這是其中一個很大的問題)
這是之前在 Slashdot 上看到的消息,主要是因為 Linux 上的 Firefox 6 (還很久...) 將能夠使用 GCC -O3
編譯:「Firefox On Linux Gets Faster Builds — To Be Fast As Windows」。
在 VirtualBox 裡面裝好 Windows 後用 Firefox 4 (把 extensions 都裝上去),居然比 Linux 下 native Firefox 還快,就有種淡淡地哀愁...
繼續等吧...
Steve Souders 公開新網站 HTTP Archive。類似於 Internet Archive 紀錄網站的每個時間點的樣子,HTTP Archive 紀錄網站每個時間點的 HTTP 效能:「Announcing the HTTP Archive」。
目前蒐集了 ~17000 個網站,每個網站約每兩個禮拜分析一次,選擇的網站來自 Alexa Topsites、Fortune 500 (2010)、Quantcast。翻了自家的站台,看起來是從 2010 年 11 月就開始跑...
也因為紀錄了很多網站,所以也有些有趣的數據可以在「Interesting stats」這邊看到 (有日期可以選)。
Mobile Perf bookmarklet 在 Jacky 的 Twitter 上看到的工具,是由 Steve Souders 整理出來的,包括了七個 bookmarklet 工具,執行後就會像這樣:
拿來分析 performance issue 還不錯...
從 ihower 的 Twitter 上看到的,看起來相當好用的東西:「Head JS :: The only script in your HEAD」,官方網站的程式碼就相當容易懂了,這邊就不再列出範例了...
由於以往要作到類似效果並不太容易 (okay,我知道某 library 可以做,但... *消音*),Head JS 的出現以及好用的程度 (容易上手),可以使得網站大幅提昇頁面讀取速度。
手上舊的 project 可能就放著吧,但新的 project 應該會用...
在「The State of Web Performance Optimization – 2010」這篇文章裡提到了 2010 年的 Web 最佳化統計資料,由於這是 WebPagetest 的統計資訊,裡面有很多有趣的統計資料...
看起來網頁愈來愈糟糕 XD 像是 Page Size 愈來愈大,Number of Requests 數量變多,Image Compression 的比例反而變少,以及 Combine JS/CSS 的分數愈來愈低,而整體的 Page Load Time 也變高了...
不過也有不少項目是變好了,主要都是對開發沒有增加難度的... 像是 Keep-Alive 設定、Text Compression (GZip) 以及 Cache Static Content 都可以在 server side 設定一次就解決。人果然是懶惰的,會影響到開發的東西果然都沒什麼進展 XD