2.3.1 桌面瀏覽器的視口
在桌面瀏覽器中，假設某個頁面的寬度設定為自適應的100%: html ，這意味著html寬度始終與瀏覽器寬度保持一致。
同時，瀏覽器寬度也等價於瀏覽器可視區域寬度，所以在桌面瀏覽器中，瀏覽器可視區域大小決定了頁面的布局。所見即所得，瀏覽器視窗多大，就會以多大的尺寸影響頁面布局。我們稱這裡的可視區域大小為布局視口（layout viewport），或者簡稱為視口（viewport），如圖2-14所示。
在本書後面的內容中，如果沒有特別說明，所稱視口皆為此概念。當然，如果頁面布局為固定寬度布局，頁面布局就不會受到視口大小影響，但是在視口之外的內容，需要通過控制瀏覽器視口的滾動欄才能看見。
桌面端視口的特點是，瀏覽器區域大小受限於顯示器螢幕大小，這也意味著頁面的寬度不會超過瀏覽器螢幕寬度。讀者可能會納悶，為什麼上面這麼顯而易見的事情會稱為「特點」？因為在移動裝置上不是這樣的，也無法做這麼乙個設定。
假設在100%寬度的body內還有一些占用寬度為10%的元素，如果以桌面視口的定義，10%寬度的元素實際寬度最大只能是系統解析度的10%，則在1920×1080的顯示器上瀏覽器最大化的情況下，該元素最大寬度為192 px。若在iphone 4上瀏覽這個頁面，如果iphone 4仍然繼承的是桌面視口的設定，那麼使用者看到只是乙個32 px的元素，這是根本是無法識別的，這樣的容器也不可用。
所以，移動裝置的視口定義與桌面並不相同，但視口同樣是用於控制頁面布局渲染的。
對於移動裝置上的瀏覽器來說，仍然需要乙個區域用於控制頁面的布局渲染。只不過這個區域不再以螢幕尺寸作為限制。
以iphone 4為例，safari渲染頁面布局的預設寬度為980 px（css畫素）。但是，使用者可能覺得並非如此，因為當使用者用safari開啟乙個**桌面版後，他看到的頁面寬度剛好是與螢幕寬度相等的，如圖2-15所示。但是iphone 4的系統寬度解析度不是320 px嗎？
其實之所以這樣是因為瀏覽器做了兩件事，如圖2-16所示：
（1） 用980 px畫素寬度渲染頁面；
（2）將頁面縮放至寬度與系統寬度一致。
使用者使用手勢縮放頁面也是同樣的原理。瀏覽器和使用者在這裡並沒有改變頁面（準確來說是視口）的大小（size），只是改變了視口的縮放比例（scale）。
但是，瀏覽器使用預設的980 px去渲染頁面並非是萬能的。例如，當頁面比較窄時（如只有320 px寬），頁面效果會非常糟糕，如圖2-17所示。
設計人員希望以頁面的寬度來渲染頁面，並能自然自適應到系統寬度。於是手機廠商（最早是在safari中）提供了乙個名為viewport的標籤設定視口大小。例如，在上乙個用例中，當我們想以320 css畫素渲染頁面時，可以在
標籤中加入meta標籤，並設定如下：
在前幾節中常說的「系統解析度」就是視口大小，有興趣的讀者可以去viewportsizes.com上查詢自己感興趣的裝置的視口大小。
大部分情況下我們都希望以系統解析度的寬度來渲染頁面，以盡可能地避免縮放，以及正確地響應裝置（例如，頁面布局是在320 px寬度的限制下進行設計的，我們當然希望裝置以320 px寬度來渲染布局，而不是用980 px渲染後再進行縮放）。問題是不同裝置的系統解析度是不一致的，即使在同一種裝置上，橫豎兩種持握方式也會讓渲染方式不同。
但是，我們可以不用關心具體的數值，只要告訴瀏覽器：「無論什麼裝置，什麼樣的持握方式，請按照系統解析度寬度渲染。」
於是我們可以將width的值設定為device-width。例如：
《高效能響應式Web開發實戰》一1 4 定義響應式
我們有沒有可能採用一種最直接的方式，用一句話闡述響應式在前端開發中究竟代指哪些技術？如果非要往前追溯對響應式技術的定義，一定要談alistapart 3 上的被奉為經典的兩篇文章，即 responsive web design 4 和 a dao of web design 5 在 responsi...
《高效能響應式Web開發實戰》一1 5 本書任務
圖1 5與圖1 6給出的是本書中要完成的頁面設計稿。這是一位產品經理為本書而設計的。2015年年初sitepoint 6 發布了一篇有關2015年網頁設計趨勢的文章 the big web design trends for 2015 7 文章中歸納了在2015年網頁設計中將會出現的趨勢性特徵，如大...
高效能web優化（一）
資料在網路上傳輸的時間分成兩部分，一部分是使用者請求的資料報到達伺服器的時間，另一部分是伺服器的回應資料經由網路傳送給客戶端的時間，這兩部分的時間稱為響應時間。響應時間的大小取決於頻寬和資料量的大小。響應時間的其中大部分時間消耗在伺服器端，我們用吞吐率來衡量這部分時間，即每秒處理請求數。吞吐率影響因...