Throughout my software development career, especially over the last 20 years, I've constantly sought a balance between system and software aspects. One of these balancing points is the issue of application size. On one side, I have an engineering instinct that says, "Every kilobyte matters, every excess is a cost," while on the other, a pragmatic perspective that argues, "Delivering value-adding functionality to the user as quickly as possible is essential." Navigating between these two extremes has been a significant part of my career.

So, should we really fight for every kilobyte? Or should we prioritize functionality? This is a gray area that varies depending on the project's context, target audience, and even deployment model. In my experience, there's no clear-cut answer to this question, but the best results can be achieved by asking the right questions and making conscious trade-offs. In this post, I'll share my thoughts and observations from different fields on this topic.

The Harsh Realities of Size in the Mobile World

The importance of size in mobile applications is undeniable. Especially in markets like Turkey, where mobile internet is widespread but not always fast or unlimited, app size directly affects download rates, user experience, and even how long an app stays on a device. Years ago, while developing my own Android spam application, I experienced this reality repeatedly. The smaller I made the app, the higher the download and installation rates became.

For example, at one point, my app's main package was around 12MB. After several rounds of optimization (cleaning up unnecessary resources, code compression with ProGuard, optimizing native libraries), I managed to reduce this size to 7MB. This 40% reduction directly reflected in my Play Store download statistics. This difference was critical, especially for users with low-bandwidth connections or those using capped mobile data. Some users even provided feedback stating they refrained from downloading the app simply because of its large size.

💡 Mobile Optimization Tip

When developing Android apps, using tools like apkanalyzer to inspect APK content in detail is very useful for understanding which resources or libraries take up the most space. Unused language packs or high-resolution images often occupy significant space.

Another impact arises during update processes. Users don't want to download large updates with every new version. This can lead to delays or complete cancellations of in-app updates. When I added a feature to my Android app, if it required a new large library, I considered loading it modularly or offering it only to Premium users. Because I didn't want every user to download that size. This situation constantly forces mobile developers to balance functionality with size. The app's cold start time is also directly affected by size; larger applications generally start slower.

Different Dynamics in Web and Enterprise Software

In the web world, especially with modern SPA (Single Page Application) architectures, JavaScript bundle sizes have become a serious problem. The total size of JavaScript, CSS, and other resources that users need to download to their browser directly affects the site's loading speed. Years ago, while developing a React-based dashboard application for a client project, we found our initial bundle size reached an exorbitant 4MB. This meant a poor initial loading experience.

To remedy the situation, we undertook aggressive optimizations:

1. Code Splitting / Lazy Loading: We loaded only the necessary components for the main page, splitting other routes and modules to be downloaded when the user needed them.
2. Tree Shaking: We optimized Webpack configuration to remove unused code from the bundle.
3. Image Optimization: We switched to modern formats like WebP and compressed images.
4. CDN Usage: We distributed static assets via global CDNs.

As a result of these steps, we managed to reduce the initial bundle size to around 800KB. This significantly improved the perceived speed of the site for users. According to our measurements, the Largest Contentful Paint (LCP) decreased by 60%. In web projects, this type of optimization can even affect SEO performance. [related: Web performance optimizations and SEO relationship]

In enterprise software, the situation is slightly different. Since the end-user typically accesses it from within the corporate network, bandwidth may not be as limited as mobile. However, deployment times and dependency management come to the forefront here. When developing an ERP for a manufacturing company, deploying a new module could sometimes take hours. One reason for this was the repeated deployment of a single large JAR file (monolith) with all its dependencies.

# Example JAR size and deployment time for a monolithic application
# These were typical values seen for a JAR file of approximately 300MB
# Even for a single version change, this time had to be waited.
$ ls -lh my-erp-monolith-1.2.3.jar
-rw-r--r-- 1 erbay erbay 298M May 28 14:30 my-erp-monolith-1.2.3.jar

$ time scp my-erp-monolith-1.2.3.jar user@erp-server:/opt/erp/
my-erp-monolith-1.2.3.jar                          100%  298MB  50.0MB/s   00:05

$ time systemctl restart erp-application.service
# Time for the application to fully start and enter service
real    1m35s
user    0m2s
sys     0m1s

In such cases, size impacts operational speed and agility rather than direct performance. Managing dependencies and enabling different modules to be deployed separately (with a transition towards a microservices architecture) both alleviates the size problem and accelerates development and operational processes.

Indirect Effects of Size in Backend and Infrastructure

In backend applications or infrastructure components, size is often given less importance because it doesn't directly affect the end-user. However, indirect costs and operational burdens arise here too. Especially since I started working with container technologies, I've personally experienced how critical Docker image sizes can be.

The size of a Docker image can directly affect deployment time, disk usage, network traffic, and even security vulnerabilities. For example, running an application in an Alpine Linux-based image (approx. 5MB base size) instead of an Ubuntu-based image (approx. 100MB base size) creates significant differences in network traffic and storage space saved with each new deployment.

# Ubuntu-based, larger image example
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3 python3-pip && rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python3", "app.py"]

# Alpine-based, smaller image example
FROM python:3.9-alpine
COPY requirements.txt .
RUN pip install -r requirements.txt --no-cache-dir
COPY . .
CMD ["python", "app.py"]

