目标定的小一点,比如先快它个20倍吧

去年Facebook发布Instant Articles(即阅文)时,也只是着眼于publisher的优化方案,目的是“能方便他们创建加载速度快的互动式 Facebook 动态”,本质上是服务于FB的现金牛信息流广告,如不是相关渠道从业者,甚至不知此物为何用。

不久后,Google便发布了AMP计划,一项号召全行业参与的网页加速计划。

如你所知,最近的里程碑——百度推出中文移动网页加速实施方案MIP。

AMP发布的时候引起了不小的震动,甚至连线杂志都发了评论员文章,因为这样的方案解决HTML5页面最大的痛点:速度,且通过一个模糊的容器概念,使这种效果不限于在某个APP内完成。

我们先将两个搜索巨头的解决方案,放在一起对比一下

077EFE7C-DE74-4E7E-97B8-2E8D39CE5E07

这些加速的机制和特点我原封不动地引自两个框架的官方网站,我刻意将相似的技术放在了同一行,如果你已经使用了这样的框架,这些经过自上而下规范过的代码对页面加载速度帮助极大,你甚至可以获得原生APP的感受。

“精简的JS”

“预先告知标准的静态资源”

“不允许且不被信任外部JS”

“特定规范的CSS及动画”

这样的页面犹如一个个加工精准的子弹,而浏览器只需要上膛击发,那些繁多复杂的卡壳问题将一去不复返。

因为,本质和“即阅文”一样,虽不是在指定APP内完成加速,MIP取而代之是增加了更多的代码规范,形成一个抽象上的容器,符合这些规范的页面将进入“容器”完成飞一般的体验,当然我想你要使用百度APP可能效果更好(MIP现在没有未来也会有这样特别的加速吧),你可以感受一下百度APP中打开百度自家产品和打开你的网站的对比。

这是趋势吗?

不定论好坏,我想起码一部分是,比如内容类的资讯页。

或者你应该这么理解,如果你还需要搜索引擎分发的流量,你就要尊重这个产品及其用户的要求,因为速度也是这个产品要解决的痛点。

很常见的一个误解就是,当你我都以为网友们在访问这样的页面时

携程首页

其实网友们大多是看这样的信息

2王宝强马蓉亲子照

有了规范,你不能再为做不出极速的页面找理由,为了利益而拖慢页面速度的事情更不能!你是在和渠道作对,看看这些搜索结果,这些页面上的ad,无序的、低效的HTML5页面,损害的是广告主、浏览者、搜索引擎的利益,不帮助(治)你提高帮(治)谁?

最后,难以回避地,我们还是要面对一下“即阅文”、AMP或是MIP的原罪——这种极权模式下的框架,极其严重地扼杀了新的技术和设计,页面将不再具备美感和用户体验!(OMG,用户体验这神奇的佛挡杀佛的名词啊)

吃饱了吗?就谈艺术

首先,你是内容类页面吗?你成天转来转去的微信公众号的页面扼杀了多少HTML5新技术你两只手数的过来吗?极其严重地影响了优质内容的产生和传播了吗?从渠道优化技术角度看,公众号其实一开始就拿来是和“即阅文”对标的产品,看着不像是吧,公众号、即阅文、AMP、MIP再加一个快出来的应用号,原理和本质上都是一样的,仔细想想容器的概念吧

其次你运用的新技术性能上保证到了多高的水平,说白了你是否连累了你渠道的用户,尤其是免费渠道,比如搜索引擎?做的再好看用户打不开还是白瞎啊。姑且你做到了最牛的技术及最高的性能,行业里你觉得能有几家水平会做、愿意投入去做这样的优化?为你的渠道想想吧,尤其免费的渠道,它不是服务一两个极客做的网站,然后被一叶遮目的嫌弃,你追求的是技术的极致和前卫,可架不住我们大伙想看王宝强啊,(此处突然想艾特这届百度公关)。

如果以上你都不符合,你既不是内容类页面(简单交互类页面),也没法将手里的不是MIP规范的页面优化到MIP的水平,那就多提和推进MIP的产品、研发及运营人员,将MIP尽快做到cover非内容类页面,比如“精致的JS”再OPEN一点?有限度地为我们开放一些自定义JS方法的权限?不同级别的站点“容器”宽松度不同一点?甚至百度CACHE便宜一点?

