最近在负责小天鹅官方商城的首页开发,目前已基本完成。这里,把官网首页开发的要点罗列、梳理一下,也对用到的技术方案做个整理、对比。罗列顺序不分先后,想到什么就写了什么。
运营位的问题
基本电商都会有一套运营工具吧。而且,首页的运营位还是挺多的。
常见设置运营位的地方:首页banner、导航栏、类目栏、普通商品列表、运营自定义的商品标签、带图文消息的楼层、特殊频道的模板、公告栏、广告位等,基本运营会变动、需自定义的地方,都需要预留运营位。
当然,需要运营位的地方不仅仅是首页,各个页面、活动页、相同模板用于不同活动时等都可以用。
此类运营工具的原理
无非是写一个可视化界面,将运营填写的信息转化成一份json数据存储在服务器上,在controller中取到数据,按照约定解析,然后吐给view;或者直接将运营的信息转化成ssi页面片,在view中直接调用,这个需要web服务器支持SSI。
至于可视化界面工具的设计,只要包含:允许用户自定义json数据的字段名称、新建、管理页面片就行。至于别的功能,就由你想用的有多爽决定了。比较合理的分工是:开发建好运营位和自定义的字段,运营按照指示去填写具体的内容就好了。
公共页面片
网站有很多部分都是公共的,为了便于维护和减少重复工作量,我们一般会抽离成公共的页面片。
常用公共页面片:官网的公共头、尾、404、版权信息、css(reset和global)、统计上报脚本、微信分享脚本、自适应布局脚本等。
可以使用SSI页面片,需要web服务器支持。<#include virtual=””>、<#echo> 等。
统计上报、微信分享、自适应布局脚本的实现原理,下面都有提到。总之,是要有这种意识,养成这种习惯。
容灾处理
redis兜底数据,itil告警上报
容灾的方面很多。考虑到网络故障、云服务器故障,运维会有备用容灾机器,当主机器挂掉时,连备用机器;担心后台接口挂掉,我们可以用redis备份,即从接口中拉出数据之后redis存一份,如果接口挂了,就先用redis,同时立刻告警。view中也要做数据获取不到时的处理(如隐藏,甚至用兜底数据)。但告警是必不可少的,且各环节都要做到位。尽可能做到:让用户无感知,自己又能最快发现问题。
也因此,开发中,对异常分支的处理,要视情况告警、打日志、兜底、try…catch等。
参考方案:
性能优化
我们是电商网站,所以性能优化的大头是图片。
图片懒加载:图片即将显示时才去加载,组件lazyload。
图片服务:阿里云的图片服务,支持png,jpg,webp等格式转换。
webp方案:兼容性:webkit内核浏览器,IE不支持,Android 4.0以上提供原生支持,其他版本及iOS可使用官方提供的解析库(Android ,iOS)。对于浏览器是否支持webp,只能使用特性检测 :这个不用再特性检测了,支持的浏览器会在请求头中自动添加accept:image/webp,是浏览器自身的行为。
然后在服务器端根据请求头accept:image/webp判断客户端是否支持webp格式,若支持,则返回阿里云webp格式链接,否则是原图片链接。
|
|
h5的响应式布局
目前小天鹅商城首页采用的是rem方案 ,以后新增的项目也都会采用rem方案。但我们的商城依然有百分比、媒体查询等方案。这也算是历史遗留问题。
rem方案能同比例放大所有页面元素, 直接量设计稿不用计算,但问题是:存在精度问题,可能会对不齐,尤其是雪碧图图标问题。但依然推荐这种方案。
百分比方案,需要计算百分比,且并不能精确的同比缩放;字体不能缩放,字体与其他元素不协调。
|
|
图标处理方案
雪碧图:合成工具gulp.spritesmith,很方便,spritesmith支持gulp,grunt,cli。优点:适用于任何小图标,包括闭合的图标和多色图标。但:存在分辨率的问题,hover态与非hover态需要2套图标,体积较字体图标大。
雪碧图存在一个问题,尤其是rem方案时,图标width,height,background-position设置不当,导致图标会被截掉部分。解决方法是:
1. 自己抠图或设计导出的sketch图标,要四周留白,大概5px左右。
2. 设置padding值,建议10px,并在spritesmith的CSS模板中,将padding加入到宽、高、位置的计算中。
字体图标:矢量图标,纯CSS控制,体积小,任何分辨率上都不模糊。但:只适用于纯色、闭合的图标。生成工具(暂时还没有用过)
base64:只用于小图标(小于1kb的图片)。工具gulp-base64。
公共错误页处理
公共的业务逻辑都会统一处理、维护。对于CI框架,一般写在application/core下的MY_Controller中,业务逻辑去继承即可。即:class Index extends MY_Controller{} class MY_Controller extends CI_Controller{}
showErrorPage :基本是load一个公共的错误页,一般会同时支持2种形式:同步、异步。
|
|
公共登录页
业务组件
业务中可复用的模块、组件都可以抽离出来,与业务耦合较轻的,封装成组件,耦合较重的,封装成模块,小范围调用。个人觉得,Vue,react对组件的支持上比jQuery有很大优势。jQuery多使用模块模式,将一系列功能、属性封装在一个对象中,对外只暴露需要暴露的方法,所有可选项用参数传递。
|
|
弹窗组件注意点:
1.create弹窗之前判断下,是否已存在,可以用一个变量记录弹窗ID,存在,直接取,不存在,则新建。
2.销毁时,若有动画,则等动画结束后再销毁(webkitTransitionEnd)。
3.可以挂在$上,$.mpop=function(){ return new Mpop();}。当然也可以放在一个初始化的函数中。
4.回调函数。组件的灵活性与方便性,需要自己权衡。
Vue舒服的地方:
1.slot用在需要自定义的地方,比起jQuery的自己拼HTML片段,很舒服。
2.过渡效果支持的很好。
统计上报处理
1.在需要上报的地方加属性:data-mtag=”xxx”;
在脚本中,添加click事件,对带有data-mtag元素的点击事件进行上报。用script标签的src属性,直接发送请求到服务器即可,在服务器端对上报数据进行处理。
2.对整个页面的统计,在URL中直接加matg=”xxx”的参数。 在脚本中直接取URL上的参数上报。
3.告警。结合微信服务号、企业号,短信或微信告警。
目前,对上报数据的处理分析,是由数据团队做的,前端这里只做了数据埋点、收集、上报这个部分。这些上报脚本都是放到一个公共页面片中的,所有的页面都会引用。
目前网页性能数据、脚本错误上报等并没有做。因为从业务量、业务类型来说,并不是很需要。
|
|
浏览器兼容性处理:
浏览器兼容性琐碎且繁杂,不过,绝大部分问题都能在网上搜到解决方案。这里也只是简单记录几个,稍后会专门整理一篇博文。
- 移动端的fixed问题:
- 日期问题:日期格式用2017/04/29代替2017-04-29
- IE8兼容问题:许多CSS3都不支持,只能优雅降级。像vue、react这种新框架,目前也只能在移动端使用。
第三方客服
这个好像也没什么要特别说明的。接入方法和细节需要和第三方沟通。不过,有一个原则:第三方客服的接入方式不要对自己的业务有太大侵入。
第三方统计
包括百度统计、广告投放统计等。这个也很简单,第三方都会提供好接入代码,只要放到合适的位置就好了。和第三方客服一样,这种脚本延迟加载就行:async defer 。
微信、APP内分享
微信JS-SDK。通过script获得JsApi使用签名后,调用微信分享相关的回调函数。先设置wx.config({}),然后config信息验证后会执行ready方法,在ready函数中调用分享API。
|
|
具体使用方法,请看微信开发文档.
SEO优化
这个方面也挺大的,而且SEO优化有很多方面,这里只列前端开发中相关的点。
- 为页面添加元标记meta:网站关键词、描述等
- html语义化:各种标签的合理使用、图片Alt、title标签
- URL标准化
- 外链最好nofollow
- 重要内容不要使用js输出
- 对于暂时不需要显示的元素应该使用
z-index
属性而不是display:none;
这样的代码,因为Spider会过滤display
属性为none
的内容。
上面提到的好多方面都是泛泛而谈,因为每个方面展开后都是一个方向。我也只是对目前接触过的总结记录一下。以后自然也会不断加深对其的理解和实践。当然,这些技术和思想也都不仅仅限于首页。