如何令網站更快更吸引(一)?

淺談 web.dev 2020 提出的網站性能基準(一):最大內容繪製LCP
Photo by Bench Accounting on Unsplash

今年因為全球肺炎持續肆虐,令到不少的公開活動都轉戰線上播放,而Google 一年一度的 web.dev LIVE 亦不能倖免。不過,轉為線上舉辦活動並不代表內容有所失色。

Google 經常更新網站性能的指標和工具,務求在衡量網站方面的用戶體驗與時並進,使得無論各類用家、企業、開發者在哪種網絡環境、使用哪種設備瀏覽也好,亦能獲得最佳的網站使用體驗。那讓我們來看看今年Google 提出的網站性能基準,Core Web Vital吧。

今年 的 Core Web Vital 有三項,包括:

  1. LCP — Largest Contentful Paint 最大內容繪製;
  2. FID — First Input Delay 首次輸入延遲;
  3. CLS — Cumulative Layout Shift 累計版面配置轉移;

Largest Contentful Paint 最大內容繪製

LCP 是一個量度網頁載入速度的指標。相比起First contentful paint (FCP) 量度從頁面開始載入到屏幕上,呈現頁面內容任何部分的時間,LCP量度頁面載入時,主要或是最大的內容載入/繪製,並展示到網站用戶可見視野範圍的時間。快速的LCP象徵著能夠使用戶確信信該網頁頁面對他們有用

要理解甚麼是 LCP,我們可以透過在哪些狀況下,會影響網頁載入LCP 的速度:

  1. 緩慢的伺服器回應時間
  2. 阻礙網頁繪製的JavaScript 和 CSS 檔案
  3. 緩慢的資源載入時間
  4. 客戶端的網頁繪製

很多時,圖像往往是當網頁完成載入時所顯示的最大元素,亦是影響網頁載入速度的元兇。企業會傾向使用一些容量很大,但解析度較高的圖片,為求展示一些清晰、漂亮的產品照、宣傳圖像,吸引客戶的關注,或使客戶能夠更能理解產品的細節。

但其實在不少設備的Retina屏幕上,用戶都無法分辨高解析度和一般解析度的圖像,而太大容量的圖像,會阻礙網頁的載入,使得客戶的使用體驗質素下降。所以,要將圖像解析度,與網頁的載入速度作出相應的平衡,至為重要。將圖像轉為WebP 這類能夠減少檔案大小、但仍然維持和JPEG格式相同圖片品質的類型,亦能夠減少圖像檔案在網路上的傳送時間。

另外,JavaScript 、 CSS 這裡幫助網頁建構的檔案,它們的載入先後、所需時間,亦都和網頁載入的速度有關。Google 亦建議除了這些的檔案大小外,亦可以留意其放置來源的回應時間是否理想,例如放置在CDN(內容傳遞網路),就能夠利用最靠近每位網頁使用者的伺服器,更快、更可靠地將圖片、影片等檔案傳送給用家。

那什麽才能得到好的LCP分數? Google 建議網頁開發者,應該努力使得網頁在頁面開始載入的2.5秒內,完成最大內容繪製(LCP)。2.5秒-4.0秒被視為需要改進,而多過4.0秒去完成最大內容繪製則視為表現差劣。而為了確保達到滿足大多數用戶這個目標,衡量準則為在移動裝備和桌面設備上,整個網站的內容要有75百分位數能得到好的LCP分數。

可以檢測實際環境和測試環境LCP的工具,有以下幾個:

Field tools 

Lab tools 

Ref:

https://www.youtube.com/watch?v=AQqFZ5t8uNc

https://www.chromestatus.com/feature/5666250908762112

https://web.dev/lcp/


聯絡我們:
主頁: https://ones.software/hk/
電郵地址: hello@ones.software
電話號碼: (+852) 5538 3410
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
Phone number: (+852) 5538 3410

]]>

好的房間預約系統有什麽重要元素?

