13 Ways to Optimize Gradle Build Performance

As I’ve mentioned in previous posts, build performance has a significant impact on team and organizational development productivity. Even small delays in builds that run multiple times a day can accumulate into substantial time losses over time. The same applies to CI/CD environments.

Therefore, I believe investing time at the team and organizational level to improve build speed is definitely worthwhile.

Before Starting Optimization…

Before applying changes, you can first use Build Scan to identify total build time and slow parts of the build.

For reference, starting from Gradle 4.3, you can run a Build Scan via the --scan command-line option.

$ gradle build --scan

For older Gradle versions, refer to the Build Scan Plugin User Manual.

After the build completes, Gradle provides a URL where you can find the Build Scan.

BUILD SUCCESSFUL in 2s
4 actionable tasks: 4 executed

Publishing build scan...
https://gradle.com/s/e6ircx2wjbf7e

If Build Scan isn’t to your liking, you can use the --profile command-line option to generate an HTML report in the build/reports/profile directory of the root project. Gradle calls this a Profile report.

However, sometimes builds are slow no matter how well you write your build scripts. This usually happens when a plugin or custom task has an inefficient internal implementation, or when system resources are insufficient. In such cases, you need to dig deeper using Gradle Profiler. It can uncover subtle performance issues that a standard Build Scan cannot detect. Note that Gradle Profiler can be used alongside professional profilers like JProfiler or YourKit. These tools drill down to the method level and show where CPU time is being consumed.

The reason I mentioned how to inspect builds before explaining how to optimize builds is that ultimately, we need to quantitatively verify how much improvement was achieved after applying optimizations.

The build optimization process should follow this sequence:

1. Inspect the build.
2. Apply changes.
3. Re-inspect the build.
4. If improved, keep it; if not, revert and try a different approach.

Now let’s dive into the 13 ways to optimize Gradle build performance.

1. Update Versions

Gradle

Each Gradle release includes performance improvements. Using an older version means missing out on these benefits. While maintaining compatibility for your project is important, Gradle maintains backward compatibility between minor versions, so the upgrade risk is low. Staying up to date also makes major version upgrades smoother.

Be cautious with major version changes, though!

You can update the Gradle version to a desired version (X.X) using the Gradle Wrapper.

./gradlew wrapper --gradle-version X.X

Java

Gradle runs on the JVM, and Java updates often improve performance. For the best Gradle performance, it’s recommended to use the latest Java version.

Make sure to check the Compatibility Matrix to ensure your Gradle and Java versions are compatible!

Plugins

Plugins play a critical role in build performance. Outdated plugins can slow down builds, and new versions often include optimizations. This is especially true for Android, Java, and Kotlin plugins.

For example, with the ktlint-gradle plugin, you can regularly monitor release notes and evaluate new versions from a performance perspective.

plugins {
    id("org.jlleitschuh.gradle.ktlint") version "<current_version>"
}

2. Enable Parallel Execution

Most projects consist of multiple subprojects, some of which are independent. However, by default, Gradle executes only one task at a time.

To execute tasks from different subprojects in parallel, use the --parallel flag.

gradle <task> --parallel

To make parallel execution the default, add the following to gradle.properties in your project root or Gradle home directory.

gradle.properties

org.gradle.parallel=true

Parallel builds can significantly improve build times, but the effectiveness depends on project structure and inter-subproject dependencies. If a single subproject dominates execution time or there are many dependencies between subprojects, the benefits of parallelization may be limited. However, most multi-project builds will see noticeable build time reductions.

Visualizing Parallelism with Build Scan

The Build Scan mentioned earlier provides a visual timeline of task execution in the Timeline tab, which helps identify bottlenecks in parallel execution.

By adjusting the build configuration to run these two slow tasks earlier and in parallel, the total build time is reduced from 8 seconds to 5 seconds.

3. Re-enable the Gradle Daemon

The Gradle Daemon significantly reduces build times through the following:

• Caching project information between builds
• Running in the background to avoid JVM startup delays
• Leveraging ongoing JVM runtime optimizations
• Watching the file system to determine what needs to be rebuilt

Gradle enables the Daemon by default, but some builds may override this setting. If the Daemon is disabled in your build, simply enabling it can yield significant performance gains.

To enable the Daemon for a build:

gradle <task> --daemon

For older Gradle versions, you can permanently enable it in gradle.properties.

