微浏览器无处不在
何为微浏览器？微浏览器同样可以访问网站链接、解析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标签来帮助生成预览图。
<meta name="description" content="seo description long">
<meta name="keywords" content="seo keyword list">
<link rel="shortcut icon" href="favicon.ico"
type="image/x-icon">
<link rel="icon" href="favicon_32.png" sizes="32x32">
<link rel="icon" href="favicon_48.png" sizes="48x48">
<link rel="icon" href="favicon_96.png" sizes="96x96">
<link rel="icon" href="favicon_144.png" sizes="144x144">
<meta property="og:title" content="Short title here" />
<meta property="og:description" content="shortish description" />
<meta name="twitter:title" content="Short title here">
<meta name="twitter:description" content="shortish description">
<meta property="og:image"
content="https://res.cloudinary.com/.../hero-img.png" />
<meta name="twitter:image:src"
content="https://res.cloudinary.com/.../hero-img.png">随着群聊和其他协作工具变得越来越普及，我们看到各个大型社交媒体平台出现了许多新功能。特别是近年来，我们看到链接展开（link unfurling）功能被各大聊天平台采用。这些平台并没有重复做无用功，而是寻找既存的微数据来生成预览。
但是应该使用哪些数据呢？这些数据又该如何处理呢？事实证明，每个平台的做法稍有不同，这导致它们呈现的信息也稍有差异。
图2：同样是亚马逊网站的链接，在iMessage（左）、Hangouts（中）和WhatsApp（右）中显示的稍有不同。
既然微浏览器无处不在，为什么在网站的分析报告中看不到它们呢？
来自微浏览器的流量很容易被忽略。其中的原因有如下几点：
首先，来自微浏览器的页面请求不会运行JavaScript，并且不接受cookie。Google Analytics的<script>代码块根本不会被执行，而所有的cookie也会被渲染代理忽略。
其次，如果你打算基于CDN或WEB堆栈中的HTTP日志进行日志分析，你将只能看到相对较小的来自微浏览器的流量。这是假设你可以识别user-agent字符串的情况。因为其中一些微浏览器会伪装成真实的浏览器，而另一些则伪装成Facebook或Twitter。例如，iMessage对所有的请求都使用同样的user-agent字符串（如下），并且自iOS 9以来就没有更改过。
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开发人员应该清楚的。
首先，微浏览器应该设法保护用户的隐私。当用户还没有决定访问你的网站时，尤其是，当用户正在进行的是一场私人对话时，也许这场对话会提到你的品牌或网站，但这只应该让你觉得耳朵在发烧，并不意味着你可以窃听他们的对话。
因此，所有微浏览器应该：
不执行JavaScript -- 这意味着您的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=“description”标签。然而，由于description标签里包含的往往是无意义的SEO优化短语，用户可能会感到一头雾水。
因此，description的文本应该足够清晰。
最多提供三个<meta property=“og:image”图像。大多数平台只会加载第一个，而其他平台（特别是iMessage）则会试图创建并加载一个拼接图。
图6：Amazon使用User-Agent检测，这导致许多链接预览使用的是description meta标签
使用<meta property=“og:video* 标签来实现渐进式（非流式）的视频体验。
<meta property="og:type" content="video.other">
<meta property="og:video:url"
content="https://shoesbycolin.com/blue.mp4">
<meta property="og:video:secure_url"
content="https://shoesbycolin.com/blue.mp4">
<meta property="og:video:type" content="video/mp4">
<meta property="og:video:width" content="1280">
<meta property="og:video:height" content="720">
不要使用UA sniffing来隐藏<meta>标签。像亚马逊这样的网站会这样做，他们这样做的目的是为了尝试显示只带有Facebook/Twitter微数据注释的网站。但这可能会给不使用相同伪装约定的微浏览器带来问题。结果是导致链接没有预览效果。
利用这个标签讲述你的产品故事或总结你的想法。
总结
随着我们更多的会话发生在群聊和Slack频道中，链接预览已经成为一个重要的方式，让你的用户在进入你的网站之前，就会被它所吸引。不幸的是，并不是所有的网站都提供了优秀的或令人信服的预览效果。（现在你知道了这些，所以对预览效果差的网站也无法做到视而不见了 —— 对此我深感抱歉）。为了能够更快地吸引用户访问你的网站，我们需要确保我们网站的所有页面都用微数据进行了注释。更进一步说，如果我们可以结合这些页面的预览来创建一个可视化的网站摘要，那就可以说是完美无缺了。
原文：https://24ways.org/2019/microbrowsers-are-everywhere/
本文为 CSDN 翻译，转载请注明来源出处。
热 文 推 荐
☞动漫美少女生成神器、猫的门禁...2019 年十七大最佳机器学习项目 | 年度盘点
☞这三名男子靠开加密矿池获得7.22 亿美元，却不兑现收益拿去奢侈挥霍……