Ben 发布的文章

HTTP/2 时代的开启为前端开发带来了最佳体验。

如果你对 HTTP/2 有所了解,那你可能用过它,或者至少想过怎样能把它融入你的项目中。尽管有很多关于它如何改变工作流程,提高 Web 速度和效率等方面的猜想,但最佳使用方式还没有定下来。这里我想讲的就是我在之前的项目中所发现的 HTTP/2 的最佳实践。

如果你还不确定什么是 HTTP/2,或者为什么它能改进你的工作,可以先看看我介绍背景方面的第一篇文章

记住:开始之前,我要告诉你,尽管你的浏览器可能支持 HTTP/2,但你的服务器可能不支持。检查你的主机托管服务,看看他们是否提供 HTTP/2 的支持。否则你可能要建立你自己的服务器。这篇文章并不会涉及这方面该如何做,但你可以查看 http2 github 页面,找一找这方面的工具。

热身工作

首先组织好你的文件。看一看下面的文件树结构,作为组织你的样式表的起点:

/styles
|── /setup
|     /* 变量、混入(minin)和函数 */
|── /global
|     /* 能放在任何组件和部分中的可重用组件 */
|── /components
|     /* 特殊组件和部分 */
|── setup.scss // setup 样式索引
|── global.scss // 全局样式索引

这会把你的样式分到三个目录下面:setupglobalcomponenets。接下来我会说明这些目录对你的项目有什么用。

setup 目录

setup 目录保存所有的变量、函数、 混入 minin 以及一些正常编译需要的其它文件的定义。要想让这个目录物尽其用,把这个目录下所有内容导入到 setup.scss 文件中是个很不错的主意,这样这个文件就会像下面所展示的一样:

/* setup.scss */

/* 变量 */
@import "setup/variables/colors";

/* 混入 */
@import "setup/mixins/color";

/* 函数 */
@import "setup/functions/color";

... 等等

现在我们能快速引用这个站点中的所有定义,应该确保在所有的样式文件顶部包含我们这里创建的这个文件。

global 目录

接下来的目录,global 目录,应该包含可在当前站点的多个部分或者每一个页面中重复使用的组件。像按钮、文本、主要样式,以及你的浏览器默认设置应该放在这里。我不建议把页面的头部或底部样式放在这儿,因为某些项目中没有头部,或者不同页面头部不同。而且,底部永远是页面的最后一个元素,所以在用户加载完当前站点的其它东西前,不必过分优先考虑加载底部样式。

记住,如果没有那些定义在 setup 目录下的东西,你的 global 样式就可能没有作用,你的 global 文件看起来应该像这样:

/* global.scss */

/* 应用定义 */
@import "setup";

/* 全局样式 */
@import "global/reset";
@import "global/buttons";
@import "global/typography";
@import "global/grid";

... 等等

注意,首先要做的就是导入 setup 样式。这样的话,之后的文件都可以引用这个样式里的定义。

由于站点内的每个页面都需要 global 样式,我们可以用典型的方式,在 <head> 标签内用一个 <link> 标签来加载它们。你所看到的将是一个十分小巧的 css 文件,或者说理论上小巧的,这取决于你需要多少全局样式。

最后,你的组件

注意,我没有在上述目录树中的 components 目录里包含索引文件。这是 HTTP/2 所带来的效用。直到现在,我们已经按照标准步骤构建了一个典型的站点,保持相当简单的结构,仅选择全局化那些最重要的样式。组件充当它们自己的索引文件。

大多数开发者有独特的组织组件的方式,因此我并不想影响你的策略。但是,你所有的组件看起来应该像这样:

/* header.scss */

/* 应用定义 */
@import "../setup";

header {
  // 样式
}

... 等等

同样的,你要把 setup 样式包含进来,确保所有东西在编译时都定义过。除了编译这些文件,以及可能要把他们放到 /assets 目录,以便很容易找到模版,对这些文件你不必 拼接 concatenate 压缩 minify 它们或者改变什么。

现在样式表已经差不多了,构建站点应该很简单。

