前端优化-渲染优化

前端优化其六-开发60帧每秒的app

浏览器如果花费很长的时间去绘制一帧的话,就会丢失另一帧。最糕的情况下,浏览器会直接卡死。

浏览器如何渲染帧

  1. 浏览器向服务器发起get请求 get/http/1.1
  2. 服务器做出响应并发送html
  3. 浏览器提前解析dom(parse html)
  4. 浏览器解析cssom (parse stylesheet)
  5. 结合 dom + cssom生成render tree (Recalculate styles)
  6. 浏览器开始计算布局,即计算元素会占用多少空间、位置(layout),网络布局意味着某个元素可以影响其他元素,这对浏览器来说非常复杂。例如body的宽度会影响子项的宽度,一直向dom树的下方蔓延。
  7. 从矢量到光栅,把像素绘制到图层(paint)
  8. 浏览器需要把图像解码成内存,篇4说过,这很消耗内存和cpu(image decode)
  9. 合成图层,浏览器会把内容绘制到一或多个图层上,图层太多或者太少都可能影响性能。或许你可以想像一下photoshop图层,他们很像。

    Read More

前端优化-启动优化

前端优化-其五 javascript优化

随着现代web技术越来越成熟,浮现出了一批批优秀而又成熟的框架。驱动这些框架产生的原因是我们的web需要解决越来越复杂的需求。随之而来的便是越来越复杂的代码,越来越大的代码文件。

javascript 是最昂贵的资源

由于web的特殊性,我们总是习惯的将文件大小看得很敏感。也有优秀的技术把我们的代码文件压缩到很小:通过工具压缩后的代码,再结合gzip技术往往可以把代码文件压缩到原大小的十几分一。这当然很棒,我们节省了大量的带宽。

Read More

前端优化-图片优化

前端优化其四 图片

图片是网页重要的一部分,设计师在设计网页的时候也经常通过图片来使网页更加的炫丽。随着计算机相关技术的发展,用户对图片的质量要求也在不断的上升,这意味着我们要给用户提供更棒的图片、更大的内存占用、更多的绘制cpu消耗。如果是移动设备,这些往往还意味着电池寿命。在许多网站中,图片都占去了它们大部分的加载带宽,图片也是网页性能中很大的一部分负担。好像,有必要给图片做一下优化了。

压缩图像内容的大小

和大部分资源一样,首先应该使用压缩工具减小资源文件的大小,往往这是性价比最高的方式。但是和文本资源不同,图像资源的压缩也意味着图像质量可能有所损失。那么,合理的压缩策略就很重要了,不过度压缩、不重复压缩,还需要根据不同的图像文件格式设置不同的压缩方式。

Read More

前端优化-http缓存

前端优化 其三 http 缓存

我们每一次打开网页,都需要获取比如js、css、图像、字体等各种资源。如果每一次都从网络上下载,显示并不是一个理智的选择。http 缓存提供了一种机制,浏览器首次加载
网页时,会将页面资源存储在 HTTP缓存中。当浏览器下次访问该页面时,它可以在缓存中查找以前获取的资源并从磁盘检索它们,这通常比从网络上下载资源要快。合理的利用http 缓存,可以使你的网站再次被访问时的渲染速度大大提高。

cache-control

cache-control 是http1.1 协议中定义在header头里用来告诉浏览器和服务器对缓存机制的支持情况,通过给他设置不同的值来定义缓存策略。

Read More

前端优化-记一张页面的加载


web前端优化–其一

web前端是一门神奇的技术。我们编写html标记和css语言,屏幕上就会显示出漂亮的页面。
但浏览器到底是如何使用我们的 HTML、CSS 和 JavaScript 在屏幕上渲染像素的呢?

一张最简单的网页

 <!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>hello word</title>
</head>
<body>
  hello word
</body>
</html>

Read More

关于雪碧图的自适应


<!–markdown–>## 前言

之前对雪碧图的自适应大小并没有太多的了解,一直停留在scale大法的地步。今天趁着另一个同学来问我,去好好了解了一下。
主要参考了 http://www.cnblogs.com/aaronjs/archive/2015/08/20/4744014.html。这位同学写得很好,简单明了清晰。

情景

当我们在使用 rem 做移动端布局的时候,在享受rem的方便的时候,往往也很头痛雪碧图的自适应问题。毕竟雪碧图无法像 rem 一样跟着屏幕一起变大变小。于是乎就有了像 scale、或者使用多套雪碧图来适配多种屏幕等等。这里讲另一种方法。通过
background-positionbackground-size 的百分比属性。

主要思路

  • 通过 background-size 缩放雪碧图
  • 通过 background-position 百分比获取图片片段

