# build times The duration required for a software build to complete, used to measure and optimize build performance. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Linux 7.4 Could End Up Seeing Kernel Builds ~36% Faster, Incremental Builds ~70% Faster DevFeed: [Linux 7.4 Could End Up Seeing Kernel Builds ~36% Faster, Incremental Builds ~70% Faster]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-14T10:31:16Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux](), [build performance](), [build times](), [Arm](), [Compiler](), [Git](), [Artificial Intelligence]() Tags: [ai](), [arm](), [build-times](), [compiler](), [desktop-linux](), [git](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview A second revision of Linux kernel patches could make full allmodconfig builds about 36% faster and incremental builds about 70% faster. The work, led by Lorenzo Stoakes of Arm, addresses single-threaded bottlenecks and includes fixes, an upstream rebase, and an optional parallel Rust compiler front end. The patches are being considered for inclusion in Linux 7.4. ### Source excerpt Earlier this month I wrote about a patch series posted to the Linux kernel mailing list that addressed a lot of "hideous code" to make Linux kernel builds faster. A number of single-threaded bottlenecks were tracked down and fixed within the Linux kernel thanks to the assistance of AI. A second revision of those patches hit the mailing list this morning and there is hope they could be upstreamed for Linux 7.4... ## Starlight 0.42 DevFeed: [Starlight 0.42]() Original publisher: [Read original article]() Author: Chris Swithinbank Published: 2026-09-02T00:00:00Z Content type: release Language: en Sources: [The Astro Blog]() Topics: [releases](), [Accessibility](), [build times](), [Command-line interface](), [changelog]() Tags: [accessibility](), [astro](), [build-times](), [changelog](), [cli](), [javascript](), [release](), [typescript]() ### AI overview Starlight 0.42 reduces client-side JavaScript through the Popover API, compiles its published source to JavaScript with type definitions, and includes build-time and accessibility improvements. ### Source excerpt Less JavaScript, and more JavaScript, all in one release. ## Clearer Build Optimization Results with GitHub Copilot DevFeed: [Clearer Build Optimization Results with GitHub Copilot]() Original publisher: [Read original article]() Author: David Li Published: 2026-08-13T18:18:50Z Content type: article Language: en Sources: [C++ Team Blog]() Topics: [GitHub Copilot](), [Optimization](), [build performance](), [build times](), [C++](), [Windows](), [Visual Studio 2026]() Tags: [build-insights](), [build-optimization](), [build-performance](), [build-times](), [c-plus-plus](), [github-copilot](), [optimization](), [performance](), [visual-studio](), [visual-studio-2026](), [windows](), [workflow]() ### AI overview GitHub Copilot build performance for Windows now provides deterministic messages for optimization outcomes, including successful improvements, changes below the success threshold, unsuccessful changes, and builds that were too short to analyze. Successful results include baseline and final build times, measured improvement, and effects on iterative builds when applicable. ### Source excerpt We know that slow builds are a consistent theme in feedback from C++ developers. Your feedback helped us to shape GitHub Copilot build performance for Windows, an agent that can trace your build, find bottlenecks, apply optimizations, and measure the result. When using the agent, the clearest outcome is a straightforward win. The agent changes [...] The post Clearer Build Optimization Results with GitHub Copilot appeared first on C++ Team Blog. ## Dynamic Derivations + Dynamic build graphs: next steps DevFeed: [Dynamic Derivations + Dynamic build graphs: next steps]() Original publisher: [Read original article]() Author: tomberek Published: 2026-08-07T18:58:35Z Content type: opinion Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [build performance](), [systems](), [build times](), [bazel]() Tags: [announcements](), [bazel](), [build](), [ci](), [incremental](), [performant](), [ux]() ### AI overview A proposal for a Dynamic Derivations working group in the Nix ecosystem outlines collaboration goals, user-experience refinement, infrastructure needs, and adoption efforts. The post also summarizes the feature's development history and discusses potential benefits such as faster rebuilds and fine-grained incremental builds. ### Source excerpt After the long-history (see below) of Dynamic Derivations we are at a point where there are many groups exploring the feature and I am proposing a working group to: share the experiences of the implementors refine the user experience based on usage of the various PoCs determine infrastructure needs deduplicate work raise awareness build momentum for adoption ... anything else relevant I believe this feature has the potential to be a game-changer. Faster rebuilds, easier development, reduced pressure on CI systems, cacheable and alternative forms of instantiation, less need for "lang2nix", close the gap with Bazel, and fine-grained incremental builds. Along with the existing work on better schedulers, RBE-style remote builders, bytecode evaluation, parallel eval, memory optimizations (thanks @xokdvium !), and so much more - this is an exciting time for Nix and I can see DynDrvs as a way to fix some of the outstanding UX issues Nix has in day-to-day usage. There is even work to make IFD more performant, there is lots of design space to explore here. This should be a part of what Nix has to offer the world. @Ericson2314 has devoted years to this, and it deserves the payoff of becoming a mature feature. This is a call to action. Let's consider collaboration and a semimonthly meeting to at least say hello + consider next steps: Dynamic Derivations Working Group - Crab Fit History Dynamic Derivations have been in-progress for a long time. This has much of the history that I can put together. Let me know if this can be more complete. (and if anyone can help move/migrate into the wiki?) Build Systems à la Carte : 2018 RFC started Apr 2021 by @Ericson2314 and @L-as with [RFC 0092] Computed derivations by Ericson2314 - Pull Request #92 - NixOS/rfcs - GitHub (after reworking RFC 0040). Based on Initial example PoC by @L-as GitHub - L-as/nix-build.nix: nix-build.nix with RFC 92 - GitHub Content-addressed Nix Dec 2021: Implementing a content-addressed Nix by @thufschmitt. RFC Shep ## Pure Virtual C++ 2026 Is a Wrap DevFeed: [Pure Virtual C++ 2026 Is a Wrap]() Original publisher: [Read original article]() Author: Marian Luparu Published: 2026-07-22T16:00:35Z Content type: news Language: en Sources: [C++ Team Blog]() Topics: [C++](), [Visual Studio 2026](), [build times]() Tags: [ai](), [announcement](), [build-performance](), [c-plus-plus](), [conference](), [interop](), [pure-virtual-c-plus-plus]() ### AI overview Pure Virtual C++ 2026 has concluded, and recordings of its featured and on-demand C++ conference sessions are available. Topics include C++/Rust interoperability, AI-assisted tooling, build times, C++20 modules, packages, MSVC, and profile-guided optimization. ### Source excerpt Pure Virtual C++ 2026 is a wrap. Every featured and on-demand session is now available on YouTube -- catch up on C++/Rust interop, AI-driven tooling, build performance, and more. The post Pure Virtual C++ 2026 Is a Wrap appeared first on C++ Team Blog. ## Faster C++ iterative builds with GitHub Copilot DevFeed: [Faster C++ iterative builds with GitHub Copilot]() Original publisher: [Read original article]() Author: David Li Published: 2026-07-17T14:22:57Z Content type: article Language: en Sources: [C++ Team Blog]() Topics: [build times](), [C++](), [AI Bots]() Tags: [agent](), [build-insights](), [build-optimization](), [build-performance](), [build-times](), [c-plus-plus](), [copilot](), [diagnostics](), [game-development](), [github](), [github-copilot](), [optimization](), [performance](), [tool](), [visual-studio](), [visual-studio-2026](), [windows](), [workflow]() ### AI overview GitHub Copilot build performance for Windows adds an iterative build tool that evaluates optimization changes against incremental builds as well as clean builds. ### Source excerpt Slow builds are a consistent theme of feedback from C++ developers. We built GitHub Copilot build performance for Windows so you can leverage Copilot to optimize your project's build times. This workflow will find optimizations that bring your build times down. At first, we only measured the impact of build optimizations on full clean builds. [...] The post Faster C++ iterative builds with GitHub Copilot appeared first on C++ Team Blog. ## A Gradle Module Structure for Clear Boundaries, Faster Builds, and Test Coverage DevFeed: [A Gradle Module Structure for Clear Boundaries, Faster Builds, and Test Coverage]() Original publisher: [Read original article]() Author: Jesse Wilson Published: 2026-07-15T13:38:11Z Content type: article Language: en Sources: [Blogs on Ryan Harter]() Topics: [Gradle](), [build times](), [modules](), [test-coverage](), [Android Gradle Plugin](), [Kotlin]() Tags: [android-gradle-plugin](), [build](), [build-times](), [gradle](), [kotlin](), [modules](), [test-coverage]() ### AI overview The article describes a Gradle module convention that separates each feature's public API from its implementation. The author says this structure reduced build times and coupling between features while helping enforce test coverage, with Android Gradle Plugin support making a separate test-fixtures module unnecessary. ### Source excerpt Flattening my Dependency Graph Jesse Wilson Jesse explores a Gradle module structure that he likes. Read now ➡ I liked this not-so-recent post from Jesse Wilson, which outlines a Gradle module convention that prioritizes clear public/private boundaries to support encapsulation and build speed. The approach, adapted from one presented by Ralf Wondratschek, also happens to closely resemble one that I helped institute at Dropbox shortly after I joined four and a half years ago. ## Turbopack: What's New in Next.js 16.3 DevFeed: [Turbopack: What's New in Next.js 16.3]() Original publisher: [Read original article]() Author: Andrew Imm Published: 2026-06-29T20:00:00Z Content type: article Language: en Sources: [Next.js Blog]() Topics: [Next.js](), [Cache](), [Caching](), [build times](), [Compiler](), [Persistence](), [Rust](), [cpu]() Tags: [build-times](), [cache](), [caching](), [cpu](), [development](), [memory](), [next-js](), [performance](), [persistence](), [rust]() ### AI overview Next.js 16.3 improves the Turbopack bundler with lower development memory usage, persistent filesystem caching for faster builds, experimental Rust React Compiler support, API support, and faster hot module replacement and development startup. Memory-cache eviction, enabled by default with the development filesystem cache, helps prevent unbounded memory growth during long development sessions. ### Source excerpt Turbopack in Next.js 16.3 adds development memory eviction, persistent file cache for builds, experimental Rust React Compiler, and `import.meta.glob` support. ## Announcing TypeScript 7.0 RC DevFeed: [Announcing TypeScript 7.0 RC]() Original publisher: [Read original article]() Author: Daniel Rosenwasser Published: 2026-06-18T14:31:17Z Content type: release Language: en Sources: [TypeScript]() Topics: [TypeScript](), [Go Language](), [Compiler](), [build times](), [npm](), [vs-code](), [Extension](), [ci]() Tags: [build-times](), [ci](), [development](), [extension](), [go](), [performance](), [post](), [release](), [speed](), [typescript](), [vs-code]() ### AI overview TypeScript 7.0 RC introduces a Go-based compiler foundation with shared-memory parallelism, reporting substantial speed improvements while preserving TypeScript 6.0's type-checking semantics. The release candidate is available through npm, with an optional VS Code preview extension for faster editing. ### Source excerpt Today we are excited to announce the Release Candidate of TypeScript 7.0! If you haven't been following TypeScript 7.0's development, this release is significant in that it is built on a completely new foundation. Over the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles to [...] The post Announcing TypeScript 7.0 RC appeared first on TypeScript. ## Achieving Fast Inner Dev Loops with Gradle: Configuration Cache and Beyond DevFeed: [Achieving Fast Inner Dev Loops with Gradle: Configuration Cache and Beyond]() Original publisher: [Read original article]() Author: Alex Semin Published: 2026-05-20T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [code productivity](), [build performance](), [build times](), [Development]() Tags: [build](), [build-tool](), [compilation](), [context](), [developer-productivity](), [flow](), [gradle](), [incremental](), [kotlinconf](), [parallelism](), [productivity]() ### AI overview This article explains how Gradle is working to accelerate inner developer loops. It describes the shift from execution time to configuration time as the main build bottleneck in large codebases, while highlighting configuration cache, incremental builds, build cache, and parallelism as approaches to reduce waiting and preserve developer flow. ### Source excerpt How many engineers in your organization have to sit idle for 10 or more minutes just to rebuild the app locally after a small change? If you're an engineering leader, build engineer, or part of a developer productivity team, you're not alone in facing this challenge. Building complex software is inherently demanding, but the time your developers spend waiting has a profound impact beyond just the literal minutes lost. It fundamentally disrupts their psychological flow. "There are like these time scales of psychological flow, right? So if something takes longer than a minute, you already start planning for it... you suffer from context switch as well. If it's 1 second, that's where we want to be right in that seamless state of flow. And if it's less than one second, then you feel it's like magic... productive developers are happy developers." -- Rodrigo Oliveira When developers have to wait, their attention drifts, and the cost of context switching destroys their momentum. Our goal as enablers of developer productivity should be to eliminate this friction, bringing that feedback loop as close as possible to the "magical one second". In a recent presentation at KotlinConf 2025, Gradle engineers Rodrigo Oliveira and Alex Semin detailed how Gradle Build Tool is evolving to keep developers in that productive, happy "flow state". By tackling the most significant bottlenecks in modern software builds, Gradle is paving the way for incredibly fast inner developer loops. If you prefer to watch the presentation recording, you can find it here. The shifting bottleneck: From execution to configuration On every invocation, Gradle goes through three distinct phases: initialization, configuration, and execution. Historically, when we optimized Gradle builds, we focused almost exclusively on the execution phase. This is when the majority of work expected by a developer happens: production sources compilation, test execution, etc. For years, execution was the longest phase. We tackled thi ## Optimizing Our Build Times by Migrating from Webpack to Rspack DevFeed: [Optimizing Our Build Times by Migrating from Webpack to Rspack]() Original publisher: [Read original article]() Author: Benson Pan, Software Engineer Published: 2026-05-20T00:00:00Z Content type: tutorial Language: en Sources: [Yelp]() Topics: [Webpack](), [build times](), [monorepo](), [build performance](), [Developer experience]() Tags: [build](), [build-times](), [build-tools](), [developer-experience](), [migration-guide](), [monorepo](), [performance](), [speed](), [tooling](), [tools](), [webpack]() ### AI overview A Yelp engineering blog post explains how the team migrated monorepo builds from Webpack to Rspack. It reports an approximately 50% reduction in build time and discusses compatibility, configuration, custom plugins, and a staged rollout. ### Source excerpt Over the years, Webpack has remained the bundler of choice for many JS projects, including here at Yelp. While it has served us well, its speed has increasingly become a bottleneck as our monorepo continues to grow. Fortunately, a bunch of new build tools (Vite, Parcel, Rspack, etc.) have emerged in recent years. Each of these tools promises different ways of improving performance and developer experience. In this blog post, we'll walk through how we migrated our monorepo builds from Webpack to Rspack and achieved an approximately 50% reduction in build time. Why Rspack Our team has been closely observing... ## How KIKO Milano scales for Black Friday DevFeed: [How KIKO Milano scales for Black Friday]() Original publisher: [Read original article]() Author: Meghan Schaefer Published: 2026-05-05T07:00:00Z Content type: article Language: en Sources: [Vercel News]() Topics: [Vercel](), [Amazon EC2](), [Amazon Web Services](), [build times](), [Provisioning](), [configuration](), [App](), [releases]() Tags: [aws](), [configuration](), [infra](), [infrastructure](), [performance](), [provisioning](), [releases](), [vercel]() ### AI overview KIKO Milano moved its ecommerce application from manually scaled AWS infrastructure to Vercel. The migration eliminated three weeks of Black Friday infrastructure preparation, reduced application build times by 75%, and enabled the team to deploy multiple times per day. Automatic scaling and on-demand environments allowed the team to focus on campaigns, testing, and the ecommerce experience instead of infrastructure limits. ### Source excerpt KIKO Milano on Vercel: Eliminated 3 weeks of Black Friday infrastructure prep 75% decrease in app build times Went from minimal releases to deploying multiple times per day KIKO Milano's ecommerce team used to treat peak traffic as an operations project. Weeks before Black Friday, they had to manually scale AWS infrastructure and adjust application configuration, knowing that if demand exceeded forecasts, their site could slow down or even break, costing them real revenue. After migrating to Vercel, they removed manual prep from their playbook. Instead of provisioning infrastructure, their team now ships campaigns and tests daily. The Black Friday problem: manual scaling and stressful failure modes Before Vercel, KIKO ran their ecommerce app on AWS EC2 instances sized for normal traffic, then scaled by hand ahead of peak periods. This was their previous process leading into Black Friday: Manual scaling window: Black Friday prep began 2-3 weeks ahead of the event, then had to be unwound after the traffic spike passed. Infrastructure configuration: The infra team manually adjusted AWS EC2 capacity to support expected traffic. Application configuration: Scaling also required application-side changes, making peak readiness more than just an infrastructure task. War room prep: Chat channels and conference rooms were set up for teams to triage performance and downtime problems. Beyond the manual prep work, KIKO's dev team had to anticipate failure modes that hurt the business. Slow navigation and site instability made it hard for users to purchase, and, in Ant's words, they knew that at any point, "everything could break." Worry-free delivery and automatic scaling Vercel changed the work from preparation to execution. With environments available on demand, faster builds, and automatic scaling during traffic spikes, Ant's team stopped planning around infrastructure limits and focused on the ecommerce experience itself. Environments without the bottleneck KIKO's old setup r ## Announcing TypeScript 7.0 Beta DevFeed: [Announcing TypeScript 7.0 Beta]() Original publisher: [Read original article]() Author: Daniel Rosenwasser Published: 2026-04-21T18:24:17Z Content type: release Language: en Sources: [TypeScript]() Topics: [build times](), [ci]() Tags: [build-times](), [ci](), [command-line](), [extension](), [go](), [javascript](), [release](), [speed](), [typescript](), [vs-code]() ### AI overview TypeScript 7.0 Beta introduces a Go-based compiler foundation that the article says is often about ten times faster than TypeScript 6.0 while preserving its type-checking semantics. It is presented as ready for day-to-day use, CI pipelines, and VS Code editing through a preview extension. ### Source excerpt Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta! If you haven't been following TypeScript 7.0's development, this release is significant in that it is built on a completely new foundation. Over the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles [...] The post Announcing TypeScript 7.0 Beta appeared first on TypeScript. ## Why I'm Seeking Sponsors for Metro, a Kotlin Dependency Injection Compiler DevFeed: [Why I'm Seeking Sponsors for Metro, a Kotlin Dependency Injection Compiler]() Original publisher: [Read original article]() Author: Zac Sweers Published: 2026-01-29T15:56:29Z Content type: opinion Language: en Sources: [Zac Sweers]() Topics: [Compiler](), [Dependency injection](), [build performance](), [build times](), [Kotlin](), [Mobile](), [monorepo]() Tags: [android](), [build-performance](), [build-times](), [compiler](), [dependency-injection](), [developer-productivity](), [kotlin](), [metro](), [monorepo](), [open-source]() ### AI overview The author discusses opening GitHub sponsorship for Metro, a Kotlin dependency injection project. They report build-performance gains, benchmark results against Dagger, compatibility across Kotlin and IDE versions, and adoption by several engineering teams. ### Source excerpt Metro is the proudest work of my career. Ever since starting it on vacation in November 2024, building it has been an incredible journey and the community reception has been nothing short of wonderful. It sits at the intersection of several fields I've come to specialize in, ranging ## Vite 8 Beta: The Rolldown-powered Vite DevFeed: [Vite 8 Beta: The Rolldown-powered Vite]() Original publisher: [Read original article]() Author: The Vite Team Published: 2025-12-03T00:00:00Z Content type: release Language: en Sources: [Vite]() Topics: [build times](), [Web Development]() Tags: [build-performance](), [javascript](), [migration](), [performance](), [release](), [rust](), [toolchain]() ### AI overview Vite 8 beta replaces its esbuild-and-Rollup pipeline with the Rust-based Rolldown bundler. The release emphasizes faster production builds, more consistent development and production behavior, and an integrated Vite, Rolldown, and Oxc toolchain. ### Source excerpt Vite 8 Beta: The Rolldown-powered Vite December 3, 2025 TL;DR: The first beta of Vite 8, powered by Rolldown, is now available. Vite 8 ships significantly faster production builds and unlocks future improvement possibilities. You can try the new release by upgrading vite to version 8.0.0-beta.0 and reading the migration guide. ## Next.js 15.5 DevFeed: [Next.js 15.5]() Original publisher: [Read original article]() Author: Luke Sandberg Published: 2025-08-18T20:00:00Z Content type: release Language: en Sources: [Next.js Blog]() Topics: [build times](), [Node.js](), [web applications]() Tags: [build-performance](), [next-js](), [node-js](), [release](), [typescript]() ### AI overview Next.js 15.5 adds Turbopack production builds in beta, stable Node.js middleware support, TypeScript enhancements, and deprecation warnings ahead of Next.js 16. ### Source excerpt Next.js 15.5 includes Turbopack builds in beta, stable Node.js middleware, TypeScript improvements, `next lint` deprecation, and deprecation warnings for Next.js 16. ## From Zero to GPU: A Guide to Building and Scaling Production-Ready CUDA Kernels DevFeed: [From Zero to GPU: A Guide to Building and Scaling Production-Ready CUDA Kernels]() Original publisher: [Read original article]() Author: David Holtz; Daniël de Kok Published: 2025-08-18T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [CUDA](), [GPU](), [PyTorch](), [Deployment](), [build times](), [C++]() Tags: [c-plus-plus](), [cuda](), [deployment](), [ecosystem](), [gpu](), [guide](), [hub](), [kernels](), [kernels-community](), [optimization](), [pytorch]() ### AI overview A guide to building modern, production-ready CUDA kernels with Hugging Face Kernel Builder. It covers developing a custom RGB-to-grayscale kernel with PyTorch's C++ API, supporting multiple architectures, managing dependencies, and addressing production and deployment challenges. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Optimizing Docker Image Builds for Size and Build Time DevFeed: [Optimizing Docker Image Builds for Size and Build Time]() Original publisher: [Read original article]() Author: Pranshu Raj Published: 2025-07-31T17:25:43Z Content type: tutorial Language: en Sources: [Pranshu Raj - blog on backend systems, performance and sidequests]() Topics: [Docker](), [Docker Image](), [Dockerfile](), [build performance](), [build times](), [Benchmark](), [Go Language]() Tags: [alpine](), [benchmark](), [build-performance](), [build-times](), [docker](), [docker-image](), [docker-image-size](), [go](), [how-to]() ### AI overview This tutorial describes optimizing a Go backend Docker image using Alpine base images and multi-stage builds. The reported changes reduced image size from 1.29 GB to 27.1 MB and build time from 43.8 seconds to 23.6 seconds. ### Source excerpt How to optimize (and benchmark) docker image builds for build time and image size. ## How Blacksmith paired Postgres and ClickHouse for fast CI and real-time observability DevFeed: [How Blacksmith paired Postgres and ClickHouse for fast CI and real-time observability]() Original publisher: [Read original article]() Author: ClickHouse Published: 2025-07-29T12:50:25Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [ci](), [telemetry](), [build times](), [GitHub Actions]() Tags: [analytics](), [build-times](), [ci](), [clickhouse](), [cloud](), [github-actions](), [observability](), [postgres](), [real-time]() ### AI overview Blacksmith uses Postgres for operational metadata and ClickHouse Cloud to query large volumes of CI observability data. The article describes the move as a way to improve analytical-query performance, scalability, and developer experience. ### Source excerpt What happens when you combine Postgres, ClickHouse Cloud, and real-time ingestion via the Postgres CDC connector in ClickPipes? ## The quest for the five minute deploy DevFeed: [The quest for the five minute deploy]() Original publisher: [Read original article]() Author: Matthew Barrington Published: 2025-07-22T10:07:34Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [CI/CD](), [build times](), [Caching](), [Go Language](), [Deployment]() Tags: [build-times](), [caching](), [ci-cd](), [deployment](), [go](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [outage](), [post-mortem](), [slack-incident](), [speed]() ### AI overview This article describes how incident.io worked to reduce deployment time toward a goal of less than five minutes from merging a pull request to production. It examines slow Go builds and test suites, limitations of CI/CD caching, and the decision to evaluate different CI/CD providers based on price, reliability, extensibility, and familiarity. ### Source excerpt This is the story of how incident.io drastically cut down their code deployment times, detailing their journey from slow, inefficient CI/CD pipelines to achieving near "five-minute deploys" through strategic changes to their infrastructure and caching mechanisms. ## Analyze Your Nx Cloud Runs With Your AI Assistant DevFeed: [Analyze Your Nx Cloud Runs With Your AI Assistant]() Original publisher: [Read original article]() Author: Juri Strumpflohner Published: 2025-06-25T00:00:00Z Content type: tutorial Language: en Sources: [Juri Strumpflohner]() Topics: [ci](), [Model Context Protocol (MCP)](), [Cloud APIs](), [Conversational AI](), [Architecture & optimization](), [build times]() Tags: [ai](), [ai-assistants](), [build-times](), [ci](), [devops](), [mcp](), [model-context-protocol-mcp](), [nx](), [nx-cloud](), [optimization](), [resource]() ### AI overview This article explains how Nx Cloud MCP connects AI assistants to live CI data so technical teams can analyze pipeline runs conversationally, identify recurring build and test failures, compare cache performance, and optimize development workflows. ### Source excerpt Learn how to use Nx Cloud MCP to analyze CI data conversationally with AI assistants, identify failure patterns, and optimize your development pipeline through data-driven insights. ## Docusaurus 3.8 DevFeed: [Docusaurus 3.8]() Original publisher: [Read original article]() Author: Sébastien Lorber Published: 2025-05-26T00:00:00Z Content type: release Language: en Sources: [Docusaurus Blog]() Topics: [build performance](), [build times](), [Optimization](), [Cache](), [Webpack](), [Node.js](), [Netlify](), [Vercel](), [macOS]() Tags: [build-performance](), [builds](), [cache](), [macos](), [netlify](), [node-js](), [optimization](), [release](), [vercel]() ### AI overview Docusaurus 3.8 improves build performance through persistent caching, worker threads for static site generation, and other optimizations. The release also introduces Future Flags for preparing sites for Docusaurus 4 and adds new features. ### Source excerpt We are happy to announce Docusaurus 3.8. ## Building Scalable Mobile Projects at Android Makers 2025 DevFeed: [Building Scalable Mobile Projects at Android Makers 2025]() Original publisher: [Read original article]() Author: Cyril Mottier Published: 2025-04-10T08:37:01Z Content type: opinion Language: en Sources: [Cyril Mottier Blog]() Topics: [Mobile](), [scaling](), [builds](), [build times](), [maintenance]() Tags: [2025](), [build-times](), [builds](), [maintenance](), [mobile](), [scaling]() ### AI overview The article introduces a keynote on scaling mobile projects as codebases, contributor counts, and complexity grow. It highlights strategies for maintaining fast build times, reusable code, clear ownership, and resilient project structure. ### Source excerpt Edit - Aug 4: adding link to the video on YouTube I recently gave a keynote called "Building Scalable Mobile Projects: Fast Builds, High Reusability and Clear Ownership" at Android Makers 2025 in Paris. Here was the abstract. Every successful project eventually faces the challenges of scaling: an ever-growing codebase, an increasing number of contributors, and rising complexity. Without proper measures, this can lead to slow build times, a cluttered codebase, maintenance difficulties, code duplication, and even dead code--ultimately jeopardizing the company's ability to deliver value. ## Astro 5.3 DevFeed: [Astro 5.3]() Original publisher: [Read original article]() Author: Matt Kane Published: 2025-02-13T00:00:00Z Content type: release Language: en Sources: [The Astro Blog]() Topics: [Astro](), [build times](), [Server-side rendering](), [Netlify]() Tags: [astro](), [benchmark](), [build](), [build-times](), [cli](), [community-contribution](), [experimental](), [netlify](), [ssr]() ### AI overview Astro 5.3 improves page-rendering performance by avoiding unnecessary asynchronous rendering, with reported gains for SSR responses and static build times. It also adds automatic session storage setup for supported adapters, more control over Netlify bundling, and improved request handling. ### Source excerpt Astro 5.3 is here with faster page rendering, easier setup for experimental sessions, and more! [Next page]()