PHP,DDD,CQRS,Event Sourcing,Kubernetes,Docker,Golang

0%

两个宜于『统一Web』的方案:响应式与自适应

1377683186626你大概早就听别人说过我们正处在『后PC时代』。那么它对于Web开发者来说意味着什么呢?它意味着你那网站的30%到50%的流量如今已经来自移动设备。意味着很快,使用台式机和笔记本访问Web的人将逐渐减少。 (那么)我们该如何在用户行为上处理这种结构性转变?我们已经逾越了用M-dot或T-dot来hack的阶段,开始步入一个由响应式与自适应设计 技术统治的时代——即W3C联盟口中的统一化Web来临。W3C议案的关键部分在于『统一化Web意味着,在合理条件下,无论用户使用什么设备,要将相同 的信息与服务传达给他们。』 对于开发者来说,那就意味着统一化Web方案要确保你的站点不仅工作在今天的智能手机和平板电脑上,也要能应付未来那遥未可知的屏幕画面。 目前有三种流行性方案来开发网站:使用响应式设计、 客户端自适应、服务器端自适应。 这三种方案难分高下,每种都有其自身的优缺点。明智的Web开发者会在实施下一个项目之前权衡各自的利弊。

响应式Web设计

响应式Web设计是最常见的统一化Web方案。它使用CSS Media Queries根据设备显示器的规格来调整网站的呈现方式。从波士顿环球报到迪斯尼站点到Indochino西服网站,响应式站点的数量正在飞速增长。 这种方案的核心优势在于设计者可以为所有设备使用同一模板,仅用CSS来定制不同大小屏幕上内容的呈现方式即可。 然而,一个良好的响应式设计没什么捷径可言。要迈向响应式,团队通常需要进行完全的站点重建。 在设计和测试阶段会非常繁琐,保证为每种可能的设备或内容定制用户体验很困难。我们都见过那样一堆看起来一点儿都不吻合的碎片拼图站点。在移动用户优先考虑的开发过程中,响应式站点设计可以与设备结合得很融洽。对于平板和手提电脑来说,(响应式设计)则更有优势。 对响应式站点来说,性能也很可怕。在Mobify公司,我们近期完成了一项对15个流行的响应式电子商务站点的分析。在这些站点中,主页平均加载87个资源、1.9MB的数据量。一些响应式页面可以大到15MB。 之所以数据量这么大是因为响应式方案需考虑到所有设备。你的用户只使用一种设备,但是不得不在使用前等待所有的页面元素和资源加载才行。简单来说,性能影响你的底线。在智能手机端,当用户不得不等上一秒时,转化率会额外降低3.5%。若是达到3秒大关,57%的用户会彻底离开你的站点。 当响应式设计迅速成为普遍的标准时,也为在线电商带来了新的挑战,包括怎样处理图片、怎样优化移动端性能,并且当采用移动优先的方案时,通常意味着网站必须推倒重建。

客户端自适应

客户端自适应秉承着『为定制的设备 内容传达响应式设计用户体验』的原则。它采用JavaScript丰富站点的功能和独特性。比如,自适应站点只为Retina显示器(比如新款iPad)提供Retina质量的图片,而标准精度显示器接收低质量图片。 自适应设计有两种方案:一种是在客户端生效,在用户的浏览器上;另一种是由Web服务器负荷来检测设备类型并加载正确模板。客户端自适应类型的网站 案例包括个性T恤Threadless和奢侈品闪购ideeli。自适应模板方案的优势在于其复用HTML和JavaScript的能力,简化了项目管理 和测试的更迭。 客户端响应方案意味着你不必完全重构网站。相反你可以基于已有内容布局移动响应。对于专家级开发者而言,这种方案也可以让你针对指定设备或屏幕分辨 率。例如,对Mobify的大多在线时尚零售客户而言,95%的移动端流量来自iPhone。客户端自适应意味着他们可以专门针对苹果智能手机进行优化。 与响应式设计不同,自适应模板确保客户端设备只加载所需资源。因为对设备和特性的检测已经转移到了移动设备自身,类似Akamai和Edgecast的内容分发网络可以在不影响用户体验的情况下使用他们大部分的缓存功能。 客户端自适应比起响应式设计而言有着更高的壁垒。开发者用这项技术需要熟练掌握JavaScript,也依托于网站现有的模板为基础。最后,因为客户端自适应作为现有底层代码上的覆盖物,你需要在网站迁移时让它们作为一个整体。

服务器端自适应

依赖于服务器插件和自定义用户代理检测器我们也可以通过多种途径得到服务器端自适应方案。使用服务器端自适应的网站包括Etsy,One Kings Lane和OnlineShoes.com。 为什么要选择服务器端自适应?它通常针对每个设备提供独特的模板,允许更多的定制。并且这种方案把设备检测逻辑块放在服务器上,使得小型移动页面加载得更快。除此之外,对于像Magneto这种常见的CMS和电子商务系统来说,还有多种多样可用的服务器端插件。 这种方案不适用于小心脏——通常需要你大幅度改变后端系统,实施起来将会是冗长(和昂贵)的。管理多种模板需要有持续不断的维护成本。最后,当服务 器过载时这种方案还会带来性能问题。当服务器上加载移动用户代理检测器的时候,需要关掉许多部署在CDN上的缓存机制,像Akamai一样,这将导致移动 端和桌面访客的用户体验速率降低。 当然,许多公司仍然在跟响应的基本要领角力,显然还没有准备好面对重口味的自适应。然而,随着竞争的加剧和移动通信流量的上涨,越来越多的团队将在所有三个方法上浅尝辄止,(最终)择出一个最适合他们用户的方案。