小细节

  • background-size 的百分比是相对于元素本身的
  • background-position 的百分比是相对于雪碧图的
  • 为了减少数字计算精度,尽量使雪碧图横竖排的个数可以让100整数, 如4、5。

完整Demo

<p data-height="265" data-theme-id="0" data-slug-hash="PzbVRp" data-default-tab="css,result" data-user="hijimo" data-embed-version="2" class="codepen">See the Pen <a href="http://codepen.io/hijimo/pen/PzbVRp/">PzbVRp</a> by jimo (<a href="http://codepen.io/hijimo">@hijimo</a>) on <a href="http://codepen.io">CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>

在线demo:传送门

关于字蛛


<!–markdown–>字蛛是什么

字蛛是腾讯前端小组推出的一个font-face工具,主要用于解决网站设计时的字体问题。简述与用例见传送门

字蛛能干什么

它提供了一些便利允许你在某些情况下,让你的设计师随心所欲的使用字体而没后顾之忧。并且,这些字体是可以被使用到网页中去的。
<p><!–more–></p>

工作原理

设计师给我们的设计图上的字体往往美丽动人,但并非所有的客户机都拥有这漂亮的字体。font-face 允许我们使用自定义的字体,在加载网页的时候向客户发送字体文件。但和英文字体不同,中文字体往往都是10M以上,这在天朝的的网络大概需要40秒的加载时间。

字蛛作为一个工具,提供了一种便利:通过爬取网站内已使用的文本,将字体文件中不需要的字体通通删除后重新打包成eof,woff,ttf,svg等流行的web字体。新打包的字体文件由于只包含了很少的字体,所以可以得到令人满意的大小。

使用方式

官网上有很详细的使用说明。其实可以说是简单到了极致,只需要一句命令行语句就搞定了

font-spider /Users/jimo/Documents/website/demo.hijimo.com/fontspider/*.html

在线案例

嗯,我写了一个小demo.使用了目前很火的思源字体。 传送门

实现过程

字蛛使用了三个插件:

  • fontmin:百度出品,用于字体转换与压缩
  • cssom :用于css解析
  • cheerio :用于html解析

使用感受

  • 大小:
  1. 700个不重复中文 150k
  2. 458个不重复中文 86K
  3. 242个不重复中文 45k
  4. 100个不重复中文 21K
  5. 20个不重复中文 9K
  • 兼容性: @font-face 标记在ie6就已开始支持在ie9已经完全支持。见传送门
  • 关于源字体:字蛛官方有声明,必须要有ttf格式的字体
  • 关于ttf:并不是每一个ttf文件都允许被转换,首先该ttf字体充许这种转换。另有其他网友说有些偏门字体会出错,我没碰到过。
  • 关于用户体验:由于使用了外部字体。当第一次字体文件加载好的时候页面会闪一下,非常不友好。第二次或以后再访问由于cookie的存在并不会有这个问题。亦或者可以使用loading的页面事先加载好所需文件。
  • 关于使用场景:像企业官网、个人主页等使用少量不重复汉字的场景。博客或内容系统的标题、导航、菜单等非正文栏目。
  • 其他,睡醒了再补充

关于ie11下fontsize0与 rem


<!–markdown–>前言一

好像很久很久没有写博客了…

前言二

今天七夕,老板不让加班…

前言三

最近在工作中使用到了rem,随之引发了一个奇怪的bug…

关于rem

w3c对rem只有简短的一句概述:root em, a unit equal to the em size for the document root (usually html)。 使用根元素html的字体大小。它的出现,可以让我们更加快乐简单的去完成自适应布局顺带连字体大小都一起自适应了。
<p><!–more–></p>

bug表现

在ie11(还有微软新的旗鱼浏览器)下,部分使用了rem单位的元素仅能在预设的fontsize下工作,之后不管如何再更改html的大小,都不再起作用。最后花了半天的时间定位到原因为,失效的父容器中设置了font-size:0;

<p data-height="268" data-theme-id="0" data-slug-hash="ZGdKXP" data-default-tab="result" data-user="hijimo" class='codepen'>See the Pen <a href='http://codepen.io/hijimo/pen/ZGdKXP/'>ZGdKXP</a> by jimo (<a href='http://codepen.io/hijimo'>@hijimo</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//assets.codepen.io/assets/embed/ei.js"></script>
–bug呈现原因与解决方案

最终解决方案,在父容器中取消了font-size:0的css样式。关于bug出现的原因,鉴于其他浏览器都能正常工作,结合国内外友人碰到的ie11下的fontsize 与 em rem 的bug来看。暂定于这是ie11的bug!(此结论仅由目前我所拥有的知识与信息所得出,随时拥有变更的可能性,且不具有任何借鉴意义!)

w3c上对rem的描述.(传送门1 传送门2)。

转-CSS 与 HTML5 响应式图片

<!–markdown–>原文地址:iyunlu
随着 Retina 屏幕的逐渐普及,网页中对图片的适配要求也越来越高。如何让图片在放大了两倍的 Retina 屏幕显示依然清晰,曾经一度困扰着网页开发者,好在 CSS3 与 HTML5 已经着力在改变这种现状。那么到底什么是响应式图片呢?
<p><!–more–></p>

图片

什么是响应式图片?

响应式图片是指:用户代理根据输出设备的分辨率不同加载不同类型的图片,不会造成带宽的浪费。同时,在改变输出设备类型或分辨率时,能及时加载对应类型的图片

图片2

CSS 响应式图片

对于很多 IOS 开发者来说可能已经不太陌生了,为了适配Retina 屏幕,传统的 CSS3 实现方式是通过加载一张宽高分别放大两倍的图片,然后通过 Media Queries 使背景图片尺寸减小一倍「background-size:50% 50%;」,例如:

.mod .hd h3 { background-image:url(http://img02.taobaocdn.com/tps/i2/T10s3JXn4XXXXnbIAn-105-160.png );/* 普通屏幕 */ 