基于目前H5页面及其发展的进程,我们不要脱离实际生产和效益来说,我的观点是特别悲观的,在一个不稳定的环境(各式各样的浏览器及webview)下,一个充满鸡肋和不确定氛围的研发大潮背景下,H5前端技术再花哨和前卫,也掩盖不了整个生态长尾中那些技术和产品的羸弱,由此造成的产出、投入的惨淡使这种问题陷入死循环,本质上我们连大部分页面中的速度和阅读品质都解决不了,关注那几颗夜明珠又有什么用处呢?为什么不通过一些hero app 来带动一下基础建设,把根基及服务的用户做扎实呢?

还是王健林老师说的好:”要当首富这是对的,先定一个能达到的小目标,比方说我先挣它一个亿,一个亿,亿,亿,亿…”

 

本文的AMP版本

当我们谈论百度站长平台时在谈什么

大概一个月前,百度站长平台的刘禾女士说她在筹办一个线下的茶座会,“以一种从没有过的、工程师直接出面的形式开办”;“会议想请一些大站的SEO人出席,探讨一些搜索引擎和网站相处的问题和方案”,问我要不要来。

我想,这样的机会怎么能函授呢?当即定了北去的行程。

不知不觉,已经参加了该系列两届的茶座会,有一些前所未有的感想、观察和心路历程,以作记录。

众所周知,如果你做超过五年的SEO,有横跨过中文和非中文优化的工作历程,想必对搜索引擎行业的发展已了如指掌。鄙人入行逾8年,算不上资深,外贸行业起步,有幸师从Google入门,后负责旅游相关的中文网站优化,又有幸百度赏饭多年,也算经历过近些年网站优化这个职业的起伏。

考证一下,大概在1999年,Google就有了google webmaster tool(现名Google Search Console)的雏形Google sitemap,我当然是没有见过。但在我开始使用google webmaster tools的时候,GWT的功能也远没有今天的丰富;就算这样,GWT对于站长们也是革命性的,至少在远离算法的部分,站长从此可以看到自己网站在搜索引擎中的各种表现:想想吧,一个远离美国本土、在Google没有亲戚朋友的站长,每天打开电梯就可以看到收录、抓取、屏蔽、甚至点一点按钮就可以控制网站和Google的相处,这是多大的造化。

后来接触的多了,想想也没什么,搜索引擎也是个产品。

如果你比较早的接触过互联网产品相关的工作和流程,更甚至担任和跟进过量级巨大的产品项目,你就完全可以了解一个以排名算法为核心的产品为何要与以研究自己算法为工作的人接触如此之近。

首先,这些人都是该产品的用户,其次,他们又是为搜索引擎带来用户的群体。

一个产品,一个系统,不可避免地有不可控的元素,bug、逻辑错误、功能死角等等,我们在使用各种互联网产品的时候都有切身体会,相应的,产品开发有预防、收集、修正等优化产品的各种环节;虽然有的产品量级足够大甚至充当了生态的角色,但本质上产品的属性还是无法磨灭的。

是产品就有问题,就需要收集问题、修复问题、改善体验,想想以前的一次次“打击”、“算法更新”、“黑帽案例”、“前端展现新元素”,实质上都是产品的破坏、改善、升级迭代。基于此,一个无法收集或者收集渠道单一的产品在功能改善和BUG修正上是弱势的,甚至功能决策上都影响准确。有个简单的例子,年初,我们做applink这个功能,功能刚刚上线发现浏览器端和客户端收集的数据无法对齐,众所周知用户的手机系统是完全封闭的,浏览器抛出applink后除非成功打开了APP,否则无法将流程及其携带的数据埋点衔接,浏览器和App之间是系统的地带,中间发生什么导致错误,作为操作系统生态中的一员无从得知,基于这样无法逾越的权限,我们不得不在巨量的日志和数据中查找原因,很幸运我们在日志中没有迷失,成功找出并兼容了这些机型。 很简单的一个问题,但我们体量小的,生产线相对是短的已苦恼不已,若是搜索引擎这样庞大的生态,收集相关信息想必更有挑战性。

我想,站长工具诞生之日起就担负了自身产品优化至关重要的角色,发布正确的建站方案、制定规范的施工标准、打通大站(大型站点和大批量使用的站点)和搜索引擎的融合、拉近搜索引擎产品开发人员和其用户们的距离,从各个方面讲这样的运作模式都是多赢的:更多规范的出台不仅意味着网站开发及营销人员建站做功能时有迹可循,同时也引领开发及营销人员往正确的路线上投入资源;其次,搜索引擎开启了更宽广的渠道收集生态中的现象、问题、改善方案,网站方则准确看到自己在生态中的表现、及时作出调整;再次,搜索引擎更便利、近距地看到整个生态发生着什么,哪些技术方案、开源框架、设备、用户习惯促使自己的产品功能亟待改变;搜索badcase、blackcase 更容易被搜索引擎方发现了,站长原先靠猜的现象起码一部分可以被解释或者找出方向修正了,通道有了,太多可以想象及改变的了。

