Introduction

Improving Spring Boot response time is rarely about one magic property or one annotation. Most slow endpoints are slow because of a chain of small costs: database queries, serialization, thread contention, remote calls, and unnecessary object work. The fastest way to improve response time is to measure the path first, then remove the bottleneck that actually dominates the request.

Start by Measuring the Slow Path

Before optimizing, make the slow endpoint visible. A controller that "feels slow" might actually be:

• waiting on the database
• blocked on another HTTP service
• doing too much JSON serialization
• stuck in thread-pool contention

A simple timing example inside a service:

1import org.slf4j.Logger;
2import org.slf4j.LoggerFactory;
3import org.springframework.stereotype.Service;
4
5@Service
6public class UserService {
7    private static final Logger log = LoggerFactory.getLogger(UserService.class);
8
9    public String loadUser() {
10        long start = System.nanoTime();
11        try {
12            // real work here
13            return "ok";
14        } finally {
15            long elapsedMs = (System.nanoTime() - start) / 1_000_000;
16            log.info("loadUser took {} ms", elapsedMs);
17        }
18    }
19}

For real applications, use structured metrics and tracing rather than ad hoc logs everywhere, but the principle is the same: do not optimize blind.

Database Time Is Often the Main Problem

Many Spring Boot performance complaints are actually database complaints.

Common causes:

• N+1 query patterns
• missing indexes
• fetching too many columns
• loading large object graphs unnecessarily

A repository call can look simple and still be expensive once ORM behavior expands it.

For example, returning entities directly from a controller often pulls in more data than needed. A DTO-focused query is frequently faster:

public record UserSummary(Long id, String name) {}

@Query("select new com.example.UserSummary(u.id, u.name) from User u")
List<UserSummary> findUserSummaries();

This reduces mapping cost and avoids serializing fields the client never asked for.

Watch for Blocking Remote Calls

An endpoint can also be slow because it waits on another service. If a request path calls:

• a payment API
• a search service
• a profile service

then your response time includes all of those network delays.

In such cases, the fix may be:

• caching
• reducing the number of downstream calls
• parallelizing independent calls
• using async workflows when the client does not need immediate completion

But do not add @Async just to look fast. If the client must wait for the result, you have only moved the blocking point around unless the design truly changed.

Caching Helps Only for Repeatable Data

Spring caching is useful when the data is read often and changes infrequently.

Example:

1import org.springframework.cache.annotation.Cacheable;
2import org.springframework.stereotype.Service;
3
4@Service
5public class CountryService {
6
7    @Cacheable("countries")
8    public String getCountryCode(String countryName) {
9        // simulate expensive call
10        return countryName.substring(0, 2).toUpperCase();
11    }
12}

Caching can dramatically reduce response time, but only when the cached value is worth reusing. Caching volatile or user-specific data carelessly can create correctness bugs faster than performance wins.

Tune the Connection Pool and Threading Carefully

Spring Boot commonly uses HikariCP by default for database connections. If the pool is too small, requests wait. If the pool is too large, the database may become the bottleneck instead.

Similarly, Tomcat or Undertow thread counts affect throughput under load, but increasing them blindly is not a guaranteed improvement. More threads can mean more context switching and more pressure on downstream services.

A useful rule is:

• tune pool and thread sizes only after measurement
• match them to actual database and CPU capacity

Configuration is important, but it is not a replacement for profiling.

Serialization and Payload Size Matter

If an endpoint returns a large response, response time may be dominated by:

• entity-to-JSON conversion
• large nested objects
• network transfer

A smaller payload often beats a cleverer controller.

This is why pagination, projection, and field selection matter even in fast JVM code. Returning less data is one of the simplest real optimizations available.

A Practical Optimization Example

Bad pattern:

1@GetMapping("/users")
2public List<User> users() {
3    return userRepository.findAll();
4}

Better pattern:

1@GetMapping("/users")
2public List<UserSummary> users() {
3    return userRepository.findUserSummaries();
4}

This often improves:

• query size
• ORM work
• serialization cost
• network transfer

One change can shorten the whole request path.

Common Pitfalls

The biggest mistake is tuning Spring Boot properties before measuring where the request actually spends time. Slow responses are often caused by the database or a downstream service, not by Spring Boot itself.

Another issue is trying to "fix" latency with asynchronous code even when the caller still needs the result synchronously. That changes complexity more than it changes response time.

Developers also often return full entities directly from controllers, which can trigger excessive loading and heavy serialization.

Finally, do not ignore the query layer. N+1 behavior, bad indexes, and oversized result sets are among the most common reasons a Spring Boot endpoint feels slow.

Summary

• Measure the slow path first instead of optimizing by guesswork.
• Database access is one of the most common real causes of slow Spring Boot responses.
• Reduce unnecessary data fetching and serialization by using DTOs and targeted queries.
• Use caching only when the data is stable enough to benefit from reuse.
• Tune thread pools and connection pools only after profiling the real bottleneck.