org.gradle.daemon=true

On developer machines, enabling the Daemon improves performance. For CI machines, there are benefits for long-running agents, but not necessarily for short-lived environments. Since Gradle 3.0, the Daemon automatically shuts down in low-memory situations, so it’s safe to keep it enabled.

4. Enable Build Cache

Gradle Build Cache optimizes performance by storing the output of tasks for specific inputs. When a task is re-run with the same inputs, Gradle retrieves the cached output instead of re-executing the task.

Personally, every time I see this philosophy of applying deterministic and pure function concepts to the build system, I find it beautiful :)

By default, Gradle doesn’t use Build Cache. To enable it for a build:

gradle <task> --build-cache

To permanently enable it, add it to gradle.properties.

org.gradle.caching=true

Visualizing Build Cache with Build Scan

The Build Scan mentioned earlier helps analyze the build cache effectiveness through the Build Cache tab on the Performance page.

• Number of tasks that interacted with the cache
• Types of caches used
• Transfer and compression/decompression speeds of cache entries

For more detailed information about Build Cache, refer to the Build Cache documentation.

5. Enable Configuration Cache

Configuration Cache speeds up builds by caching the results of the configuration phase. It allows Gradle to skip this phase entirely when build configuration inputs haven’t changed.

There are some limitations, however:

• Not all core Gradle plugins and features are supported yet
• Builds and plugins may need adjustments to meet Configuration Cache requirements
• IDE imports and sync don’t use Configuration Cache

When Configuration Cache is enabled, Gradle behaves as follows:

• Executes all tasks in parallel, even within the same subproject
• Caches dependency resolution results to avoid redundant computation

Build configuration inputs include:

• Init scripts
• Settings scripts
• Build scripts
• System and Gradle properties used during configuration
• Environment variables used during configuration
• Configuration files accessed via value suppliers (providers)
• buildSrc inputs, including configuration files and source files

By default, Gradle doesn’t use configuration cache. To enable it for a build:

$ gradle <task> --configuration-cache

To permanently enable it, add the following to your gradle.properties file.

org.gradle.configuration-cache=true

For more detailed information, refer to the Configuration Cache documentation.

6. Enable Incremental Build for Custom Tasks

Incremental Build is a Gradle optimization that skips tasks that have already been run with the same inputs. If a task’s inputs and outputs haven’t changed since the last execution, Gradle skips it.

Most built-in Gradle tasks support incremental builds. To make custom tasks compatible, you need to specify their inputs and outputs.

tasks.register("processTemplatesAdHoc") {
    inputs.property("engine", TemplateEngineType.FREEMARKER)
    inputs.files(fileTree("src/templates"))
        .withPropertyName("sourceFiles")
        .withPathSensitivity(PathSensitivity.RELATIVE)
    inputs.property("templateData.name", "docs")
    inputs.property("templateData.variables", mapOf("year" to "2013"))
    outputs.dir(layout.buildDirectory.dir("genOutput2"))
        .withPropertyName("outputDir")

    doLast {
        // Template processing logic goes here
    }
}

The key here is the detailed settings like withPropertyName() and withPathSensitivity(). PathSensitivity.RELATIVE means only relative paths are considered, not absolute paths. This is important for cache reuse across different machines. For example, if developer Onseok works in /Users/onseok/project and developer Chulsoo works in /Users/chulsoo/project, the relative paths are identical!

Visualizing Incremental Builds with the Build Scan Timeline

The Build Scan’s Timeline view helps identify tasks that could benefit from incremental builds. It helps you understand why a task ran when Gradle was expected to skip it.

In the example above, one of the inputs – timestamp – had changed, so the task was not up-to-date and was re-executed.

A developer might think “I didn’t change any code, so why did it rebuild?” In reality, unexpected inputs like timestamp or the current time often change. Finding these is where Build Scan truly proves its value.

Finally, to optimize builds, it’s worth sorting tasks by execution time to identify the slowest tasks in your project.

The Pareto principle typically applies: about 20% of tasks account for 80% of the total build time. Optimizing just the few slowest tasks can yield significant overall performance improvements.

7. Create Builds for Specific Developer Workflows

The fastest task is one that doesn’t run. Simply skipping unnecessary tasks can significantly improve build performance. If your build includes multiple subprojects, you can define tasks that build each independently. This maximizes caching efficiency and prevents changes in one subproject from triggering unnecessary rebuilds in others. It also helps teams working on different subprojects avoid redundant builds.

