HTML Performance Basics: Why Markup Still Decides How Fast Your Site Loads

Most “my site is slow” problems I get called about on Long Island aren’t server problems. They’re markup problems. The HTML itself is bloated, blocking, or built in a way that forces the browser to wait on things it shouldn’t have to wait on. You don’t need a rebuild to fix most of it. You need to understand what the browser does with your HTML before it paints a single pixel.

How the browser actually reads your HTML

When a browser gets your HTML, it parses it top to bottom and builds the DOM. The moment it hits a <script> tag without special handling, parsing stops. The browser downloads and runs that script first, then continues. Same story with CSS: a stylesheet in the head blocks rendering until it’s fetched and parsed, because the browser refuses to paint unstyled content.

That’s the whole game. Every millisecond your HTML makes the browser wait is a millisecond your user stares at a blank screen. Google’s Core Web Vitals still weight this heavily, and Largest Contentful Paint (LCP) is the metric that hurts most sites.

Defer and async: the single biggest win

If you do one thing after reading this, fix your script tags. A plain <script src="..."> in the head is a render blocker. You almost never want that.

<!-- Bad: blocks parsing until downloaded and executed -->
<script src="/js/analytics.js"></script>

<!-- Good: downloads in parallel, runs after HTML is parsed -->
<script src="/js/analytics.js" defer></script>

<!-- Good for independent scripts with no DOM dependency -->
<script src="/js/vendor.js" async></script>

defer keeps execution order and runs after the DOM is ready. async runs whenever it finishes downloading, so only use it for things that don’t touch the DOM or depend on other scripts. Analytics and ad pixels are the usual async candidates. Your own app code is almost always defer.

Preload what matters, and only what matters

The browser discovers your fonts and critical images late, after it has already parsed the CSS that references them. That delay shows up directly in LCP. Tell the browser early with a resource hint.

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="https://i0.wp.com/www.kennykey.com/img/hero.webp" as="image" fetchpriority="high">

Two warnings. First, preloading everything defeats the purpose; you’re just competing with yourself for bandwidth. Second, the crossorigin attribute on font preloads is not optional. Omit it and the browser downloads the font twice. I’ve seen that exact bug add 200ms to LCP on more than one site.

Stop shipping images that fight the layout

An image without width and height attributes causes layout shift, because the browser doesn’t know how much space to reserve until the image loads. Then everything jumps. That’s Cumulative Layout Shift, and it’s easy to kill.

<img src="https://i0.wp.com/www.kennykey.com/img/card.webp"
 width="800" height="600"
 loading="lazy" decoding="async"
 alt="Product card">

Set loading="lazy" on anything below the fold. Do not lazy-load your hero image; that delays LCP for no reason. Modern CSS handles the aspect ratio automatically when width and height are present, so the space is reserved before the image arrives.

Trim the DOM, trim the CSS

A 5,000-node DOM is slow to parse and slow to style. If you’re rendering a giant table or a long list, virtualize it or paginate it. The browser has to do real work for every node.

On the CSS side, the fastest stylesheet is the small one. If you’re shipping a framework’s entire CSS bundle to style four components, that’s render-blocking weight your users pay for on every page load. Inline the critical above-the-fold CSS and defer the rest:

<style>/* critical styles here */</style>
<link rel="stylesheet" href="/css/main.css" media="print" onload="this.media='all'">

That media="print" trick loads the stylesheet without blocking render, then flips it to apply once it’s ready. It’s a well-worn pattern and it works.

A quick checklist

• Every script is defer or async, never bare in the head.
• Fonts and the hero image are preloaded, and fonts include crossorigin.
• Images have width, height, and the right loading strategy.
• Critical CSS is inlined; the rest loads non-blocking.
• Nothing renders 5,000 DOM nodes when 200 would do.

None of this requires new infrastructure or a hosting migration. It’s editing the HTML you already have. If you’d rather hand it off, I do this kind of work as part of Long Island web design and performance audits, and it’s usually a few hours, not a few weeks.

FAQ

Does HTML really affect load speed, or is it just my server?

Both matter, but HTML structure decides when the browser is allowed to start rendering. Blocking scripts and stylesheets delay that start regardless of how fast your server responds.

Should I use async or defer?

Use defer for your own scripts and anything that touches the DOM. Use async for independent third-party scripts like analytics that don’t depend on anything else.

Will fixing my markup actually improve my Core Web Vitals scores?

Usually yes, especially LCP and CLS. Preloading key resources and setting image dimensions are two of the highest-impact changes you can make without touching your hosting.