目标定的小一点,比如先快它个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了多少行业,多少传统行业在筹备、进行、完成着这种变革,多少技术能力赢弱但又有着优质服务和产品的公司在等待、着急完成这种变革,那些技术、时间、资源都在赛跑的公司和创业者多么需要和各个推广渠道高效地融合,人连接服务是个方向,让拥有优秀服务和产品的网站不输在信息鸿沟上,让这些优秀的公司资源不浪费在没必要的起跑线上,让专业的公司专心做专业的事,百度站长平台,期待更多技术规范和行业引领。

 

tag management 的设计

用途:一般市面上都是管理第三方代码的

作为刺入页面的针,实现第三方代码的管理太过简单,所有的营销需求都可以与之发生关联

QQ截图20150423104541

如图是Google GTM的基本结构

container:容器,代码仓库,物料基地,容纳了形形色色与业务有关所有的代码

tags:容器中取出的代码,谓之tag

rules:如何从容器中取出tag

marcos:宏,这玩儿吧,如果你早年玩过一些自动SEO工具,一眼就可以看懂

容器是你的仓库,tag是你要喷出的代码,rules 决定你喷代码的范围,当没有变量时候可以作为trigger,宏来产生变量,变量可以做出rules,也可以捕获营销所需的值向后传递。

tag management像一支锋利尖韧的针,将营销需求刺入 页面

遵循这个思想,我准备开工做一个