For example, frontend developers don’t need to build the backend subproject, and documentation writers don’t need to build frontend or backend code.

In practice, this situation comes up very often. Especially in projects using microservice architectures or monorepos, a team only needs to build the part they’re working on, but time is wasted building everything.

Instead, you can maintain a single task graph for the entire project while creating developer-specific tasks. Each user group needs only a subset of tasks. Converting that subset into Gradle workflows that exclude unnecessary tasks is the approach.

Gradle provides several features for creating efficient workflows:

• Assigning tasks to appropriate groups
• Creating aggregate tasks: tasks that depend on other tasks but have no actions of their own (e.g., assemble)
• Using gradle.taskGraph.whenReady() to defer configuration and run validations only when needed

For example, in a Kotlin Multiplatform monorepo environment, this aggregate task pattern can be especially useful.

// Platform-specific aggregate tasks
tasks.register("buildAndroid") {
    dependsOn(
        ":shared:compileKotlinAndroid",
        ":androidApp:assembleDebug",
        ":feature:auth:compileDebugKotlinAndroid",
        ":feature:home:compileDebugKotlinAndroid"
    )
    group = "platform"
    description = "Build only Android-related modules"
}

tasks.register("buildIOS") {
    dependsOn(
        ":shared:compileKotlinIosX64",
        ":shared:compileKotlinIosArm64",
        ":iosApp:linkDebugFrameworkIosX64",
        ":feature:auth:compileKotlinIosX64",
        ":feature:home:compileKotlinIosX64"
    )
    group = "platform"
    description = "Build only iOS-related modules"
}

tasks.register("buildWeb") {
    dependsOn(
        ":shared:compileKotlinJs",
        ":webApp:browserDevelopmentWebpack",
        ":feature:auth:compileKotlinJs",
        ":feature:home:compileKotlinJs"
    )
    group = "platform"
    description = "Build only Web-related modules"
}

tasks.register("buildDesktop") {
    dependsOn(
        ":shared:compileKotlinJvm",
        ":desktopApp:jar",
        ":feature:auth:compileKotlinJvm",
        ":feature:home:compileKotlinJvm"
    )
    group = "platform"
    description = "Build only Desktop-related modules"
}

With this setup, an Android developer can run just ./gradlew buildAndroid to save iOS build time. This optimization is especially important for KMP projects, where per-platform compilation time can be substantial.

8. Increase Heap Size

By default, Gradle reserves 512MB of heap space for builds. This is sufficient for most projects.

However, very large builds may require more memory to store Gradle’s model and caches. If needed, you can increase the heap size in gradle.properties in your project root or Gradle home directory.

org.gradle.jvmargs=-Xmx2048M

For more information, refer to JVM Memory Configuration.

9. Optimize Configuration

Gradle builds go through three phases: initialization, configuration, and execution. The configuration phase runs regardless of which tasks are executed. Expensive operations in this phase can slow down even simple commands like gradle help or gradle tasks.

You can also enable configuration cache to minimize the impact of a slow configuration phase. However, even with caching, the configuration phase runs occasionally, so optimization is still important.

Many developers think “configuration cache handles it, so I don’t need to worry about the configuration phase.” But cache invalidation happens more often than you’d expect – a simple gradle.properties change, checking out a new branch, or modifying an environment variable can all invalidate the cache.

Avoid Expensive or Blocking Work

Time-consuming operations should be avoided during the configuration phase. Sometimes, however, they creep in unexpectedly. Encrypting data or calling remote services in build scripts is an obvious problem, but such logic is often hidden inside plugins or custom task classes. Expensive work in a plugin’s apply() method or a task’s constructor should be avoided.

class ExpensivePlugin implements Plugin<Project> {
    @Override
    void apply(Project project) {
        // Bad: expensive network call at configuration time
        def response = new URL("https://example.com/dependencies.json").text
        def dependencies = new groovy.json.JsonSlurper().parseText(response)

        dependencies.each { dep ->
            project.dependencies.add("implementation", dep)
        }
    }
}

Instead, do this:

class OptimizedPlugin implements Plugin<Project> {
    @Override
    void apply(Project project) {
        project.tasks.register("fetchDependencies") {
            doLast {
                // Good: only runs when the task is executed
                def response = new URL("https://example.com/dependencies.json").text
                def dependencies = new groovy.json.JsonSlurper().parseText(response)

                dependencies.each { dep ->
                    project.dependencies.add("implementation", dep)
                }
            }
        }
    }
}

