十六：从输入URL到打开页面可以做的优化

当用户在浏览器地址栏输入一个网址到看到整个页面

• 1.url解析 （客户端做）-> 2.DNS解析（域名解析）->3.建立TCP链接（TCP三次握手）->4.发送http请求，服务器处理请求，返回响应结果->5.关闭TCP的链接通道(TCP四次挥手)->6.浏览器渲染->7.代码运行中

性能优化汇总

• 1.利用缓存

  • 对于静态资源文件实现强缓存和协商缓存（xxx.html这种页面不进行强缓存，xxx.css/js/png...可以强缓存，每次更新在后面加哈希值或时间戳，这样HTML在加载的时候就会重新拉取资源了）
  • 对于不经常更新的接口数据采用本地存储做数据缓存

• 2.DNS优化

  • 分服务器部署，增加HTTP并发性（这导致DNS解析变慢）

  • DNS Prefetch

    
    
    DNS预解析.png
• 3. TCP的三次握手和四次挥手
  • Connection:keep-alive
• 4. 数据传输
  • 减少数据传输的大小 ->内容或者数据压缩（webpack等），服务器端开启GZIP压缩（一般能压缩60%左右）, 大批量数据分批次请求（例如：下拉刷新或者分页，保证首次加载请求数据少）
  • 减少HTTP请求的次数 ->资源文件合并处理，字体图标，雪碧图 CSS-Sprit，图片的BASE64

• 5.CDN服务器“地域分布式”

前端优化-减少白屏效果

• LOADDING 人性化体验(转圈圈)
• 骨架屏：客户端骨屏 + 服务器骨架屏
• 图片延迟加载

前端骨架屏和客户端骨架屏

• 前端骨架屏：开始只用默认的占位块占位（保证结构的美观）=>开始只加载第一屏数据（图片都是延迟加载），滚动到哪一屏幕，再去加载这一屏的数据和图片
• 客户端骨架屏：首屏内容都是服务器直接渲染好的（在服务器能抗住的情况下，比客户端一步步的渲染会更快一点）

CDN资源(地域分布式)：在北京发了一条微信，是发送到北京的服务器上，北京服务器再发送到总服务器，总服务器再下发到接受微信人的那个地域服务器。