背景描述
最近版本上线了一些新功能。隔天测试也立即反馈了一个新问题。就是当操作3000条的大数据列表后，第一个被调用的接口就会queued 2min之久。
问题分析
看到接口返回过慢，最开始并未怀疑是前端问题，而是第一转给后端协助排查。但是当仔细查看devtools下network面板发现queued竟然就要两分钟。
这一下就发现问题并不好排查，因为虽然3000条数据很大，但是并不应该影响浏览器请求接口。这里有关浏览器的知识。多进程和js单线程。以下个人理解，如有问题，希望大家补充。
浏览器内核中线程的关系。GUI和js引擎互斥。因为js是可以直接操作页面dom的。因此当修改页面上元素属性的同时，GUI渲染页面。那么渲染树上的dom元素的数据可能因为两者共同作用而出问题。所以浏览器为了防止渲染出现数据不一致问题。从根本上就杜绝了GUI渲染线程与js引擎同时作用。两者不能同时作用的原因。也说明了，GUI更新页面内容的同时，JS引擎线程不能被执行。
通过上述分析，我们知道当JS线程进行巨量计算的话，GUI也需要等待。那样用户就会感觉巨卡无比。GUI渲染大量数据的话JS线程也会等待。
分析结论，虽然有3000条数据，但是页面并不卡顿，代表JS线程未堵塞。那么接口堵塞与JS执行无关。
相关知识梳理
浏览器接口调用是在那个进程的工作呢？
带着疑问，我们梳理下浏览器进程的知识点吧。（浅梳理，更深层次大家自行搜索或评论区补充）
浏览器主要的进程有四个。
- 主进程。用于资源分配，以及控制其他进程的创建和销毁。是老大的地位。还负责浏览器界面和全局交互（下一页，上一页等），网络资源的管理，下载等。
- GPU进程。用于渲染页面。
- render进程。渲染每一个页签内容，也是我们前端打交道最多的进程。
- 插件进程。承载浏览器内每一个插件。
经验和教训
- 接口queued问题，仍未为解决，但是应该与js线程无关。
- 网络资源属于主进程。
- render进程不应该影响主进程下载。可能与页面渲染有关。
结束语
本文意在抛砖引玉，虽然发现问题，分析浏览器行为，但仍未实质解决掉。但范围上，已经限定在渲染上。没有具体指出，是因为大家渲染的组件更不相同，不能统一处理。望理解。
上善若水，水善利万物而不争。 ——老子