之前的文章提過,一個智能辦公室的建立,會議室/房間預約系統是基本元素,那麼有市面上林林總總的房間預約系統,怎樣選擇那些是值得投放資金購入的軟件?

如何能夠令管理者對公司資源運籌帷幄,預約系統的界面設計至為重要。假設公司 有 50 間房間,一般坊間的預約系統就會把這 50 間房間的狀態、預約資料等,以列表的形式平白地列出。這樣的列表雖然能夠提供所有資訊,但是表現方式並不直觀, 管理者往往要消化大量數據,容易過於疲勞,甚或看漏一些資訊,導致資源錯配等問題。

我司經過多番研究,銳意打破傳統用列表數據的形式,採用全新的界面概念去管理房間,通過自家開發的 3D 地地圖引擎,讓用戶可以直接管理房間,毋須花費時間在 數百列數據中尋找所需的房間資訊。


傳統預約系統界面設計

如何能夠令管理者對公司資源運籌帷幄,預約系統的界面設計至為重要。假設公司 有 50 間房間,一般坊間的預約系統就會把這 50 間房間的狀態、預約資料等,以列表的形式平白地列出。這樣的列表雖然能夠提供所有資訊,但是表現方式並不直觀, 管理者往往要消化大量數據,容易過於疲勞,甚或看漏一些資訊,導致資源錯配等問題。

我司經過多番研究,銳意打破傳統用列表數據的形式,於Bookings ONE採用全新的界面概念去管理房間,通過自家開發的3D地圖引擎,讓用戶可以直接管理房間,毋須花費時間在數百列數據中尋找所需的房間資訊。

簡化地圖設計 

現時市面上普遍聲稱擁有地圖功能的軟件,都是利用客戶提供的圖片配合特定的軟件去製作地圖。我司認爲這些客制步驟過於耗時,亦牽涉不少人手操作,使製作這類地圖的成本大增。

爲減低企業使用 3D 地圖的成本,我司致力簡化地圖的製作步驟。我司成功研發出獨家技術,於 SVG 圖片中直接找出地圖以及房間的形狀,經過軟件處理後就能夠產生 3D 地圖。 

跨平臺支援 


Bookings ONE的地圖引擎硬件需求低,可在不同平台上運行,包括 iOS、Android、 Windows,以至 Smart TV,大大增加系統的應用範圍; 我們的管理頁面支援手機界面,管理員可通過手機,進行大量的房間管理; 

透過智能電視能夠顯示各樓層房間的狀態,例如使用狀況、房間容量等即時信息,用戶也能使用觸控式智能電視,透過地圖直接預約房間,使整體的預約過程更流暢直接;

Bookings ONE亦全面支援 IoT 儀器,通過與 IoT 儀器進行鏈接,顯示房間的即時資訊,例如溫度,濕度等。用戶能夠通過 3D 地圖,直接了解辦公室的實際環境情況 。


除了以上所提到的細節外,Bookings ONE 還有更多的功能和優勢,務求提供最好的用戶體驗給企業,不論是管理層還是員工的需求都能一一滿足,從而提升公司形象和員工整體工作效率。

欲免向隅,馬上聯繫我們: hello@ones.software / (+852) 5538 3410, 亦可到 Bookings ONE 官網了解更多 :https://ones.software/hk/bookings-one/

聯絡我們:
主頁: https://ones.software/hk/
電郵地址: hello@ones.software
電話號碼: (+852) 5538 3410
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
Phone number: (+852) 5538 3410

]]>

甚麼是前端開發?