回到百度的站长平台,作为使用者的感觉就是发展迅速,但大面积开放的时间也是相对较短的。愚以为,作为产品,后台一些功能和概念还需官方文档介绍、一些数据输出还需稳定正确、一些案例和用法还需百度官方和众营销高手补充和丰富,更多数据还可以更开放(如果https 真的只是防劫持,则间接干掉了中文网站分析师这个生态中举足轻重的职业);平台自身的知名度和覆盖度还可以通过更多合作、通道、信息据点提升。用户群只有营销人员是不够的,让那些运营、产品、开发、老板各个工种都用起来,都要熟知标准和规范。

作为从业人员我想大家近年都感同身受——发展和变化太快,一年前还红得发紫的渠道一年后就可能在急速萎缩,一些认为还当红的渠道其实看数据已经处于瓶颈即将衰退。但本质上讲线上行为是更多了,设备的小型化和移动化,束缚减少了场景增多了,总之,流量其实更多了。不论奉为国策的“互联网+”还是百度提出的“人连接服务”,抑或全民创业 offline   to online——一部手机躺着就能和名医对上话、快速叫上车、各种缴上费,放五年前这些行为都不能想。领军的技术和公司很多,但放眼望去,这才o2o了多少行业,多少传统行业在筹备、进行、完成着这种变革,多少技术能力赢弱但又有着优质服务和产品的公司在等待、着急完成这种变革,那些技术、时间、资源都在赛跑的公司和创业者多么需要和各个推广渠道高效地融合,人连接服务是个方向,让拥有优秀服务和产品的网站不输在信息鸿沟上,让这些优秀的公司资源不浪费在没必要的起跑线上,让专业的公司专心做专业的事,百度站长平台,期待更多技术规范和行业引领。

 

前端代码优化带来搜索引擎高效地识别移动页面

最近为百度站长平台写了一些文章,在此记录一下

开篇先摘一段新闻《中国智能手机市场6年首现负增长》。

文中指出:“IDC报告显示,2015年第一季度中国手机市场出货量为1.1亿部左右,同比下滑3.7%。其中智能手机市场出货量为1亿部左右,同比下降2.5%。这是过去6年以来,中国智能手机市场第一次出现季度同比下滑的情况。”

这意味这什么呢?

简单说,我国智能机不但普及,且已趋饱和,移动红利即将消耗贻尽。

那对于网站优化人员又意味着什么?

结果上讲,重大网站没有完成移动化需亡羊补牢,中小网站去完成移动化迫在眉睫。

制作出用户体验良好的手机页面只是万事俱备,最为关键的临门一脚是获得搜索引擎的青睐,这样才能得到精准的用户,很多网站拥有PC和移动两套页面,从经验上看,精准、高效地被搜索引擎识别不但促进移动页面的排名和流量获取,对PC页面也有额外的效果加成。

在经历了一轮轮移动H5项目,看过很多移动页面识别和优化的国外文章,更重要的是多次和百度相关人对话和解决问题后,我将一些常见的HTML识别细节总结了两部分,用于促进移动页面被搜索引擎识别、收录,让更多优质流量更早、更多地分发到自己页面。

一、head标签中的部分

1.URL设计

URL尽量含有通用已成趋势的移动命名,例如“m./wap./3g./mobi./mobile./mob/wml/”,可以在子域名等方面体现

2.页面顶部的doctype标签

作为协议的重要部分,doctype中是否移动化也很重要,检查是否存在与移动相关的声明,如这些关键词,openmobilealliance, xhtml-mobile, xhtml-basic,wapforum,dtd compact html

例:“<!DOCTYPE html PUBLIC “-//WAPFORUM//DTD XHTML Mobile 1.0//EN””http://www.wapforum.org/DTD/xhtml-mobile10.dtd”>”

3.meta标签中的viewport属性和x-ua-compatible 属性

viewport,移动前端开发中最重要的标签,响应式设计的根基,如果你的页面是遵守响应式设计的,那么说明这些页面对移动设备有友好的输出。

