最近面试中遇到了关于性能优化的提问，所以整理了一下
1.script标签放在header里和放在body底部里有什么区别？
2.前端性能优化指标有哪些？怎么进行性能检测？
3.SPA（单页应用）首屏加载速度慢怎么解决？
4.如果使用CSS提高页面性能？
- 怎么进行站点内的图片性能优化？
6.虚拟DOM一定更快吗?
7.有些框架不用虚拟dom，但是他们的性能也不错是为什么？
8.如果某个页面有几百个函数需要执行，可以怎么优化页面的性能？
9.讲一下png8、png16、png32的区别，并简单讲讲 png 的压缩原理
10.页面加载的过程中，JS文件是不是一定会阻塞DOM和CSSOM的构建
11.React.memo()和useMemo(的用法是什么，有哪些区别?
12.导致页面加载白屏时间长的原因有哪些，怎么进行优化？
13.如果一个列表有100000个数据，这个该怎么进行展示？
14.DNS预解析是什么？怎么实现？- 在React中可以做哪些性能优化?
16.浏览器为什么要请求并发数限制？
17.如何确定页面的可用性时间，什么是PerformanceAPI?
18.谈谈对window.requestAnimationFrame的理解- css加载会造成阻塞吗？
20.什么是内存泄漏？什么原因会导致呢？- 如何用webpack来优化前端性能
22.说说常规的前端性能优化手段- 什么是CSS Sprites?
- CSS优化、提高性能的方法有哪些？
- script标签中，async和defer两个属性有什么用途和区别?
暂时就整理了这些，都整理了对应的答案，觉得有帮助可以【点击此处】哈~
1.Script标签放在header里和放在body底部里有什么区别?
将script标签放在head和body底部，会对页面的加载和性能产生不同的影响：
script标签放在head部分
优点：
1.预加载：浏览器在渲染页面之前，会先下载和解析所有在head部分的脚本文件。这样可以确保脚本在页面加载过程中随时可以被调用。
2．全局可用性：一些脚本，特别是需要在页面一加载就运行的脚本，适合放在head中。
缺点：
1.阻塞渲染：浏览器在遇到script标签时会暂停HTML的解析和渲染，直到脚本下载并执行完毕。这可能会导致页面加载变慢，尤其是当脚本文件较大或者需要从远程服务器下载时。
2，页面白屏时间延长：用户可能会看到页面在加载过程中有一段时间的白屏，直到脚本加载完成。
script标签放在body底部
优点：
1．非阻塞渲染：将script标签放在body底部意味着浏览器可以优先下载和渲染HTML内容，这样用户可以更快地看到页面内容。
2.更好的用户体验：用户不会因为等待脚本加载而长时间看到空白页面。页面内容会先显示出来，然后再执行脚本，这提高了页面的响应速度和用户体验。
缺点：
1．延迟脚本执行：如果某些脚本需要在页面加载之前运行（如某些初始化脚本），放在body底部可能会导致这些脚本运行延迟，影响功能。
现代优化技术
1.defer属性：在head部分使用script标签时，可以添加defer属性。这个属性会告诉浏览器异步下载脚本，但在页面解析完成后再执行脚本。这样既可以保持脚本全局可用，又不会阻塞页面渲染。
2.async属性：async属性也用于异步加载脚本，但它会在脚本下载完成后立即执行，不考虑页面的解析进度。这对某些独立的、不会依赖于其他脚本或DOM结构的脚本很有用。
总结
head部分：适合需要立即执行的脚本，但可能阻塞页面渲染。
body底部：适合一般脚本，能提高页面加载性能和用户体验。
·使用defer或async：现代浏览器支持这些属性，可以同时兼顾性能和功能需求。
2.前端性能优化指标有哪些？怎么进行性能检测？
参考答案:
概述
web性能说简单点就是网站打开速度快不快，页面中的动画够不够流畅，表单提交的速度是否够快，列表滚动页面切换是否卡顿。性能优化就是让网站变得快。
在MDN上对web性能的定义是网站或应用程序的客观度量和可感知的用户体验。比如减少页面加载时间（减少文件体积，减少HTTP请求，使用预加载)，让网站尽快可用(懒加载或者分片加载)，平滑的交互性(使用CSS替代JS动画，减少uI重绘)，感知表现(加载动画，1oading等给用户感觉快)，性能测定(性能指标，性能测试，性能监控以便持续优化，毕竟性能优化是个持续的过程)。
页面性能关乎到用户的留存，网站的转换率，用户体验和网站的传播，甚至影响搜索排名遭到用户投诉，当然也会影响开发的效率。
1.性能指标
进行性能优化之前首先要知道要在哪些方面做性能优化。
首先需要了解性能指标，多快的速度才算快呢？可以使用专业的工具可量化的评估出网站或应用的性能表现。
立足于网站页面响应的生命周期，分析出造成较差性能表现的原因，最后进行技术改造，可行性分析等具体的优化措施，持续迭代优化就可以了。
事实上性能是相对的，他并不是绝对的概念。对于一个用户而言在不同的网络环境下访问页面的速度可能是不同的。即使相同的网站在懒加载的情况下也会显得快。
在讨论性能的时候精确地，可量化的指标是很重要的。但是仅仅因为一个度量标准是基于客观准备并且可以定量的度量的，并不一定意味这些度量是有用的。对于Web开发人员来说，如何恒量一个Web页面的性能一直都是一个难题。
最初，开发人员使用Time to To Byte。DomContentLoaded和Load这些恒量文档加载进度的指标，但他们不能直接反应用户视觉体验。
为了恒量用户视觉体验，Web标准中定义了一些性能指标。这些性能指标被各大浏览器标准化实现，例如First
Paint和First Contentful Paint。
还有一些由Web孵化器社区组提出的性能指标,如Largest COntentfulPaint，Time toInteractive
First Input Delay, First CPU Idle。
另外还有 Google 提出的 First Meaningful Paint，Speed Index。
百度提出的First Screen Paint。
这些指标之间并不是毫无关联，而是在以用户为中心的目标中不断演进出来的，有的已经不再建议使用，有的被各种测试工具实现，有的则可以作为通用标准可用于生产环境测量的API。
2.RAIL性能模型
RAIL是Response，Animation，Idle和 Load 的首字母缩写，是一种由 Google Chrome团队于 2015年提出的性能模型，用于提升浏览器的用户体验和性能。
RAIL模型的理念是以用户为中心，最终目标并不是让你的网站在任何特定设备上都能运行很快，而是使用户满意。
Response：应该尽可能快速的响应用户的操作，应在在100ms以内响应用户输入。
Animation：在展示动画的时候，每一帧应该以16ms进行渲染，这样可以保持动画效果的一致性，并且避免卡顿。
Idle：当使用js主线程的时候，应该把任务划分到执行时间小于50ms的片段中去，这样可以释放线程以进行用户交互。50ms为单位是为了保证用户在发生操作的100ms内做出响应。
要使网站响应迅速，动画流畅，通常都需要较长的处理时间，但以用户为中心来看待性能问题，就会发现并非所有工作都需要在响应和加载阶段完成，完全可以利用浏览器的空闲时间处理可延迟的任务，只要让用户感受不到延迟即可。利用空闲时间处理延迟可减少预加载的数据大小，以保证网站或应用快速完成加载。
Load：应该在小于1s的时间内加载完成你的网站，并可以进行用户交互。根据网络条件和硬件的不同，用户对性能延迟的理解也有所不同，在3G网络需要花费更多的时间，5s是一个更现实的目标。
基于用户体验的性能指标其中包括以下几个比较重要的性能指标。
- FCP (First Contentful Paint)
首次内容绘制，浏览器首次绘制来自DoM的内容的时间，内容必须包括文本，图片，非白色的canvas或svg，也包括带有正在加载中的web字体文本。这是用户第一次看到的内容。
2.LCP (Largest Contentful Paint)
最大内容绘制，可视区域中最大的内容元素呈现到屏幕上的时间，用以估算页面的主要内容对用户的可见时间。
img图片，video元素的封面，通过url加载到的北京，文本节点等，为了提供更好的用户体验，网站应该在2.5s以内或者更短的时间最大内容绘制。
3.FID (First Input Delay)
首次输入延迟，从用户第一次与页面进行交互到浏览器实际能够响应该交互的时间，输入延迟是因为浏览器的主线程正忙于做其他事情，所以不能响应用户，发生这种情况的一个常见原因是浏览器正忙于解析和执行应用程序加载的大量计算的JavaScript。
4.TTI (Time to Interactive)
网页第一次完全达到可交互状态的时间点，浏览器已经可以持续的响应用户的输入，完全达到可交互的状态的时间是在最后一个长任务完成的时间，并且在随后的5s内网络和主线程是空闲的。从定义上来看，中文名称叫持续可交互时间或可流畅交互时间更合适。
5.TBT (Total Block Time)
总阻塞时间，度量了FCP和TTI之间的总时间，在该时间范围内，主线程被阻塞足够长的时间以防止输入响应。
只要存在长任务，该主线程就会被视为阻塞，该任务在主线程上运行超过50毫秒。
线程阻塞是因为浏览器无法中断正在进行的任务，因此如果用户确实在较长的任务中间与页面进行交互，则浏览器必须等待任务完成才能响应。
6.CLS (Cumulative Layout Shift)
累计布局位移，CLS会测量在页面整个生命周期中发生的每个意外的布局移位的所有单独布局移位分数的总和，他是一种保证页面的视觉稳定性从而提升用户体验的指标方案。
用人话来说就是当点击页面中的某个元素的时候，突然布局变了，手指点到了其它位置。比如想点击页面的链接，突然出现了一个banner。这种情况可能是因为尺寸未知的图像或者视频
这也是谷歌指定的web性能指标标准，谷歌认为之前的标准太复杂，指标太多了，在2020年重新进行了梳理，简
化到了三个。加载性能LCP，交互性FID，视觉稳定性CLS。只需要做好这三个，网站的性能基本上就可以了。
测量Web Vitals的工具有很多，比如Lighthouse，web-vitals，浏览器插件web vitals。
1.Web-Vitals
2.浏览器插件
谷歌浏览器可以直接在插件市场中查找并且安装webvitals。安装完成之后浏览器的右上角会多出插件标志，点击就会显示页面的性能指标。
4.性能测试
性能检测是作为性能优化过程中的一环，他的目的通常是给后续优化工作提供指导方向，参考基线以及千户对比的依据。性能检测并不是一次性执行结束后就完成的工作，他会在检测，记录和改进的迭代过程中不断重复。来协助网站的性能优化不断接近期望的效果。
- Lighthouse(灯塔)
Lighthouse是谷歌开发并开源的web性能测试工具，用于改进网络应用的质量，可以将其作为一个Chrome扩展程序运行，或从命令行运行。只需要为其提供一个需要审查的地址，Lighthouse就会对页面进行一连串的测试，生成一个有关页面性能的报告。
在浏览器的调试工具中默认就存在lighthouse选项，只需要切换至lighthouse，在右侧的选项区选中需要的选项。点击生成报告。
可以看到淘宝的首屏时间是0.6s²可交互时间是1.5s，总阻塞时间是10ms。最大绘制时间是1s。通过这些
指标就可以看到在哪方面存在性能瓶颈。
在下方会对渲染进行拍照截图，如果空白页面较多也能体现网站白屏时间过长。下面还会给一些优化建议。比如某
些资源过大，加载时间过长等，当然这些建议不并一定都是对的，只是一些建议。
最后是测试环境信息，不能制作一种环境的测试，要多环境测试。
2.WebPageTest
在线web性能测试工具(Security Verification),提供多地点测试。他只能测试已经发布了的网站。
输入需要测试的网页地址，点击starttest按钮就开始测试了，可以选择测试地理位置，测试的浏览器等。
这里会生成一份详细的测试数据，我这里没打开，打开再补图吧，尴尬...
5.Chrome DevTools
1．浏览器的任务管理器
可以查看当前Chrome浏览器中，所有进程关于GPU，网络和内存空间的使用情况，这些进程包括当前打开的各
个标签页，安装的各种扩展插件，以及GPU，网络，渲染等浏览器的默认进程，通过监控这些数据，可以定位可
能存在内存泄露或网络资源加载异常的问题进程。
更多工具->任务管理器
可以看到所有进行的进程，可以看到内存占用网络消耗。
2.Network网络分析
Network面板是一个常被用到的工具，通过它可以获取到网站所有资源的请求情况，包括加载时间，尺寸大小，
优先级设置以及HTTP缓存等信息。可以帮助开发者发现可能由于未进行有效压缩而导致资源尺寸过大的问题，未
配置缓存策略导致二次请求加载时间过长的问题。
3.Coverage
监控并统计出网站应用运行过程中代码执行的覆盖率情况。
统计的对象是JavaScript脚本文件与css样式文件，统计结果主要包括文件的字节大小，执行过程中已覆盖的
代码字节数，可视化的覆盖率条形图。
根据执行结果可以发现到底哪些尺寸较大的代码文件覆盖率较低，这就意味着这些代码文件中可能存在较多的无用
代码。
Ctrl + shift + p搜索coverage就会显示出来。
4.Memory 面板
主要用于分析内存占用情况，如果出现内存泄露，那么就可能带来网站崩溃的后果。
为了更细致和准确的监控应用网站当前的内存使用情况，Chrome浏览器提供Memory面板，可以快速生成当前的
堆内存快照。
5.Performance
使用Performance面板主要对网站应用的运行时性能表现进行检测和分析，包括页面的每秒帧数，CPu的消耗和
各种请求花费的时间。
7.性能优化路径
....
先展示到这里，觉得对大家面试有帮助欢迎随时交流，本文内容25题都有答案可以【 点击此处 】
