JMeter is a defacto standard in performance measurement. There are a lot of existing plugins you can add easily to your project, but sometimes additional functionality needed. In this case JSR223 Sampler is the solution. With use of this sampler you can write your own script to use up response data.

Response times are really important on the internet. It is a cardinal question, how long should visitor waiting for the page to be loaded. Technical solutions are changing really fast, but users are the same. They need short loading times. Performance optimalization has a long history. Please check following article.

Response Times: The 3 Important Limits
by Jakob Nielsen on January 1, 1993

Summary: There are 3 main time limits (which are determined by human perceptual abilities) to keep in mind when optimizing web and application performance.

Excerpt from Chapter 5 in my book Usability Engineering, from 1993:

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

So you have to keep focus on response times during the testing process.
Labeling requests by response times is a fairly good solution for this purpose. In the following example I define intervals. You has to do this for all single request in your Thread Group. Exact numbers could be defined with help of previous measurement data or specification.

if (prev.getTime() > 170 && prev.getTime() < 340) {
    prev.setSampleLabel(prev.getSampleLabel() + " > 170")
} else if (prev.getTime() > 340 && prev.getTime() < 4000) {
    prev.setSampleLabel(prev.getSampleLabel() + " > 340")
} else if (prev.getTime() > 4000 && prev.getTime() < 8000) {
    prev.setSampleLabel(prev.getSampleLabel() + " > 4000")
} else if (prev.getTime() > 8000) {
    prev.setSampleLabel(prev.getSampleLabel() + " > 8000")
}

In this way each request will have more lines in the table of Aggregate Report, which will show how many requests are in the predefined time intervals. So you can create more precise reports and check criteria.