何為微瀏覽器？微瀏覽器同樣可以訪問網站鏈接、解析HTML并產生用戶體驗的另一種類型的user-agent(用戶代理)。但它與傳統瀏覽器有所不同，主要在于：它的HTML解析能力有限，而且渲染引擎非常集中。它想打造的用戶體驗并不是交互式的，而是具象式的，即為了告知用戶URL的另一端到底有什么內容。在日常中，微瀏覽器無處不在。

作者 | Colin Bendell

譯者 | 蘇本如，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

你已經到處都看到過它——在推特的某條推文提及的某個網站的小型縮略圖預覽中，在Slack的某個頻道或者WhatsApp的某個群聊的擴展描述中。

圖1：群聊中的預覽圖給我們提示了真實網頁的大概外觀。

這些鏈接預覽（link preview）對大多數人來說司空見慣，以至于我們幾乎忽略了網站設計對生成預覽可能產生的影響。然而，從吸引新用戶和增加參與度這個角度來考量，這些預覽可能是最有影響力的因素，它們的重要性可能比搜索引擎優化（SEO）還要重要。更令人擔憂的是，大多數網絡分析都對這種類型的流量視而不見，因而無法向你展示這些微瀏覽器是如何與你的網站進行交互的。

在這一年行將結束之際，我想在這里提出五個對于微瀏覽器來說至關重要的問題和觀點，它們是每個WEB開發人員都應該了解的。

什么是微瀏覽器？它們與“普通的”瀏覽器有何區別？

我們非常熟悉的主流瀏覽器有Firefox，Safari，Chrome，Edge和Internet Explorer。除此之外，還有很多使用Chromium作為渲染引擎，但是提供了獨特用戶體驗的新型瀏覽器，如Samsung Internet或Brave。

與之相比，微瀏覽器是同樣可以訪問網站鏈接、解析HTML并產生用戶體驗的另一種類型的user-agent(用戶代理)。但它與傳統瀏覽器有所不同，主要在于：它的HTML解析能力有限，而且渲染引擎非常集中。它想打造的用戶體驗并不是交互式的，而是具象式的，即為了告知用戶URL的另一端到底有什么內容。

創建鏈接預覽并不是什么新生事物。Facebook和Twitter早在10年前就在它們的帖子中添加鏈接預覽了。這些曾經是鏈接預覽的主要用例：營銷團隊創建 backlog 條目，以便從Twitter Cards 和Facebook的Open Graph注釋中采用不同的微數據。linkedIn同樣采用Open Graph和OEmbed標簽來幫助生成預覽圖。

< metaname= "deion"content= "seo deion long">

< metaname= "keywords"content= "seo keyword list">

< linkrel= "shortcut icon"href= "favicon.ico"

type= "image/x-icon">

< linkrel= "icon"href= "favicon_32.png"sizes= "32x32">

< linkrel= "icon"href= "favicon_48.png"sizes= "48x48">

< linkrel= "icon"href= "favicon_96.png"sizes= "96x96">

< linkrel= "icon"href= "favicon_144.png"sizes= "144x144">

< metaproperty= "og:title"content= "Short title here"/>

< metaproperty= "og:deion"content= "shortish deion"/>

< metaname= "twitter:title"content= "Short title here">

< metaname= "twitter:deion"content= "shortish deion">

< metaproperty= "og:image"

content= "https://res.cloudinary/.../hero-img.png"/>

< metaname= "twitter:image:src"

content= "https://res.cloudinary/.../hero-img.png">

隨著群聊和其他協作工具變得越來越普及，我們看到各個大型社交媒體平臺出現了許多新功能。特別是近年來，我們看到鏈接展開（link unfurling）功能被各大聊天平臺采用。這些平臺并沒有重復做無用功，而是尋找既存的微數據來生成預覽。

但是應該使用哪些數據呢？這些數據又該如何處理呢？事實證明，每個平臺的做法稍有不同，這導致它們呈現的信息也稍有差異。

圖2：同樣是亞馬遜網站的鏈接，在iMessage（左）、Hangouts（中）和WhatsApp（右）中顯示的稍有不同。