This kind of mistake is really common. Especially when fetching configuration from an external API or reading and processing files in the plugin apply phase… I once made the mistake of putting Git info retrieval logic for version generation in the configuration phase, which slowed down even the gradle tasks command.

Apply Plugins Only Where Needed

Each applied plugin or script adds to configuration time, and some plugins have a bigger impact than others. Rather than avoiding plugins entirely, ensure they’re applied only where needed. For example, using allprojects {} or subprojects {} can apply plugins to all subprojects, even though not all may need them.

In the example below, the root build script applies script-a.gradle to three subprojects.

subprojects {
    apply from: "$rootDir/script-a.gradle"  // Applied unnecessarily to all subprojects
}

This script takes 1 second per subproject, creating a total 3-second configuration delay.

To optimize:

• If only one subproject needs the script, removing it from the others saves 2 seconds of configuration delay.

project(":subproject1") {
    apply from: "$rootDir/script-a.gradle"  // Applied only where needed
}

project(":subproject2") {
    apply from: "$rootDir/script-a.gradle"
}

• If multiple subprojects use the script but not all of them, refactor it into a custom plugin inside buildSrc and apply it only to relevant subprojects. This reduces configuration time and avoids code duplication.

plugins {
    id 'com.example.my-custom-plugin' apply false  // Declare plugin without global application
}

project(":subproject1") {
    apply plugin: 'com.example.my-custom-plugin'  // Apply only where needed
}

project(":subproject2") {
    apply plugin: 'com.example.my-custom-plugin'
}

The key here is apply false. It means declaring the plugin without immediately applying it. Then each subproject can selectively apply it only when needed. This pattern is commonly used in Android projects because not all modules require the Android framework.

Statically Compile Tasks and Plugins

Many Gradle plugins and tasks are written in Groovy for its concise syntax, functional API, and powerful extension features. However, Groovy’s dynamic resolution makes method calls slower than Java or Kotlin. For Groovy classes that don’t need dynamic features, adding the @CompileStatic annotation enables static Groovy compilation and reduces this overhead. For methods that need dynamic behavior, use @CompileDynamic on those specific methods. Alternatively, consider writing plugins and tasks in Java or Kotlin, which are statically compiled by default.

Gradle’s Groovy DSL relies on Groovy’s dynamic features. To use static compilation in plugins, you’ll need to adopt a more Java-like syntax.

The following example defines a task that copies files without dynamic features.

// src/main/groovy/MyPlugin.groovy
project.tasks.register('copyFiles', Copy) { Task t ->
    t.into(project.layout.buildDirectory.dir('output'))
    t.from(project.configurations.getByName('compile'))
}

This example uses register() and getByName(), available on all Gradle domain object containers including tasks, configurations, dependencies, and extensions. Some containers, like TaskContainer, also have specialized methods like create that accept a task type.

Static compilation improves IDE support through:

• Faster detection of unrecognized types, properties, and methods
• More reliable auto-completion for method names

10. Optimize Dependency Resolution

Dependency resolution simplifies integrating third-party libraries into your project. Gradle connects to remote servers to discover and download dependencies. You can minimize these remote calls by optimizing how dependencies are referenced.

Avoid Unnecessary and Unused Dependencies

Managing third-party libraries and their transitive dependencies adds significant maintenance and build time costs. Unused dependencies often remain after refactoring.

If you’re only using a small part of a library, consider:

• Implementing the needed functionality yourself
• If the library is open source, copying the necessary code (with proper attribution)

This is especially important for Android projects where APK size must also be considered.

Optimize Repository Order

Gradle searches repositories in the order they’re declared. To speed up resolution, list the repository hosting most of your dependencies first to reduce unnecessary network requests.

repositories {
    mavenCentral()  // Declared first, but most dependencies are on JitPack
    maven { url "https://jitpack.io" }
}

This kind of mistake is really common in practice. I once had our internal Nexus repository declared last in a company project, which meant every dependency was first looked up on Maven Central, leading to long resolution times.

Minimize the Number of Repositories

You can also limit the number of essential repositories to a minimum. If you use custom repositories, create a virtual repository that aggregates multiple repositories and add only that one to the build.