The difference between these two Dockerfiles can result in hundreds of megabytes in the final image size. In the backend of one of my side products, for services continuously passing through the CI/CD pipeline, I saw deployment times shortened by 30% using Alpine-based images. This is a significant gain, especially in an environment where deployments happen dozens of times a day. [related: Container image optimization techniques]

The issue of disk space also comes into play here. When running multiple containers on a server, their logs, temporary files, and image layers can eventually fill up the disk. Especially in an environment running with journald's default settings, log sizes can sometimes get out of control. Similarly, build caches or intermediate images in CI/CD processes can also occupy unnecessary disk space, reducing performance. Once, on my self-hosted CI/CD runner, I saw pipelines halt because Docker build caches completely filled the disk. This was a concrete example of how size directly impacts not only the end-user but also operational costs.

The Fine Line Between Functionality and Speed

In the application development process, adding a new feature usually means a new library or more code. This inevitably increases the application's size. The real question here is whether the functional gain brought by this size increase justifies the resulting cost. Sometimes, we realize we've added a very large library for a very small piece of functionality.

For example, when a need for PDF generation arises in a project, including a popular PDF library (e.g., iText in Java or ReportLab in Python) in the project can increase the package size by tens of megabytes. If this PDF feature is only for specific reports and used rarely, alternatives can be considered, such as running it as a separate microservice or generating it server-side and only sending the output to the client, instead of including this large library in the main package.

⚠️ ORM Trap: N+1 Problem

When using large and complex ORMs, especially due to eager loading or N+1 select issues, too much data can be fetched unnecessarily from the database. This does not directly increase the application's size but increases network traffic and memory usage, negatively impacting performance. In a production ERP, a specific report took 30 seconds to open. Upon investigation, I found that the ORM was making separate queries for each row and fetching hundreds of kilobytes of data unnecessarily.

This situation becomes even more pronounced when under pressure for rapid delivery. It can be tempting to opt for the easiest solution (often the largest library) "to get a feature out quickly." However, this accumulates technical debt and makes future optimizations more difficult. In my experience, these "quick solutions" often lead to higher costs in the medium and long term. While adding a 50KB library might seem insignificant initially, the accumulation of such additions over time can seriously affect the overall performance and maintenance of the application. This once again proves that software architecture is not just about writing code, but also about anticipating organizational flows and potential future growth scenarios.

Pragmatic Approach: Where and How Much to Optimize?

Extreme approaches like "give up everything" or "don't care about anything" usually don't work in application size optimization. The important thing is to strike a pragmatic balance according to the needs of the project and the target user group. There are some questions I ask myself to find this balance:

• Who is my target audience? Mobile users in developing countries, or professionals in a high-bandwidth corporate network?
• How often is the application downloaded/updated? Is it a one-time download, or a continuously updated SaaS product?
• What would be the benefit of optimization? How many seconds would a 1MB reduction save, how many users would it satisfy?
• What would be the cost of optimization? Development time, maintenance difficulty, loss of readability?

The answers to these questions have led me to different strategies. For example, while I might fight for every kilobyte in a consumer-facing mobile app, I can tolerate larger bundle sizes in an internal corporate management panel. The important thing here is to make a conscious decision and stand by it.

When developing an internal platform for a bank, even a frontend bundle size of 10MB was not much of an issue. Because users accessed the platform from a fixed network with powerful computers, and the browser cache kicked in after the initial load. However, for the financial calculators of my side product, fast page loading was critical. So I compressed every JavaScript and CSS file, optimized images, and even rendered some dynamic content server-side.

// Webpack example for code splitting and lazy loading
// This ensures only main page components are loaded into the main bundle,
// other modules are downloaded when the user needs them.

const Dashboard = lazy(() => import('./Dashboard'));
const Reports = lazy(() => import('./Reports'));

function App() {
  return (
    <div>
      Loading...</div>}>
        {/* Router-based lazy loading */}
        {window.location.pathname === '/dashboard' && }
        {window.location.pathname === '/reports' && }

    </div>
  );
}

While implementing such strategies, I constantly measured the performance I achieved. I observed the effects of changes with Lighthouse scores, Core Web Vitals metrics, and my own custom telemetry systems. For example, when I applied an image compression algorithm, I saw that the page size decreased by 15% and the LCP (Largest Contentful Paint) value improved by an average of 0.5 seconds. These concrete data showed that my optimization efforts were not in vain.

Conclusion

The issue of application size is a good example of a trade-off cycle we frequently encounter in engineering. The answer to the question "A battle for every kilobyte, or prioritizing functionality?" is not black or white, but a shade of gray that varies according to the project's context. My clear position has always been in favor of "conscious balance."

On mobile platforms or in low-bandwidth environments, size optimization is vital. On the web, especially for sites where initial loading speed is critical, the importance of size is also great. In the backend and infrastructure, size primarily affects operational costs and deployment speed. In every case, our duty as developers is to provide the best user experience while not neglecting operational efficiency. This sometimes means tolerating an extra few kilobytes, and sometimes it means compressing every byte with hours of optimization work. The important thing is to support these decisions with data and act in line with the overall goals of the project.