既然微瀏覽器無處不在，為什么在網站的分析報告中看不到它們呢？

來自微瀏覽器的流量很容易被忽略。其中的原因有如下幾點：

首先，來自微瀏覽器的頁面請求不會運行Java，并且不接受cookie。Google Analytics的<>代碼塊根本不會被執行，而所有的cookie也會被渲染代理忽略。

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)

AppleWebKit/601.2.4 (KHTML, like Gecko)

Version/9.0.1 Safari/601.2.4

facebookexternalhit/1.1

Facebot Twitterbot/1.0

最后一點，許多平臺，特別是Facebook Messenger和Hangouts都采用集中式服務來請求預覽圖的布局。這與WhatsApp和iMessage有所不同，在WhatsApp和iMessage中，你會看到一個用戶對應一個請求。而對于采用集中式服務的平臺，你的WEB服務器只會看到一個請求，盡管這個請求背后代表的實際上是數千個用戶。

微瀏覽器可能比googlebot更重要

我們都知道讓像googlebot這樣的搜索引擎機器人來抓取我們網站內容的重要性。這些機器人為潛在客戶開發和發掘新用戶提供了源源不斷的動力。

然而，對于營銷人員來說，真正發揮巨大作用的是用戶群體的口口相傳。比方說，你向朋友推薦一檔電視節目和一個品牌的服裝，或者是分享一則新聞。這對營銷來說才最有價值。

去年，當我為Cloudinary的《視覺媒體現狀報告》收集數據時，我發現在美國的假日季節有一個非常突出的鏈接分享模式。在感恩節期間，一直到黑色星期五，隨著群聊中用戶交易分享和口碑推薦的增加，鏈接分享率也在激增。

讓我們縮小時間范圍，以一天為單位，我們就可以看到鏈接共享和口碑推薦有一個起起落落的日常節奏。看到在Slack分享鏈接主要集中在周一到周五期間，而在WhatsApp分享鏈接則會持續整整一周，大多數人對這個結果可能并不驚訝。同樣地，我們在“休息”時間，比如午餐時間，或者是晚上孩子們都入睡后，最常用的也是 WhatsApp。

隨著鏈接預覽變得越來越常見，我們需要對如下兩種用戶行為同等關注：

• 用戶可能對通過短信和其他聊天信息發送過來的鏈接持懷疑態度。人們不想被欺騙去點擊釣魚鏈接，所以他們需要其他信息來提供驗證。這就是為什么大多數平臺使用鏈接預覽的同時，也強調網站的URL主機名。

• 快速瀏覽。我相信你一定有過這樣的經歷：從一個會議中或者商場里走出來后，發現群聊中多了100多條消息。在你不斷滾動屏幕瀏覽聊天記錄的時候，鏈接很容易被跳過。正因如此，用戶希望鏈接的預覽可以對網站內容作一個簡單的介紹，從而判斷是否有訪問這個鏈接的必要。

圖片 4：Nielsen Norman Group使用動態圖片預覽來介紹它們的研究成果

圖片 5：電商產品如何以引人注目的預覽來顯示產品的顏色、庫存和價格，以達到吸引買家關注的目的。

微瀏覽器不是真正的瀏覽器（他們只是偽裝自己是）

正如我前面提到的，微瀏覽器通過發送正確的HTTP頭，以及假冒的user-agent字符串，把自己偽裝成真正的瀏覽器。不過，下面有幾點是WEB開發人員應該清楚的。

首先，微瀏覽器應該設法保護用戶的隱私。當用戶還沒有決定訪問你的網站時，尤其是，當用戶正在進行的是一場私人對話時，也許這場對話會提到你的品牌或網站，但這只應該讓你覺得耳朵在發燒，并不意味著你可以竊聽他們的對話。

因此，所有微瀏覽器應該：

• 不執行Java -- 這意味著您的React應用程序無法正常工作。
• 忽略所有cookie – 這意味著你的A/B或red/green cookie將會被忽略。
• 部分會跟隨重定向，但幾秒鐘后會很快超時，并放棄嘗試去擴展鏈接。
• 當用戶點擊一個普通瀏覽器的鏈接時，不會產生一個referer: HTTP header。事實上，新用戶將會被認為是“直接”流量，就好像他們直接鍵入了URL一樣。