repositories {
    maven { url "https://repo.mycompany.com/virtual-repo" } // Use aggregated repository
}

Minimize Dynamic and Snapshot Versions

Dynamic ("2.+") versions and snapshot ("-SNAPSHOT") versions cause Gradle to check remote repositories frequently. By default, Gradle caches dynamic versions for 24 hours, but this can be configured using the cacheDynamicVersionsFor and cacheChangingModulesFor properties.

configurations.all {
    resolutionStrategy {
        cacheDynamicVersionsFor 4, 'hours'
        cacheChangingModulesFor 10, 'minutes'
    }
}

Lowering these values in build files or init scripts makes Gradle query repositories more frequently. Unless you need the absolute latest release of dependencies with every build, consider removing custom values for these settings.

Finding Dynamic and Changing Versions with Build Scan

You can use Build Scan to find dynamic dependencies. Where possible, I recommend replacing dynamic versions with fixed versions like “1.2” or “3.0.3.GA” for better caching.

Dynamic versions are convenient during development but make reproducible builds difficult. In CI/CD especially, you might encounter situations like “the build worked yesterday but not today.”

Avoid Dependency Resolution During Configuration

Dependency resolution is an I/O-intensive process. While Gradle caches results, triggering resolution during the configuration phase adds unnecessary overhead to every build.

For example, this code forces dependency resolution during configuration, slowing every build.

task copyFiles {
    // Bad: this line is in the task configuration block (outside doFirst/doLast),
    // so dependency resolution happens during the configuration phase on every build.
    configurations.compileClasspath.files.each { println it }
    doLast {
        configurations.compileClasspath.files.each { println it } // This is fine: runs only during execution
    }
}

Switch to Declarative Syntax

Evaluating configuration files during the configuration phase causes Gradle to resolve dependencies too early, increasing build time. Generally, tasks should resolve dependencies only when needed during execution. Consider a debugging scenario where you want to print all files of a configuration. A common mistake is printing directly in the build script.

tasks.register<Copy>("copyFiles") {
    println(">> Compilation deps: ${configurations.compileClasspath.get().files.map { it.name }}")
    into(layout.buildDirectory.dir("output"))
    from(configurations.compileClasspath)
}

The files property triggers immediate dependency resolution even if copyFiles never runs. Since the configuration phase executes on every build, this slows down every build. Using doFirst() defers dependency resolution until the task actually executes, preventing unnecessary work during the configuration phase.

tasks.register<Copy>("copyFiles") {
    into(layout.buildDirectory.dir("output"))
    // Store the configuration in a variable since referencing the project in a task action is not compatible with configuration cache.
    val compileClasspath: FileCollection = configurations.compileClasspath.get()
    from(compileClasspath)
    doFirst {
        println(">> Compilation deps: ${compileClasspath.files.map { it.name }}")
    }
}

Gradle Copy task’s from() method references the dependency configuration rather than resolved files, so it doesn’t trigger immediate dependency resolution. This ensures dependencies are only resolved when the Copy task executes.

You might think “I just added one line for debugging,” but that one line can slow every build by a few seconds.

Visualizing Dependency Resolution with Build Scan

The Dependency resolution tab on the Performance page of Build Scan shows dependency resolution times during both the configuration and execution phases.

Build Scan provides another means of identifying this problem. A build should spend 0 seconds resolving dependencies during project configuration. This example shows that the build resolves dependencies too early in the lifecycle. This can also be found in the Settings and suggestions tab on the Performance page, which shows dependencies resolved during the configuration phase.

Remove or Improve Custom Dependency Resolution Logic

Gradle allows users to model dependency resolution in flexible ways. Simple customizations like forcing specific versions or substituting dependencies have minimal impact on resolution time. However, complex custom logic such as manually downloading and parsing POM files can significantly slow down dependency resolution. Use Build Scan or Profile Report to verify that custom dependency resolution logic isn’t causing performance issues. Such logic may be in your build scripts or part of a third-party plugin.

Below is an example where a custom dependency version is forced, but expensive logic is also applied, slowing resolution.

configurations.all {
    resolutionStrategy.eachDependency { details ->
        if (details.requested.group == "com.example" && details.requested.name == "library") {
            def versionInfo = new URL("https://example.com/version-check").text  // Remote call during resolution
            details.useVersion(versionInfo.trim())  // Dynamically set version based on HTTP response
        }
    }
}