/* ------------ Retina ------------ */ 
@media only screen and (-o-min-device-pixel-ratio: 2/1), /* Opera */ 
       only screen and (min--moz-device-pixel-ratio: 2),        /* Firefox 16 之前 */ 
       only screen and (-webkit-min-device-pixel-ratio: 2),    /* Webkit */ 
       only screen and (min-resolution: 240dpi),                    /* 标准 */ 
       only screen and (min-resolution: 2dppx)                      /* 标准 */ 
{ 
    .mod .hd h3{ 
        background-image:url(http://img02.taobaocdn.com/tps/i2/T1t9wzXlxXXXczY8cm-212-310.png); 
        background-size: 106px 155px; 
    } 
}

两张图片的对比效果:
图片3

在制作@2x图片时需要注意一些问题:

如果类似上图一样是纯文字内容的图片,不要直接从大图片缩放为小图片,这样文字效果会有些失真,这是 Photoshop 渲染的问题。应该调整字号,再重新排版。可以直接看看一淘首页的效果

一淘

蓝框内是直接缩放图片大小的效果,红框内是把字号从32号改成16号的效果。

CSS3 Media Queries 中用来定义设备分辨率的是 「resolution」 媒体特性,同时派生出两个媒体特性,分别是 「min-resolution」和 「max-resolution」。该规范中规定:若查询 Non-Square Pixels (专业术语,指高度与宽度不等的像素,可以理解为「非正方形像素」。计算机屏幕上及高清晰度视频信号中的像素是正方形的(像素宽高比为 1:1)。标准清晰度数码视频信号中的像素都不是正方形的。例如:NTSC制式的像素高度大于宽度,而PAL制式的像素宽度则大于高度。)设备,在「&&min-resolution&&」查询中指定的值必须与最稀疏尺寸进行比较,在「max-resolution」查询中必须与最密集尺寸进行比较。对于「resolution」(没有「min-」或「max-」前缀)从不查询 Non-Square Pixels 设备。另外在 CSS image Level 3 image-resolution 属性中定义了一些单位,比如「dppx」,各浏览器支持情况如下:

请输入图片描述

  1. Chrome 支持私有属性「-webkit-min-device-pixel-ratio」和「-webkit-max-device-pixel-ratio」。
  2. Firefox 8.0 之前错误的接受了整数数值(不带单位),16 开始支持 dppx 单位。
  3. Change our implementation of the resolution media query to use CSS units
  4. David Barr 在 Webkit 实现了 CSS3 image-resolution 属性, 并且支持了 dppxdpidpcm 单位,具体 Chrome 哪个版本开始支持可以自行测试,相信 Media Queries 中很快也会支持了。

需要注意几点:

  1. -o-min-device-pixel-ratio 的取值是分数比如「2 /3」,Demo,详见:http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/
  2. Firefox 16 之前版本是「min–moz-device-pixel-ratio」,min 后面有两个「-」。
  3. 1dppx 相当于 96dpi。

显而易见,通过 Media Queries 来实现「响应式图片」还是很麻烦,CSS 代码的可维护性不高,有一些 hack 的味道。我们更期望一种原生的语法来选择不同的图片,值得庆幸的是 CSS image Level 4 中就实现了这种原生语法的 image-set。 image-set 语法:

&lt;image-set&gt; = image-set( [ &lt;image-set-decl&gt;, ]* [ &lt;image-set-decl&gt; | &lt;color&gt;] ) &lt;image-set-decl&gt; = [ &lt;image&gt; | &lt;string&gt; ] &lt;resolution&gt;

那么上面的例子我们可以改为:

background-image:url(http://img02.taobaocdn.com/tps/i2/T10s3JXn4XXXXnbIAn-105-160.png);/* 普通屏幕 */ 
background-image: -webkit-image-set(
url(http://img02.taobaocdn.com/tps/i2/T10s3JXn4XXXXnbIAn-105-160.png) 1x, 
url(http://img04.taobaocdn.com/tps/i4/T1947tXmJhXXcCfooh-210-320.png) 2x);/* Retina */

这里的单位「x」等同于「dppx」,将来是否统一还有待进一步讨论。注意 Webkit 目前只实现了 url() 形式的取值,color、-gradient() 等暂不支持,而且「x」取负值似乎也是合法的

例子2

以下是一些常见移动设备的「min-device-pixel-ratio」值:

-webkit-min-device-pixel-ratio: 1.0

  1. 所有非 Retina 的 Mac
  2. 所有非 Retina 的 iOS 设备
  3. Acer Iconia A500
  4. Samsung Galaxy Tab 10.1
  5. Samsung Galaxy S
  6. 其他设备

-webkit-min-device-pixel-ratio: 1.3

  1. Google Nexus 7

-webkit-min-device-pixel-ratio: 1.5

  • Google Nexus S
  • Samsung Galaxy S II
  • HTC Desire
  • HTC Incredible S
  • HTC Velocity
  • HTC Sensation

-webkit-min-device-pixel-ratio: 2.0

  • iPhone 4
  • iPhone 4S
  • iPhone 5
  • iPad (3rd generation)
  • iPad 4
  • 所有 Retina displays 的 Mac
  • Google Galaxy Nexus
  • Google Nexus 4
  • Google Nexus 10
  • Samsung Galaxy S III
  • Samsung Galaxy Note II
  • Sony Xperia S
  • HTC One X

HTML5 响应式图片

CSS image-set 解决了背景图片的响应式问题,但是 HTML中的 img 元素怎么办呢?正当我一筹莫展的时候,2011年11月 @brucel 提出了HTML5 的一个草案:

&lt;picture alt=&#34;&#34;&gt;
    &lt;source src=hires.png media=&#34;min-width:800px&#34;&gt;
    &lt;source src=midres.png media=&#34;min-width:480px&#34;&gt;
    &lt;source src=lores.png&gt;
    &lt;!-- 不支持的浏览器降级处理 --&gt;
    &lt;img src=midres.png alt=&#34;&#34;&gt;
&lt;/picture&gt;

于此同时,其他的一些想法如雨后春笋般涌现出来,于是 W3C 社区讨论组 Responsive Images Community Group 应运而生。最新的规范在这里:http://picture.responsiveimages.org/ 。截止本文发布时间,最近一次更新是 2013年1月7日,规范示例:

&lt;picture width=&#34;500&#34; height=&#34;500&#34;&gt;
    &lt;source media=&#34;(min-width: 45em)&#34; srcset=&#34;large-1.jpg 1x, large-2.jpg 2x&#34;&gt;
    &lt;source media=&#34;(min-width: 18em)&#34; srcset=&#34;med-1.jpg 1x, med-2.jpg 2x&#34;&gt;
    &lt;source srcset=&#34;small-1.jpg 1x, small-2.jpg 2x&#34;&gt;
    &lt;img src=&#34;small-1.jpg&#34; alt=&#34;&#34;&gt;
    &lt;p&gt;Accessible text&lt;/p&gt;
&lt;/picture&gt;

可以看到这里的「srcset」属性类似 image-set,通常情况下,srcset 里面的资源是具有 fallback 特性的,也就是说第一个图片资源无法加载的时候可以跳过加载后面的备用资源。 但是 Apple 的 eoconnor 提出的方案是这样的:

&lt;img src=&#34;foo-lores.jpg&#34; srcset=&#34;foo-hires.jpg 2x,
                                 foo-superduperhires.jpg 6.5x&#34; 
                                 alt=&#34;decent alt text for foo.&#34;&gt;

诚然,任何一个新标准的提出,都会存在各种不同的声音,这是好事,作为网页的最终开发者其实并不太关心实现语法。有任何问题大家也可以直接到 HTML5 中文兴趣小组参与讨论。

小结

本来想把新年的第一篇文章写的欢乐一些,不过貌似没啥槽点。HTML5 响应式图片的草案还刚刚开始,不过前景还是很美好的。目前我们能做的就是在CSS 中使用 image-set 属性值,因为目前大部分 Retina 屏幕的设备的浏览器都是基于 Webkit 内核的,如果有特殊的需求可以使用 Media Queries。