构建组件

或许对于模板语言你有自己的选择,这取决于你的项目,有可能是 Twig、Rails、Jade 或者 Handlebars。我认为考虑组件最好的方式是它是否有自己的模版文件,它该有个与名字相应的样式。这样你的项目中,模版和样式的比例就会是个不错的 1:1 的比例,而且你知道哪个文件有哪些东西,哪里有哪个文件,因为它们的命名是有规律的。

现在它正步入正轨,用好 HTTP/2 的多种功能十分简单,让我们做一个模版:

{# header.html #}

{# compiled header styles #}
<link href="assets/components/header.css" rel="stylesheet" media="all">

<header>
  <h1>This Awesome HTTP/2 Site</h1>
  ... 等等

非常好!在模版里你可能有更简单的方式链接到资源,但这里显示你所要做的仅是在开始构建时,在模版文件中链接一个小小的头部样式。这将允许你的站点仅仅加载特定资源到任意给定页面的组件中,而且,能够设定页面从头到脚的组件的优先级。

结合在一起

现在所有的组件都有结构,浏览器将会类似以下方式来渲染它们:

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" media="all" href="/assets/global.css">
  </head>
  <body>

    <link rel="stylesheet" media="all" href="/assets/components/header.css">
    <header>
      ... etc
    </header>

    <link rel="stylesheet" media="all" href="/assets/components/title.css">
    <section class="title">
      ... etc
    </section>

    <link rel="stylesheet" media="all" href="/assets/components/image-component.css">
    <section class="image-component">
      ... etc
    </section>

    <link rel="stylesheet" media="all" href="/assets/components/text-component.css">
    <section class="text-component">
      ... etc
    </section>

    <link rel="stylesheet" media="all" href="/assets/components/footer.css">
    <footer>
      ... etc
    </footer>

  </body>
</html>

这是一个高级别方法,但你的项目中可能有调整的更细致的组件。例如,在头部的 <nav> 组件可能要加载自己的样式表。尽你所能地自由发挥,让组件更有作用 - HTTP/2 不会因这些需求而阻碍你!

结论

这只是一个关于如何在前端用 HTTP/2 构建项目的基本介绍,仅是皮毛而已。你可能注意到我上面所用的方法有的还有改进的空间。请不吝赐教!正如我在第一篇文章中所说的,HTTP/2 可能颠覆自 HTTP/1 以来我们所熟知的某些标准,所以要慎重思考和实践,以便高效使用 HTTP/2 的开发环境。


via: https://www.viget.com/articles/getting-started-with-http-2-part-2

作者:Ben 译者:GitFuture 校对:jasminepeng

本文由 LCTT 组织编译,Linux中国 荣誉推出

用披萨来说明当你订单数很大的时候 HTTP/2 是怎么打败 HTTP/1.1 的。

在建立网站和应用的方式上 HTTP/2 有些令人惊叹的改变,在 HTTP/2 发布后的一年半,几乎 10% 的网站使用了 HTTP/2。它绝对值得采用,但是这篇文章应该首先推给使用 HTTP/2 的前端开发者。这个连载的文章是指导前端开发者怎么转换到 HTTP/2。

本文涵盖了 HTTP/2 对 HTTP/1.1 来说有什么提高的内容,并且向前端开发者介绍了 HTTP/2。

再次让我想起什么是 HTTP ...

超文本传输协议,也就是 HTTP,这个协议决定了 web 内容怎么传输。HTTP/1.1 在 1999 年被标准化,那时候的 web 和现在有很大的不同,表格霸占了整个网络。样式通常被内联在元素中,如果网站管理员更加的细致,他们会在头部写个 <style>标签。 JavaScript 也被丢在文档里面,那时候完整的网站通常也不会超过几页。

HTTP/1.1 预计这种情况会持续一段时间,所以它并没有太过关注在让一个站点可以加载大量的资源方面,因为那时候的开发者并不需要这个。因此它使用了一个非常简单的方式来处理资源,你访问一个资源然后服务器去寻找它,并且返回你访问的资源,或者告诉你这个资源不存在。这种被叫作"线头堵塞"方式非常高效,但是当你需要多个资源的时候,这个进程会依次寻找每个资源。这意味着在你访问第二个资源之前,服务器必须找到你访问的第一个资源并且载入它,或者告诉你没找到。

大型站点的发展

在 1999 年之后的几年里,随着 php 和其他像 Rails 这样的动态语言的崛起,站点变得越来越复杂。css 文件也随着向响应式开发的转变而变的越来越大,因此像 Sass 这样的可以创造一个简单的工作环境的 CSS 编译器就应运而生。 JavaScript 也在 web 上有了更大的作用,它允许开发者编写复杂的应用,这曾经只是 C++ 开发人员的工作。随着 Retina 和高清显示屏的兴起,也让图片变得更高清。随着这些改变,文件大小呈现指数式的增长,使得本来是等待几个字节的资源变成了加载几千字节,甚至在某些情况下有几兆。当你开始载入页面的其它东西前,必须先载入数百 K 的东西,你只能乐观的假设你的用户有很快的网络接入。

想象 HTTP/1.1 是个过去的那种柜台购买式的街旁披萨店。你能自己过去并且预定一个雪碧和 2 片 Angry Hawaiian ,然后等待 3 分钟。他们可以很容易地处理这些,实际上这是一个蓬勃发展的商业模式-定单简单、处理迅速。

然而,一旦你决定在同样的披萨店主办一场小区域的季度颁奖典礼,事情就变的更复杂了。每个人都预定不同的东西,快速而杂乱无章让等待时间直线上升。

哪里是 HTTP/2 的舞台

HTTP/2 对前端开发者主要的承诺就是复用。意思就是资源请求能发生在同一时间,并且服务器能马上响应这些资源。在请求之间没有等待,因为它们发生在同一时间。

使用同样的比喻,HTTP/2 允许披萨店在餐馆他们自己区域举办派对。派一个服务员接受订单,并把所有已经准备好的订单交付。当其他人的比萨在制作的时候,你也不需要花 30 分钟去等待你的雪碧,它们在第一批交付的东西之中。这方式使得管理大量订单更加简单,并且防止人们等他们的订单时间太长。

复用带给我们的 web 开发的大变化是改变了文件的加载方式。帮助绕过资源加载的 HTTP/1.1 瓶颈的方式是通过连接和压缩需要被加载的文件。所有任务运行器都默认采取这样的操作方式,或者需要作一点小设置就行。和过去一样,开发人员可以将图像放在 精灵拼图 sprite sheets 中,这会减少了对服务器的请求数。

改进 HTTP/1.1

将文件连接起来是个处理 HTTP1.1 的请求限制问题的非常聪明的方式,但是连接文件的主要问题是它要求用户第一次访问整个网站时下载所有的资源。一旦它们载入后,浏览器就会缓存所有的资源。这能提高用户每次访问网页时的速度,但是前期负载很重,对跳出率不利。此外,他们可能为所不访问的页面加载资源。期望用户访问每个页面以查看每个样式,并与每个脚本进行交互是不现实的。此外,在加拿大和欧洲以及几乎每个美国移动提供商的地方,有每月的带宽上限。不是加载额外的 54 千字节的内容就会超过每月的流量限制,而是让我们假设用户想保留这些额外的流量看 Taylor Swift 的 gif。

使用 HTTP/2 和多路复用,您可以开发一些最高效的网站,但它需要一些重新思考、甚至​​撤销之前的最佳做法。重复一次,我的目的是加快 HTTP/2 的会话,使用我们新的工具,我们可以发现这些新的最佳的做法。

在我的下一篇文章,我将探索建设基于 HTTP/2 的网站的一些最好方式


via: https://www.viget.com/articles/getting-started-with-http-2-part-1?imm_mid=0eb24a&cmp=em-web-na-na-newsltr_20161130

作者:Ben 译者:hkurj 校对:wxy

本文由 LCTT 组织编译,Linux中国 荣誉推出