Instead of dynamically fetching dependency versions, define them in a version catalog.

dependencies {
    implementation "com.example:library:${versions.libraryVersion}"
}

At first you might think “it’s convenient to automatically fetch the latest version,” but making HTTP calls with every build means build times can fluctuate depending on network conditions.

Remove Slow or Unexpected Dependency Downloads

Slow dependency downloads can significantly impact build performance. Common causes include:

• Slow internet connection
• Overloaded or distant repository servers
• Unexpected downloads due to dynamic versions (2.+) or snapshot versions (-SNAPSHOT)

The Performance tab of Build Scan has a Network Activity section showing total time spent on dependency downloads, download transfer rates, and dependencies sorted by download time.

This lets you review unexpectedly downloaded dependencies. For example, dynamic versions (1.+) can trigger frequent remote lookups.

To eliminate unnecessary downloads, consider using a closer or faster repository (a geographically closer mirror or internal repository proxy if Maven Central downloads are slow), and switch from dynamic to fixed versions as shown below.

dependencies {
    implementation "com.example:library:1.+" // Bad
    implementation "com.example:library:1.2.3" // Good
}

11. Optimize Java Projects

The following sections apply to projects using the java plugin or other JVM languages.

Optimize Test Execution

Tests often account for a significant portion of build time. This includes both unit tests and integration tests, with integration tests typically taking longer to run.

Build Scan can help identify the slowest tests and prioritize performance improvements accordingly.

The image above shows Build Scan’s interactive test report sorted by test duration.

As with the Pareto principle example mentioned earlier, finding and focusing on the slowest tests in Build Scan is expected to yield significant results.

Gradle provides several strategies to speed up test execution:

• A. Run tests in parallel
• B. Fork tests into multiple processes
• C. Disable test reports when not needed

Let’s look at each option in detail.

A. Run Tests in Parallel

Gradle can run multiple test classes or methods in parallel. To enable parallel execution, set the maxParallelForks property on the Test task. A good default is the number of available CPU cores or slightly fewer.

tasks.withType<Test>().configureEach {
    maxParallelForks = (Runtime.getRuntime().availableProcessors() / 2).coerceAtLeast(1)
}

Parallel test execution assumes tests are isolated. Shared resources like file systems, databases, and external services should be avoided. Tests that share state or resources can fail intermittently due to race conditions or resource conflicts.

Tests that pass locally but fail intermittently when run in parallel on CI are extremely common. Tests that create temporary files or use fixed ports are particularly problematic.

B. Fork Tests into Multiple Processes

By default, Gradle runs all tests in a single forked JVM process. This is efficient for small test suites, but large or memory-intensive test suites can suffer from long execution times and GC pauses.

The forkEvery setting reduces memory pressure and isolates problematic tests by forking a new JVM after a specified number of tests.

tasks.withType<Test>().configureEach {
    forkEvery = 100
}

Forking JVMs is an expensive operation. Setting forkEvery too low can increase test time due to excessive process startup overhead.

This setting requires a delicate balance. Setting it too high can lead to memory leaks or state pollution, while setting it too low slows things down due to JVM startup costs. It needs to be tuned for your project’s scale and test characteristics.

C. Disable Test Reports

By default, Gradle generates HTML and JUnit XML test reports even if you never look at them. Report generation adds overhead, especially for large test suites.

You can completely disable report generation in the following cases:

• When you only need to know whether tests passed
• When using Build Scan, which provides richer test insights

To disable reports, set reports.html.required and reports.junitXml.required to false.

tasks.withType<Test>().configureEach {
    reports.html.required = false
    reports.junitXml.required = false
}

Conditionally Enable Reports

If you occasionally need reports without modifying the build file, you can make report generation conditional based on a project property.

This example disables reports unless the createReports property is present.

tasks.withType<Test>().configureEach {
    if (!project.hasProperty("createReports")) {
        reports.html.required = false
        reports.junitXml.required = false
    }
}

To generate reports, pass the property via the command line.

$ gradle <task> -PcreateReports

Or define the property in a gradle.properties file in the project root or Gradle User Home.

createReports=true

Especially in CI, reports are often needed, but they’re unnecessary during local development. This conditional setup – turning off report generation by default and enabling it only when needed for fast feedback – can be extremely useful.

Compiler Optimization