其次，微瀏覽器的核心非常小，很可能它們不能使用先進的網絡算法。大多數瀏覽器將使用標記解析器（tokenizer）來解析HTML標記，并向網絡堆棧發送異步請求。做得更好的瀏覽器能在向網絡發送異步請求之前對所需資源進行一些分析。

根據觀察實驗得知，大多數平臺在解析HTML時只是使用一個改進的for循環，并且經常同步請求資源。對于快速的wifi網絡來說，這應該問題不大，但在wifi網絡不穩定時，可能會造成體驗的不一致。

例如，iMessage在決定渲染什么之前會找到并加載所有的<link rel="icon" >網頁圖標、所有<meta property="og:image"和所有的<meta name="twitter:image: src">圖像。很多網站會建議 5 種或更多尺寸的網頁圖標。這意味著iMessage將下載所有這些網頁圖標，無論它們的尺寸大小是多少，但是如果決定改為渲染圖像，那么這些網頁圖標就一個都不會用到。

因此，包含的meta標記非常重要。內容越輕，渲染的可能性就越大。

標記/標簽很重要

既然微瀏覽器“頭腦簡單”，那么生成良好的標記就很重要了。以下是一些好的策略：

• 都快到2020年了，網站圖標只需要一個尺寸就夠了。刪除所有其他<link rel="shortcut icon"和<link rel="icon"引用吧。
• 根據觀察實驗，最常見的用于預覽的微數據標簽是Open-Graph（OG）標簽。如果沒有OG和twitter card標簽，那么使用默認的SEO <meta name=“deion”標簽。然而，由于deion標簽里包含的往往是無意義的SEO優化短語，用戶可能會感到一頭霧水。

• 因此，deion的文本應該足夠清晰。
• 最多提供三個<meta property=“og:image”圖像。大多數平臺只會加載第一個，而其他平臺（特別是iMessage）則會試圖創建并加載一個拼接圖。

圖6：Amazon使用User-Agent檢測，這導致許多鏈接預覽使用的是deion meta標簽

• 使用<meta property=“og:video* 標簽來實現漸進式（非流式）的視頻體驗。

< metaproperty= "og:type"content= "video.other">

< metaproperty= "og:video:url"

content= "https://shoesbycolin/blue.mp4">

< metaproperty= "og:video:secure_url"

content= "https://shoesbycolin/blue.mp4">

< metaproperty= "og:video:type"content= "video/mp4">

< metaproperty= "og:video:width"content= "1280">

< metaproperty= "og:video:height"content= "720">

• 不要使用UA sniffing來隱藏<meta>標簽。像亞馬遜這樣的網站會這樣做，他們這樣做的目的是為了嘗試顯示只帶有Facebook/Twitter微數據注釋的網站。但這可能會給不使用相同偽裝約定的微瀏覽器帶來問題。結果是導致鏈接沒有預覽效果。
• 利用這個標簽講述你的產品故事或總結你的想法。

總結

隨著我們更多的會話發生在群聊和Slack頻道中，鏈接預覽已經成為一個重要的方式，讓你的用戶在進入你的網站之前，就會被它所吸引。不幸的是，并不是所有的網站都提供了優秀的或令人信服的預覽效果。（現在你知道了這些，所以對預覽效果差的網站也無法做到視而不見了 —— 對此我深感抱歉）。為了能夠更快地吸引用戶訪問你的網站，我們需要確保我們網站的所有頁面都用微數據進行了注釋。更進一步說，如果我們可以結合這些頁面的預覽來創建一個可視化的網站摘要，那就可以說是完美無缺了。

原文：https://24ways.org/2019/microbrowsers-are-everywhere/

北郵教授為你揭秘5G的發展歷程、內在規律，并重點闡述新技術在數字經濟時代的作用以及對我們每個人的影響，5G時代你絕不能錯過的干貨課程，立即免費報名！