性能指标

在 User-centric Performance Metrics 一文中，共提到了 4 个页面渲染的关键指标。

此外，性能优化的时候经常也会讨论到以下指标：

1. First View（第一个视图）：浏览器中的缓存和Cookie全部清空时，第一次访问该页面
2. Repeat View（重复试图）：首次视图测试结果完成后，不清除任何数据，再次访问此页面的测试结果
3. Load Time（整页加载时间）：从初始化请求，到加载所有静态内容（图片、CSS、JavaScript等)完成
4. First Byte（首字节时间）：从用户开始导航到页面直到服务器响应的第一位到达的时间。大部分时间通常称为“后端时间”，并且是服务器为用户构建页面所花费的时间量
5. Start Render（开始渲染）：页面上显示内容的第一个时间点，在这之前显示一个空白页
6. Speed Index（加载速度指数）：可见页面加载的视觉进度，并计算内容绘制的总速度，以毫秒为单位
7. DOM Elements（DOM元素数量）：测试结束后，页面上的DOM元素个数
8. Document Complete（文档加载完成）：从初始化请求，到加载所有静态内容（图片、CSS、JavaScript等)完成，可以理解为开始执行window.onload
9. Full Loaded（所有元素加载完成）：从初始化请求，到文档加载完成，2秒内没有网络请求的时间，包括在主网页加载后由JavaScript触发的任何活动
10. Requests（HTTP请求数）：整个页面的请求数
11. Bytes in（传输的字节量）：加载页面下载的数据量，一般指页面大小

背景

微服务框架下服务个数多、调用链路较长，其中一个服务出问题会影响到整条链路。但QA提测往往需要该条链路上的多个服务配套测试，甚至是同时测试一个服务的多个演进版本。

提供稳定环境 和 多服务/多版本同时测试 看似相悖的需求，通过泳道“Swimlane”能够得到解决。

测试过程中会遇到的问题

1. 关于一个服务上的多个需求的同时测试，存在服务抢占分支测试的问题;
2. 不同的业务组在测试时依赖的第三方服务有改动或正在进行新需求测试影响本业务测试。

微服务框架下服务个数多、调用链路较长，其中一个服务出问题会影响到整条链路。但QA提测往往需要该条链路上的多个服务配套测试，甚至是同时测试一个服务的多个演进版本。提供稳定环境 和 多服务/多版本同时测试 看似相悖的需求，通过泳道“Swimlane”能够得到解决。

导读

本篇文章主要是为了宣导 GraphQL 技术，包含了介绍 GraphQL 能解决的问题和尚不完善的地方，以及我们团队在实际业务场景中的实践总结。希望读者能通过这篇文章，了解到 GraphQL 的优缺点，在遇到合适的场景中能多一个技术选择，并在日后的实践过程能有所参考，避免重复踩坑。

背景

目前在我们绝大多数的场景中，后端提供的接口是基于 RESTful 风格的接口，而 RESTful 架构风格的服务是围绕资源展开的。随着业务复杂度的提高，前端页面信息和交互体验的愈加复杂，RESTfull风格的接口，在实际研发场景下，通常会遇到以下几处痛点：

背景

前后端分层协作的各种模式，协作的边界是数据，后端提供数据服务接口，前端消费数据实现人机交互。
在当今强调前后端分离的架构下，前后端要交互的就只有数据。虽然我们通过 node 层承载了部分后端服务的功能，但是大多数情况下，前端依赖的数据，还是由后端同学提供的 API 接口提供。

这种协作方式在一些情况下，会遇到以下问题：

• 服务层 API 相对稳定，体验者 API 经常变化
• 跨团队低效协作
• 资源协调困难

开发

基于master分支拉出开发分支，以feature/***格式命名
本地进行调试的时候，通过本地文件的方式进行集成

1

yarn add local-path-to-repo

或者

1

"repo": "local-path-to-repo",

例如

1

"@gfe/saas-account-filter": "../saas-account-filter",

在 Safari 使用 iFrame 方式嵌入 Cross Domain 页面，会发生 iFrame 无法使用 Cookie，导致每次的 Request 携带的 Session id 都不一样或者登陆信息缺失。
虽然通过改变 Safari 的安全性设置可以解决此问题，但是要让用户修改设置非常困难。我们可以通过 JavaScript 来巧妙地解决该问题。

本文参考 https://blog.johnwu.cc/article/cookie-session-not-working-in-iframe.html

场景

我们接入第三方页面的时候，通常是通过 iFrame 方式进行嵌入。有些用户在 Safari 浏览器访问的时候，偶尔会发生 Cookie 缺失，导致用户信息缺失的情况。这种情况的根本原因在于 Safari 的安全性设置。如果 iFrame 的 Domain 没有被 Safari 直接存取过，Safari 就不会认可你的 Domain ，不允许存取Cookie。简而言之，就是只要你曾经在网址输入框输过该 Domain，Safari 就会认同你的 domain ，允许存取 Cookie。

基本概念

中间件的本质就是一个函数，在收到请求和返回相应的过程中做一些我们想做的事情。

Express对中间件的作用的描述如下：

• 执行任何代码
• 修改请求和响应对象
• 终结请求-响应循环
• 调用堆栈中的下一个中间件

中间件可分为以下五类（原理相同，只是用法不同）：

• 应用级中间件
• 路由级中间件
• 错误处理中间件
• 内置中间件
• 第三方中间件

从字面上，async 是“异步”的简写，而 await 可以认为是 async wait 的简写。所以应该很好理解 async 用于申明一个 function 是异步的，而 await 用于等待一个异步方法执行完成。

另外还有一个很有意思的语法规定，await 只能出现在 async 函数中。然后细心的朋友会产生一个疑问，如果 await 只能出现在 async 函数中，那这个 async 函数应该怎么调用？

如果需要通过 await 来调用一个 async 函数，那这个调用的外面必须得再包一个 async 函数，然后就进入了死循环。究竟底层是怎么实现的呢？

我的博客最开始是基于 Octopress 进行搭建，但是 Octopress 已经很久没有更新了。在我更换了新电脑后，最新的一次我试图在新 MBP 上搭建 Octopress 博客时，一直构建失败，这让我打定主意更换掉它。

调研了一下目前流行的方案后，最终决定迁移到 Hexo，主要的原因是：

• Hexo 可以生成静态文件，这样很方便地托管到 GitHub 上；
• Hexo 是基于 Node 的，而 Node 的速度非常快，相信所有的前端同学都不会拒绝 Node :)；
• Hexo 对 Octopress 的迁移很友好，图片引用方式完全一样，原先的文章不需要进行太多的改动。

基础理论能力

主要考察面试者基础语法概念（面向对象、js/css/html基础语法）、常用框架概念（Vue、React、Angular等）、基础网络知识（http协议、cookie、CDN、request等）、存储、兼容性、前端优化等

基础

• 你如何理解什么是js中的对象概念？
• js有哪些基础类型？
• const 和var的区别
• css中flex布局
• 多个页面之间如何进行通信
• CSS匹配机制
• webstorage
• http状态码
• .etc