典型的的viewport代码是这样的,<meta name=“viewport” content=“width=device-width, initial-scale=1.0”>,判断移动与否的关键属性值为width,如果width=device-width这是典型的移动友好的设计,增加判定为移动页面的砝码,如果width有具体值,且值大于典型的移动屏幕(应该小于600),那么该页面被判定为PC页面的几率大大增加。

但,META中还有一个很独特的属性作为SEO人员应该很少接触到,那就是x-ua-compatible 属性,该属性是PC意味非常强烈的功能性代码。示例代码如此,<meta http-equiv=”X-UA-Compatible” content=”IE=9; IE=8; IE=7; IE=EDGE” />,从百度工程师处得知,该代码会有较强暗示当前页面为PC页面的功能,需选择性使用。

4.title中的移动暗示

制作移动页面时,在title标签中写明:“移动版”、“手机版”、“WAP版”、“触屏版”不仅是照顾用户体验的方案,也利于页面的移动识别,反之PC页面要谨慎使用这些文案。

5.链接link标签的media和href属性中需要注意的细节(多为样式文件)

media属性值为screen时,表示屏幕中的显示样式,link的href所填写的URL(基本为样式文件的URL)就比较重要了,一定程度加大不同设备的偏重。此时URL中尽量出现/wap,/mobile/这样的命名,同URL设计一样,用于提高页面识别为移动的效率和概率。

如URL中含有pc字样则加大识别为PC页面的几率。

6.一些通用的PC类识别HTML代码

embed:经常用于嵌入多媒体

object:用于嵌入对象

marquee:老旧的滚动特效实现代码

iframe:想必网站优化人员很熟悉了,典型的PC常用标签

这些典型的用于PC或者老旧的、HTML5已经有更高效替代方案的旧标签,意味着使用它们将增加页面的PC属性,需要有目的地取舍。

7.一些javascript中典型的PC特征

加载swfobject、含有activexobject语句:移动页面根本不会使用如此重的多媒体引用方案(不信你问问你的前端工程师)

含有netscape(网景)、msie(IE)、firefox(火狐)、browser.msie(IE)这些典型的非移动端浏览器兼容代码的

设置了timer的 ,以及JS代码含有settimeout,的(此处不知道为什么设置timer还有识别的问题)

均大幅增加识别为PC页面的可能性

以上这些<head></head>中出现的内容,

二、正文body中需要注意的部分

链接和文本遵照的原则基本与head中一样——多出现移动相关的字眼;页面设置的宽度不要超过常规移动设备的大小;那些常识中(除非招错前端工程师)绝对只用于PC的一些兼容性代码。

此外div块的个数也值得注意,没有哪家移动页面会过量使用div块;还有典型的只用于适配PC机器的HTML代码,例如:accesskey(如果移动页面用,要不前端招错人了,要不产品招错人了,应该引起警觉)

head和正文两大部分,基本涵盖了一张页面最主要的部分。

网站优化人员一定要把握这些使用细节,协助前端工程师从正反方向将公司的PC和手机页面泾渭分明地呈现给搜索引擎。试想如果你每日被抓取页面达到90%的识别率,而一般水平是70%,这种优化增量是非常显著的。

最后,分享一个机器学习的思想给网站优化的新人,此文中心思想截取如下

你从市场上的芒果里随机的抽取一定的样品(训练数据), 制作一张表格, 上面记着每个芒果的物理属性, 比如颜色, 大小, 形状, 产地, 卖家, 等等。(这些称之为特征)。

还记录下这个芒果甜不甜, 是否多汁,是否成熟(输出变量)。你将这些数据提供给一个机器学习算法(分类算法/回归算法),然后它就会学习出一个关于芒果的物理属性和它的质量之间关系的模型。

下次你再去市集, 只要测测那些芒果的特性(测试数据),然后将它输入一个机器学习算法。算法将根据之前计算出的模型来预测芒果是甜的,熟的, 并且/还是多汁的。

 

结合本文中的内容、再结合你已经烂熟于心的搜素引擎工作原理,设想一下,你的所有页面都是芒果,百度是带有识别模型(且该模型会自己训练、纠正自己)的芒果鉴别器,怎么让你的芒果持续性地、每次被拿起来都进入那个又大、又甜、又多汁的篮子?那些一眼就看出来的大甜芒果当然好判断,那些一眼看不出来的呢?我们能不能多生产些一眼就看出来好坏的芒果呢?这样整个果园是不是好收割一点?

文章中的html细节就是模型的冰山一角。