The Java compiler is fast, but in large projects with hundreds or thousands of classes, compilation time can still be significant.

Gradle provides several ways to optimize Java compilation:

• A. Run the compiler in a separate process
• B. Use implementation visibility for internal dependencies

A. Run the Compiler in a Separate Process

By default, Gradle runs compilation in the same process as the build logic. You can offload Java compilation to a separate process using the fork option.

<task>.options.isFork = true

To apply this to all JavaCompile tasks, use configureEach.

tasks.withType<JavaCompile>().configureEach {
    options.isFork = true
}

Gradle reuses the forked process throughout the build, so startup costs are low. Running compilation in its own JVM helps reduce garbage collection in the main Gradle process, which can speed up the rest of the build. This is especially true when combined with parallel execution. Forked compilation has little effect on small builds but can be very helpful when a single task compiles more than a thousand source files.

This optimization is especially powerful for large projects. When GC occurs frequently in the main Gradle process, the entire build can feel like it’s stalling. Separating the compiler provides much more stable performance.

B. Use implementation for Internal Dependencies

Since Gradle 3.4, you can use api for dependencies that should be exposed to downstream projects and implementation for internal dependencies. This distinction reduces unnecessary recompilation in large multi-project builds.

When an implementation dependency changes, Gradle doesn’t recompile downstream consumers. It only recompiles when an api dependency changes. This helps reduce cascading recompilation.

dependencies {
   api(project("my-utils"))
   implementation("com.google.guava:guava:21.0")
}

Switching internal-only dependencies to implementation is one of the most impactful changes you can make to improve build performance in large modular codebases.

This is absolutely critical! Many developers don’t understand the difference between api and implementation and use api indiscriminately. Getting this one thing right alone can dramatically reduce build times. In particular, it prevents the entire project from being recompiled when a common utility module is modified.

12. Optimize Android Projects

All performance strategies described in this guide apply to Android builds as well, since Android projects use Gradle internally.

However, unlike standard Java projects, Android has additional complexity. Resource processing (images, layouts, strings, etc.) significantly impacts compilation time, and build variants like debug/release can multiply build times.

For Android-specific tips, I recommend checking the Android team’s official resources:

• Optimize your build performance (Android Developer Guide)
• Optimizing Gradle Builds for Android (Google I/O 2017 Talk)

13. Performance Improvements for Older Gradle Releases

I recommend using the latest Gradle version to benefit from the latest performance improvements, bug fixes, and features. However, some projects – particularly long-lived or legacy codebases – may not be able to upgrade easily.

If you’re using an older Gradle version, consider the following optimizations to improve build performance.

Enable the Daemon

The Gradle Daemon significantly improves build performance by avoiding JVM startup costs between builds. The Daemon has been enabled by default since Gradle 3.0. If you’re using an older version, consider upgrading Gradle. If upgrading isn’t an option, you can manually enable the Daemon.

# gradle.properties
org.gradle.daemon=true

If you’re still using a Gradle version prior to 3.0, you should seriously consider upgrading. A version that old may have security and compatibility issues as well… But if upgrading isn’t possible, at least enabling the Daemon is essential.

Enable Incremental Compilation

Gradle can analyze class dependencies to recompile only the parts of code affected by changes. Incremental compilation is enabled by default since Gradle 4.10. To manually enable it on earlier versions, add the following configuration to your build.gradle file.

tasks.withType<JavaCompile>().configureEach {
    options.isIncremental = true
}

Closing Thoughts

I decided to study and document Gradle build optimization because I wanted to solve the frustration of long build times during development. I’ve actually had the experience of applying these optimization methods one by one and noticeably reducing build times. There’s also the satisfaction of colleagues saying “the builds are faster now!”

The most important thing is not to blindly apply every optimization, but to measure precisely using Build Scan or Profile Report and improve accordingly. Some optimizations have a big impact on your project, while others may make almost no difference. Features like Configuration Cache and Build Cache have a slight learning curve when first set up, but once properly configured, the results can be truly dramatic.

Personally, I experienced significant improvements just from properly distinguishing between api and implementation, enabling parallel builds, and removing unnecessary tasks. In multi-module projects especially, these small optimizations compound to make a truly significant difference.

Improving build performance goes beyond just saving time – it transforms the development experience itself. A fast feedback loop has a positive impact on both developer focus and productivity. I hope this article helps improve the development environment for anyone who happens to read it.