(Ref:https://flatironschool.com/blog/front-end-vs-back-end-development/

如果有接觸過網頁開發的讀者,或者會聽過很多不同的專有名詞,其中不少得Front-end (前端) 和 Back-end (後端)這兩個字詞。有一些網站可能只需要設計師和前端開發者,有些則需要後端開發者和測試人員等等,那究竟前端和後端如何分辨?首先,讓我們搞清楚前端開發是什麼一回事。


Front-end 前端開發

(Ref: http://devana.rs/blog/front-end-interaction-designer/

前端包含所有用家能夠見到、繼而互動的畫面,而現今的網頁主要仍是利用HTML、CSS 和 Javascript 來建構這些畫面。

HTML相信即使不是程式員都不陌生,HTML 全名是 Hypertext Markup Language(超文件標示語言),是建立網頁的標準標示語言,簡單來說就是一個網頁的骨幹。早期的網頁,如這個有關WWW萬維網的網站(連結),主要只有文字,充其量會有一些圖像,所以畫面比較乏味,如下面的例子1a)。於是,就有CSS的誕生了。

1a) 只使用HTML的網頁 :https://codepen.io/OnesSoftware/pen/wVKvxx

CSS 於 1998年出現, 全名是 Cascading Style Sheets(層疊樣式表), 一種用來為例如HTML、XML 等這些結構化文件添加樣式的電腦語言,亦即是一個網頁的表皮/裝飾

在CSS 誕生前,要控制網頁如何顯示,就要在HTML檔案內包含顯示的資訊,例如字型的大小和顏色、背景應該是怎樣的、如何排列等等,這些都必須逐一在HTML檔案內列出。有時會因為資訊重複列出而令到網站過份冗長。CSS的出現使開發者可以將大部分這些顯示用的資訊中隔離出來,從而簡化 HTML 的檔案。這些資訊會被放在一個輔助的,用CSS語言寫的檔案中。理想來說, 現在的HTML檔案中應該只包含結構和內容的資訊,而CSS檔案中就包含樣式的資訊,以達致分工的目的。

1b) 使用了 HTML 和 CSS 的網頁: https://codepen.io/OnesSoftware/pen/rXOajM

在上面的例子1b),是將純粹使用HTML作為框架的 1a),加上 CSS 的裝飾,例如文字顏色、 邊框和背景顏色。

網頁的骨幹和表皮都有了,已經可以製作一些漂亮的靜態頁面,但如果要有一些能夠互動的部分,例如持續取得一些即時的資訊、儲存數據,甚至只是按下按鈕時彈出對話框,只用HTML和CSS的話都難以實行。 JavaScript 就正正能夠補充給予網頁「肌肉」並得以「活動」這個角色了。

1995 面世的 JavaScript 主要用作管理網頁的內容以及用戶的操作行為,而由於不同PHP、ASP的伺服器端手稿語言,不需要伺服器的支援也能夠在用戶的瀏覽器上運行,所以的確能夠減少對伺服器的負擔。

1c) 使用 HTML 、CSS 和 JavaScript 的網頁:https://codepen.io/OnesSoftware/pen/WVrwbv

在上面的例子 1c) 中,加了JavaScript 的輔助後,按下按鈕就會彈出「clicked」的對話框。

UI 與 UX 的比較

時至今日,前端的技術不斷轉變, 中間有過Flash、 Silverlight 這類 Web前端應用程式的開發解決方案曾經稱霸多年,卻因為手機平台不支援等因素而被淘汰。反而最基礎的 HTML、JavaScript、CSS不斷改進,以致如播放實時影片、繪圖、動畫等的功能都無須額外方案處理。而現在有不少 framework 和 library,如 ReactJS/Bootstrap 等等,能夠提供規格化的開發資源,使得開發的效率和水準得以大大提升。

前端開發者的主要職責,除了負責網頁的內容如何擺放,亦即所謂的 User Interface(使用者介面),也要照顧到用戶的瀏覽體驗,那就是 User EXperience(使用者體驗),這就要和專門的 UI、UX 設計師合作才得以處理得宜。前端開發者也要和後端開發者處理前後端之間的編程介面(API),使得有需要數據得以儲存、獲取和處理等等。

有興趣理解前端開發者的技術路線圖,可以看:

https://github.com/goodjack/developer-roadmap-chinese/blob/master/chinese-version/images/frontend.png

Ref:

https://zh.wikipedia.org/wiki/HTML

https://zh.wikipedia.org/wiki/%E5%B1%82%E5%8F%A0%E6%A0%B7%E5%BC%8F%E8%A1%A8

https://www.pluralsight.com/blog/film-games/whats-difference-front-end-back-end

https://flatironschool.com/blog/front-end-vs-back-end-development/

更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,我們的網址是: https://ones.software

ONES Publication
We share what we have learned about app and web development. Find us in ones.software. Email: hello@ones.software

聯絡我們:
主頁: https://ones.software/hk/
電郵地址: hello@ones.software
電話號碼: (+852) 5538 3410
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
Phone number: (+852) 5538 3410

]]>

Angular 8.0 迎來的新 rendering engine:Angular Ivy

近年大約六個月一次的 Angular 重要版本更新很快就要來了! 其中最矚目的莫過於Angular v2 第三代的 rendering engine : Angular Ivy ,當中有什麼值得我們留意的?


Angular Ivy 早在 2018 年的 4 月 的 Ng-conf 中就公佈了。有新的 rendering engine 出現,官方所強調的都莫過於容量細、速度較快、編碼層面上更簡單。不過,有幾點是 Angular 今次想透過 Ivy 來解決的:

  1. Ivy 為了改善用家體驗,使瀏覽器需要下載的內容更少,從而使應用程式的啟動時間加快。
  2. Ivy 通過簡化 API 和 構建系統(build system),幫助開發人員更容易編寫源碼。
  3. Ivy 通過將編譯管道(compilation pipeline)變得更平易近人,使得第三方的開發更為可能,有助 Angular 社區發展。

不過新事物的出現,程式員第一樣關心的事情就是用不用改之前的代碼?答案是:

100% Backwards Compatible!

皆因 Google 本身也有 600+ 個服務都是用 Angular 來編寫,Google 亦不容許當新的 Angular 版本推出時,仍然使用舊的版本,所以 Angular 幾乎不可能做出一個具斷裂性的改變,所以各位程式員請放心使用。

在編碼層面上,Ivy 有幾個重大的更新,其中包括:

  1. Locality
  2. Tree-Shaking
  3. Low Memory Footprint

Locality

