Egemen

The Cost of Everything Around the Words

Published 6 minute read

Imagine an article whose useful content is about 20 KB of HTML and text.

That document may arrive surrounded by something like this:

  • 500 KB of CSS
  • 2 MB of JavaScript
  • 5 MB of images
  • analytics
  • advertising
  • web fonts
  • tracking
  • third-party SDKs
  • 30 to 50 network requests

These figures are illustrative, not a benchmark for every modern website. The important distinction is between the material the reader asked for and the machinery required to reveal it.

The reader wanted an article. The browser received a small software system.

The short path

In theory, reading a blog post requires a very short exchange:

GET /article
-> HTML arrives
-> the reader reads the text

A browser already knows how to display headings, paragraphs, lists, quotations, links, and images. Those capabilities do not need to be recreated for each article.

A more complicated site can turn the same request into a dependency chain:

HTML
-> main.css
-> framework.js
-> runtime.js
-> vendor.js
-> font
-> analytics.js
-> ad.js
-> image loader
-> API request
-> the page finally looks complete

Some of those resources may be useful. The problem begins when they become prerequisites for the document itself.

If the HTML, CSS, and application code arrive but a third-party script times out, a resilient page still presents the article. A brittle page may wait for hydration, remote configuration, a consent manager, an advertising callback, or a component that never finishes initializing. The words are present in the response, yet the reader cannot comfortably reach them.

That is a design failure, not merely a slow connection.

Latency becomes a dependency graph

Page speed is often discussed as though it were one number. In practice, a page can depend on many separate downloads, parsers, execution steps, and remote services.

Each required step introduces another opportunity to wait. The browser may need to discover a file, open a connection, negotiate encryption, download the response, parse it, execute it, and then discover more work. Several small delays can become a long critical path.

More bandwidth helps, but it does not erase dependency depth. A fast connection still waits for a slow origin, a stalled third party, an overloaded API, or code that occupies the main thread.

A document with a short path has fewer ways to arrive late.

Reliability suffers before the server fails

A site can be online while its content is functionally unavailable.

The origin may return 200 OK, but the interface remains blank because a bundle failed. A font service may be blocked. An extension may reject a tracker that the page accidentally treats as essential. A corporate network may filter one hostname. A mobile connection may disappear after the first response. A script update may change behavior without the publisher changing the article.

Adding a dependency can be reasonable. Making basic reading depend on that dependency is a separate decision.

The useful test is simple: if this resource fails, can the reader still read the page?

For an article, the answer should usually be yes.

The reader pays for the machinery

Extra code is not free merely because the publisher does not see an invoice for it.

The reader supplies the network transfer, memory, processor time, and battery power. On an older phone, a large script can cost more than its download size suggests because it must also be parsed, compiled, and executed. On a limited connection, decorative media may compete with the text the reader actually requested.

This cost is unevenly distributed. A page that feels instant on a recent laptop and a fast local network may behave very differently on modest hardware, a congested connection, or an expensive data plan.

Keeping a document small is therefore not just scorekeeping. It is a way to require less from an unknown reader.

More code creates more trust

A third-party request is also a trust decision.

Analytics, advertising, embedded media, remote fonts, and SDKs can expose request metadata or execute code in the page. They expand the number of organizations and systems involved in displaying a paragraph. They also expand the surface that must be reviewed, updated, configured, and defended.

This does not mean every external service is malicious. It means each service needs a reason to be present.

If a dependency can observe the reader, change page behavior, or prevent the content from appearing, it is part of the publication system whether the author thinks about it or not.

JavaScript is not the enemy

An interactive editor, map, game, collaborative tool, or real-time dashboard may genuinely need substantial browser-side code. Complexity can be justified when the task itself is complex.

An essay is different.

Web bloat is not defined by the presence of JavaScript or by an arbitrary file-size threshold. It is the accumulation of work that is disproportionate to the reader’s goal. It appears when infrastructure serves itself, when optional features become mandatory, or when a document is treated as an application without gaining anything useful from the transformation.

The question is not whether a technology is modern. The question is what job it performs.

Why this site takes the smaller route

This site is built around static documents. Markdown is converted into HTML before publication. The browser receives the finished page and a small local stylesheet. There is no client application to initialize before the first paragraph becomes useful.

The site also avoids advertising, analytics libraries, third-party fonts, remote media players, tracking scripts, and browser-side SDKs. Images and audio, when an article needs them, are stored locally and remain optional to understanding the text.

These constraints reduce the number of requests, but request count is not the only goal. The more important result is graceful failure.

If the stylesheet does not load, the HTML remains structured and readable. If an image fails, its text alternative still describes its role. If optional audio is unavailable, the written article remains complete. If JavaScript is disabled, nothing essential changes because the site does not require it.

The page does not need to finish becoming an application. It begins as a document.

A practical standard

Before adding a browser dependency, it is worth asking:

  1. What reader need does this serve?
  2. Must it block the article?
  3. What happens when it times out?
  4. Does it contact another origin?
  5. Does it collect or expose reader data?
  6. Can the same result be achieved in the generated HTML?
  7. Will the page remain understandable after this tool disappears?

These questions do not forbid complexity. They make complexity justify its cost.

A small site can still be badly designed, insecure, or unreliable. Static HTML is not a substitute for careful publishing, secure tooling, or correct hosting configuration. It simply gives those responsibilities a narrower and more inspectable surface.

The intended outcome

The goal is not nostalgia, minimalism as decoration, or a perfect performance score. It is to keep the distance between a request and its answer short.

A reader asks for an article. The server sends the article. The browser displays it. Optional presentation can improve that experience, but it should not hold the words hostage.

The 20 KB of content is the reason the page exists. Everything around it should earn its weight.