如何在持续升级的项目中保持项目的高性能？如何更加准确的定位和解决性能问题？实际上，WPO的最主要目的是改善用户体验，而用户体验的好坏则可以根据几个核心性能指标来衡量。从用户体验出发的几个核心时间指标包括：Start Render、DOM Ready、Page Load、TTI。不同的性能指标对用户体验的影响是不同的，而指标本身受哪些因素的影响也是不同的。优化某个指标又该具体采用什么样的方式？接下来将一一介绍，本文集中介绍Start Render。

(更多…)

正则表达式如下

[s*((?:[wu00c0-uFFFF-]|\.)+)s*(?:(S?=)s*(['"]*)(.*?)3|)s*]

这个正则表达式的作用是用来匹配CSS属性选择符，例如：

/*能匹配成功的*/
[class='abcdefg-abcdefg']

/*匹配失败的*/
[class='abcdefg-abcdefg'

成功匹配的过程如下：

(更多…)

上一文《正则优化一则：CSS选择符匹配》中说到了如何优化一个正则在匹配成功时的效率，而实际上正则匹配有成功就会有失败，因此失败时的效率也是需要注意的。继续上文中的正则，分析了一下优化前和优化后表达式失败时的效率：

匹配文本：.a select,.b input,.b input[

(更多…)

正则表达式如下

^((^|,)s*[.w-][.ws->+~]*)+$

这个正则表达式的作用是用来匹配一些简单的CSS选择符，例如：

/*能匹配成功的*/
.a select,.b input,.b input
.a select,div.test > a,.b input
/*匹配失败的*/
.a select,.b input,.b input[type="submit"]

该表达式在匹配成功时的效率还是比较高的，因为里面使用了字符集进行贪婪匹配，接下来以匹配 ".a select,.b input,.b input " 这个文本来具体分析一下它的效率问题，具体的匹配过程见下图

(更多…)

图片上传在当今的Web应用中是一个非常常用的功能，如果不需要在上传前进行图片预览则可以简单的使用HTML+Javascript来实现，但如果一定要在上传之前提供图片预览功能则需要求助于Flash来实现。不过，随着HTML5 File API的诞生这一状况终于有了改观，本文将介绍如何使用HTML5 File API快速的实现图片预览功能。

(更多…)

Web应用的发展，使得客户端存储使用得也越来越多，而实现客户端存储的方式则是多种多样。最简单而且兼容性最佳的方案是Cookie，但是作为真正的客户端存储，Cookie则存在很多致命伤。此外，在IE6及以上版本中还可以使用userData Behavior、在Firefox下可以使用globalStorage、在有Flash插件的环境中可以使用Flash Local Storage，但是这几种方式都存在兼容性方面的局限性，因此真正使用起来并不理想。针对以上情况，HTML5中给出了更加理想的解决方案：假如你需要存储复杂的数据则可以使用Web Database，可以像客户端程序一样使用SQL（不过Web Database标准当前正陷于僵局之中，而且目前已经实现的浏览器很有限）；假如你需要存储的只是简单的用key/value对即可解决的数据则可以使用Web Storage。 本文主要从各个方面介绍一下Web Storage的具体情况。

(更多…)

FORM在HTML5中的变化算是比较大的，一方面体现在新增了大量的2.0时代的控件，另一方面则是整个FORM结构的变化。与新增的控件相比，新的FORM结构一样为将来的开发工作提供了很大的便利性。

(更多…)

在WEB页面中，为了配合Javascript的交互功能，很多时候都需要给HTML标签添加自定义属性（虽然标准不支持这么做），而关于自定义属性的名字则大都也是各自为战的自定义的，或根据功能、或根据项目等等，例如：

<!--来自贴吧—>
<div cid="count_ayjpb" st_type="toupiao"></div>
<!--来自有啊—>
<a href="#" favo_type="x" favo_obj_id="x" favo_title="x"></a>

这样的会造成自定义属性名混乱的问题，而且更为重要的是假如新的HTML标准中需要使用这个自定义属性，而且其含义与你的自定义属性中含义并不相同，这是一个大家都不希望看到的情况。于是在HTML5中给出了解决方案：只要是自定义属性都需要带上"data-"前缀。

The

data-*

collection of author-defined attributes. Authors can define any attribute they want as long as they prefix it with

data-

to avoid clashes with future versions of HTML.

因此，按照这个规范可以改写上面两个例子以获得更好的兼容性：

<!--来自贴吧—>
<div data-cid="count_ayjpb" data-st_type="toupiao"></div>
<!--来自有啊—>
<a href="#" data-favo_type="x" data-favo_obj_id="x" data-favo_title="x"></a>

实际上在淘宝的机票已经有看到这样的使用

<span data-display="inline" data-tnick="x" data-nick="x"></span>

-本文到此结束-

    前段时间简单的研究了下前端优化相关的知识，本文算是一个阶段性的总结，或者当做一个优化的参考List。

前言

    前端是庞大的，包括HTML、CSS、Javascript、Image、Flash等等各种各样的资源。前端优化是复杂的，针对方方面面的资源都有不同的方式。那么，前端优化的目的是什么？

    1. 从用户角度而言，优化能够让页面加载得更快、对用户的操作响应得更及时，能够给用户提供更为友好的体验。

    2. 从服务商角度而言，优化能够减少页面请求数、或者减小请求所占带宽，能够节省可观的资源。

    总之，恰当的优化不仅能够改善站点的用户体验并且能够节省相当的资源利用。

    前端优化的途径有很多，按粒度大致可以分为两类，第一类是页面级别的优化，例如HTTP请求数、脚本的无阻塞加载、内联脚本的位置优化等；第二类则是代码级别的优化，例如Javascript中的DOM操作优化、CSS选择符优化、图片优化以及HTML结构优化等等。另外，本着提高投入产出比的目的，后文提到的各种优化策略大致按照投入产出比从大到小的顺序排列。

(更多…)

在前段领域中，对Javascript和CSS的优化一直是大家关注的焦点，相应的压缩优化工具也非常丰富，相对而言对HTML优化的关注则显得有些冷淡。在Steve Souders的大作《Even Faster Web Sites》中谈到非常多有效的前端优化方法，例如Javascript的加载、CSS选择符、图片优化、gzip、iframe问题等，唯独没有细说HTML优化。在整个前端的构成中，HTML是必不可少的一部分，而且是真正的展示“前端”。虽然与动辄十几K的Javascript相比，HTML的大小在整个页面资源中一般不会占太多的比重，而且还有Gzip，但是事实表明，大多数页面都有较大的压缩余地，即使是Gzip过后仍然能减小可观的体积，这一事实在后续的文章中会给出，本文主要讨论HTML优化的一些可行和看上去不那么可行的途径。

(更多…)