「locality」看來是 Angular 開發團隊所提出的新名詞,這裡容許我譯作為局部性局部性的意思是指當 Angular 的編譯器(compiler)翻譯模板(template)的時候,編譯器只會允許使用對其來說是 屬於該局部local)的信息,亦即是那些由其 component decorator 與 class 所定義的信息。當需要重新編譯某一組件時,因為不直接關聯的依賴(dependency)不會牽涉在編譯的過程之內,所以就能夠實行累加組建(incremental build,毋須每次都要渲染一整個全新的 virtual DOM tree,重新編譯的時間較短,產生出來的代碼體積亦較小。

Ng-conf 亦提到局部性的其他好處:

  1. 允許第三方的 library 將預先編譯好的模板,直接發送到 NPM。對於使用這些 library 的應用程式來說,能夠簡化和加速編譯過程。
  2. AoT / JIT 所產生代碼近乎一樣,使開發、測試時能夠容易地合用這兩種代碼。
  3. metadata.json 消失了,這大大簡化第三方 library 的發佈及開發,以及和現存工具鏈(tool chain)的互用性
  4. 大量減省編譯圖(compilation graph),這能簡化組建工具,重建大型項目的時間亦能縮短。
  5. 允許元編程(meta-programming),能夠令 component 可以在執行期(run time)內創建,Higher Order Components 亦能完全實現。

Tree-Shaking

比起大量運用 Virtual DOM 的主流 framework,Ivy 所用的 incremental DOM 更有利於Tree-Shaking。Tree-Shaking 是 死碼刪除 (Dead code elimination/DCE) 的一種, 它的用途是移除對程式執行結果沒有任何影響的源碼。不過相對於傳統DCE 只是移除永遠不能執行的代碼,Tree-Shaking 能夠從程式的入口點開始,並且透過 靜態程式分析 (Static program analysis)來移除不會執行的代碼。 上代的 Renderer2 和 Ivy Render 同樣都有運用Tree-Shaking,但 Ivy 將源碼分解為更細小、更原子化的 function,更有利 Tree-Shaking 的運用,從而產生更小的 bundle。

以下的 Angular 特性都是能夠被 Tree-Shaking:

  • Template syntax
  • Dependency injection
  • Content projection
  • Structural directives
  • Life cycle hooks
  • Pipes
  • Queries
  • Listeners
Source: ngConf-2018 keynote

譬如上圖的例子,由於只有 someFnmain 引用,而 unusedFn 沒有,所以最終Ivy Render 編譯出來的bundle 就不會包含unusedFn這個 function了。

Source: ngConf-2018 keynote

但如果 unusedFn 牽涉到條件上的檢查,即使條件最終為false而不會用到unusedFn,Ivy Render 編譯出來的bundle 仍然會保留unusedFn。基於靜態程式分析只會嘗試在不實際運行程式的情況下,找出所需內容,而它通常要假設最壞的情況以確保編譯出來的程式是正確無誤,Ivy Render並不會清楚在 runtime 時該值為何,就會保留unusedFn。所以編寫源碼時就要避免這種情況,不要過份依賴 Ivy Render 的 Tree-Shaking。


Low Memory Footprint

Memory Footprint ( 記憶足跡指的是一個程式在運行時所需/引用的主記憶體數量,而使用 incremental DOM 的 Ivy 就能降低記憶足跡。

主流 framework 所使用的 virtual DOM 在每一次重新渲染的時候,會整棵DOM tree 也會重新建立一次。

(From: https://blog.nrwl.io/understanding-angular-ivy-incremental-dom-and-virtual-dom-243be844bf36

而 incremental DOM 因為當 DOM 節點有加減才需要分配記憶體,除此之外就無需使用內存空間。而由於大部分的渲染和模板調用( template calls)都毋須DOM 節點上的改變,相對地就能大幅減少運行程式時的記憶體。

(From: https://blog.nrwl.io/understanding-angular-ivy-incremental-dom-and-virtual-dom-243be844bf36

Angular v8-rc4 版本在 May 16, 2019 已經發佈,Angular v8 相信很快就會推出,我們相當期待正式版的 Ivy rendering engine 讓程式員毋須大量重寫源碼,就能夠更有效運用前台資源。

更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,我們的網址是: https://ones.software

Ref:

https://juristr.com/blog/2019/05/Angular-8-and-the-Future-NGConf-2019-Roundup/#ivy-features

https://is-angular-ivy-ready.firebaseapp.com/#/status

https://blog.angular.io/a-plan-for-version-8-0-and-ivy-b3318dfc19f7

https://blog.nrwl.io/understanding-angular-ivy-incremental-dom-and-virtual-dom-243be844bf36

https://medium.com/grapecity/what-to-expect-in-angular-8-940b217b63cb

https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking

https://www.telerik.com/blogs/an-early-look-at-angular-8-get-ready-for-opt-in-ivy-preview

https://www.zhihu.com/question/266923267/answer/316279829

https://www.telerik.com/blogs/first-look-angular-ivy

https://juejin.im/entry/5c01665a51882516cd70c661

https://blog.nrwl.io/metaprogramming-higher-order-components-and-mixins-with-angular-ivy-75748fcbc310

https://blog.angularindepth.com/ivy-engine-in-angular-first-in-depth-look-at-compilation-runtime-and-change-detection-876751edd9fd

https://blog.angularindepth.com/inside-ivy-exploring-the-new-angular-compiler-ebf85141cee1

]]>