在进行性能测试（压测）时，是否过滤掉对JavaScript、CSS等静态资源的请求，取决于你测试的目标和目的。
是测试服务端的性能还是前端的性能。这两种目的所涉及到的测试场景和工具等方法是不一样的。
- 一般的web产品，像css, jpeg等这种静态请求都是从应用层剥离出来的，一般可以放到最外层，减少对应用层的压力。所以测试业务功能时，这些资源通常不会对你的后端服务造成太大压力（除非它们是由后端动态生成的），并且它们会增加请求的数量和复杂性，但不会提供太多关于后端性能的直接信息。用JMeter或LoadRunner等工具进行后端性能测试。
- 从前端来看，要评估这些静态资源的访问响应时间，加载时间，尤其是js执行效率，前端加载速度可以通过一些比较成熟的工具进行评测，比如page speed，dynatrace，yslow，Lighthouse等，会生成评测报告告诉你一些优化意见，比如图片的压缩与合并等等。
- 不过滤的情况：
完整用户体验模拟：如果你的目标是模拟真实的用户访问体验，包括页面加载速度、资源下载时间等，那么不应该过滤这些请求。因为在实际应用中，用户的浏览器会请求这些资源，它们对页面加载时间有直接影响。
评估服务器带宽压力：静态资源往往占用了大量网络带宽，通过包含这些请求，可以更好地评估服务器的带宽使用情况和CDN性能。
- 过滤的情况：
关注核心业务逻辑：如果你主要关心的是服务器处理业务逻辑的能力，如数据库查询、API响应速度等，那么过滤掉这些静态资源请求可以使测试更专注于这些核心服务的表现。
资源已通过CDN分发：如果你的静态资源已经部署在CDN上，且CDN的性能稳定，单独测试这些资源对评估后端服务性能帮助不大，这时可能选择忽略它们。
简化测试配置：有时过滤掉这些请求可以简化测试配置，减少测试的复杂度，特别是在资源众多且与本次测试目标关联不大的情况下。
总之，是否过滤应基于你的测试目的和实际情况来决定。在某些情况下，你甚至可以设计不同的测试场景，一部分测试包含所有请求以模拟全面的用户体验，另一部分则专注于核心业务逻辑。这样可以从多个角度获得有价值的性能数据。
