A client sent us a template ZIP last spring with the note “just needs a few tweaks”. Inside: 38 stylesheets totalling roughly 2 MB uncompressed, jQuery 1.12, a carousel plugin whose last GitHub commit was in 2017, and inline onclick attributes on 60-odd elements. The tweaks took nine days. Six of those days were spent undoing decisions someone made in the template, not building anything the client asked for.

That is the actual cost of picking badly. The sales page tells you nothing about it. Demo count, screenshot quality and the number on the sales badge correlate weakly at best with how the thing behaves once you’re three sprints in and the client wants a new section type.

So here’s the process we use to choose an HTML template when we’re going to live inside it for months. It takes about an hour per candidate. It has saved us far more than an hour, repeatedly.

Open the demo in DevTools before you read a word of the sales copy

Every multipurpose template has a pretty demo. What you actually want to know is what that demo costs to load and how much of the payload is dead weight you’ll be shipping to users who never see it.

Load the demo homepage with the Network tab open, throttled to Slow 4G, cache disabled. Write down three numbers: total transferred bytes, number of requests, and Largest Contentful Paint. For a marketing homepage with a hero image, we treat 1 MB transferred and an LCP under 2.5 seconds as the line. Plenty of templates blow past 4 MB because the demo loads three font families, a 1.4 MB hero JPEG and every JS plugin in the bundle regardless of whether the page uses any of them.

Then open the Coverage tab (Cmd+Shift+P, “Show Coverage”), reload, and look at the unused percentage for the main stylesheet. Over 90 percent unused on a demo page is normal for a big multipurpose template and not automatically disqualifying. What matters is whether you can do something about it. If the CSS is a single monolithic minified file with no source, you’re stuck. If it ships SCSS partials or a PurgeCSS-friendly structure, you can cut it down.

# After downloading: what are you actually committing to?
find . -name ".css" ! -name ".min.css" -exec du -ch {} + | tail -1
find . -name ".js"  ! -name ".min.js"  -exec du -ch {} + | tail -1

Dependency count in the vendor folder is a proxy for future breakage
ls -1 js/plugins* vendor/ 2>/dev/null | wc -l

jQuery version, if any
grep -m1 -oE 'jQuery (JavaScript Library )?v[0-9.]+' js/*.js

One more demo-side check that catches a surprising amount: scroll the page slowly and watch for layout shift. Reveal-on-scroll libraries configured without reserved space produce CLS that no amount of image optimisation later will fix. We wrote about the trade-offs in micro-interactions and scroll animation without wrecking performance, and templates are where most of the damage originates.

How to evaluate an HTML template by reading its code

Almost every serious template on ThemeForest offers a live preview of the HTML. You don’t need the ZIP to learn most of what matters. View source on the demo and look for four things.

Markup discipline

Is there exactly one <h1>? Do sections use <section> and <nav>, or is it <div class="section"> all the way down? Divs everywhere are survivable. Heading levels chosen for font size rather than document structure are a tell that nobody on the team thought about assistive technology, which predicts problems elsewhere.

Class naming and CSS variables

A Bootstrap 5.3 base with CSS custom properties for colour and spacing means you can rebrand in a single :root block. A template with hard-coded hex values scattered across 38 files turns every rebrand into a find-and-replace exercise. This single factor changes theming time by days on a large site.

/ What you want to be able to do on day one /
:root {
  --bs-primary: #1f6feb;
  --bs-body-font-family: "Inter", system-ui, sans-serif;
  --themeColor: var(--bs-primary); / template's own token aliased to Bootstrap's /
}
/ And dark mode should already be wired to the standard attribute /
[data-bs-theme="dark"] { --themeColor: #58a6ff; }

Inline scripts and handlers

If the template scatters <script> blocks and onclick attributes through the markup, you cannot ship a strict Content Security Policy without a rewrite. For any client in finance, healthcare or public sector, that’s a hard stop. Check it in seconds:

grep -roE 'on(click|load|change|submit|mouseover)="' --include="*.html" . | wc -l
grep -rc '<script>' --include="*.html" . | awk -F: '$2>0'

How the demos relate to each other

This is the question nobody asks, and it decides your build weight. A template advertising 200 demos either ships one shared core stylesheet plus small per-demo overrides, or it ships 200 near-duplicate folders with their own CSS. The second pattern is where you end up with 2 MB of stylesheet because the author never deduplicated. Download the trial or read the docs structure: if there’s a single css/style.css plus css/demos/<name>.css, that’s the good pattern. It’s how Canvas has been structured for years, and it’s the reason you can delete 190 demos and lose nothing.

The dependency stack is the real commitment

You’re not buying a design. You’re adopting somebody else’s JavaScript choices, and you’ll be maintaining them for as long as the site lives.

Current-generation acceptable in 2026: Bootstrap 5.3.x, Swiper 11 or later, GSAP 3.x (whose paid plugin tier became free in 2025, which quietly removed a real licensing headache for template users), vanilla custom scripts, Lenis or native CSS scroll-driven animations. Tolerable: jQuery 3.7 for legacy plugin compatibility, as long as the template’s own code doesn’t require it. Avoid: jQuery below 3.x, Bootstrap 4, anything that bundles its own fork of a library so you can’t upgrade, and sliders that ship as a minified blob with no upstream repo.

The failure mode is specific. A CVE lands against a bundled plugin, you go to update it, and you discover the template author modified the plugin source to add a feature. Now you’re maintaining a fork. We’ve had this happen with two different lightbox libraries. Both times the fix was ripping the plugin out entirely.

Ask one question in the pre-sale comments: “Do you modify any of the bundled third-party libraries, or are they vendored unchanged?” The answer, and how fast it comes, tells you a lot.

Test the three components that always fail

Run the demo through axe DevTools if you like, but automated tools catch maybe a third of real issues. Do these four manual checks instead, in this order, because they map to the failures we see most often in audits:

1. Tab through the header. Does the dropdown open on focus or only on hover? Can you reach the sub-items with the keyboard? Hover-only dropdowns are still shipped in 2026 and they’re an instant WCAG 2.1 failure.
2. Open the mobile menu, then press Escape. It should close and return focus to the toggle. It usually doesn’t.
3. Open a modal and tab. Focus should be trapped inside it. If you tab straight out into the page behind, the template’s modal is hand-rolled and broken. Bootstrap’s native modal handles this correctly, which is a decent argument for templates that use it rather than reinvent it.
4. Zoom the browser to 200 percent. Text-only zoom breaks templates built entirely in viewport units. Look for horizontal scrollbars and clipped headings.

Contrast is worth a pass too, especially in dark mode variants where authors often use a mid-grey body text on near-black that lands around 3.8:1. The same failures repeat across CMS themes as well, which we catalogued in the five accessibility failures auditors always find.

Read the changelog and the support thread, ignore the rating

Star ratings measure how people felt at purchase. The changelog measures whether anyone is still home.

What we look for: at least three or four dated releases in the past 12 months, with entries specific enough to be real (“updated Swiper to 11.2, fixed RTL offset in sticky header”) rather than “bug fixes and improvements”. A template that got a Bootstrap 5.3 update within a few months of that release is being actively maintained. One that still says “Bootstrap 5.0.2” in 2026 is frozen.

Then open the comments tab and sort to the newest. How many unanswered questions in the last month? What’s the tone of the author’s replies? Six months of unanswered support requests is the clearest signal you’ll get, and it’s free to check. Also note the support window: ThemeForest items include six months of support by default, extendable to 12. Item updates continue regardless, but support does not.

On licensing, know which one you need before checkout. A Regular license covers one end product where users are not charged. If you’re building a paid SaaS UI or a product that end users pay to access, you need Extended. Getting this wrong is a legal problem, not a technical one. And if you’re weighing the template route against a builder or a from-scratch build in the first place, we broke the actual numbers down in HTML template vs website builder vs custom build.

What no template will do for you

Every HTML template ships contact forms that go nowhere. The markup is there, the validation styles are there, the action attribute points at a PHP file that either doesn’t exist or is a 2014-era mail script with no CSRF protection and no rate limiting. Do not ship that file. Two of the worst spam incidents we’ve cleaned up started with a bundled sendmail.php.

Decide your form handling at evaluation time, because it affects hosting. For static deployments, an endpoint service means you keep the static hosting and still get submissions routed to email, Slack or a webhook. That’s the exact gap WebForms fills: point the form at the endpoint, no backend to maintain.

<form action="https://webforms.to/submit/YOUR_ID" method="POST">
  <input type="text" name="name" required>
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <!-- honeypot: bots fill it, humans never see it -->
  <input type="text" name="_gotcha" style="display:none" tabindex="-1" autocomplete="off">
  <button type="submit">Send</button>
</form>

The other gaps: search, content editing, i18n beyond string duplication, and anything stateful. If the client will edit copy weekly, a static template plus a git workflow is the wrong answer no matter how good the template is. That’s a CMS job.

The one-hour evaluation, in order

1. Demo homepage on Slow 4G: record transfer size, request count, LCP. (10 minutes)
2. Coverage tab: unused CSS percentage, and whether SCSS sources ship. (5 minutes)
3. View source: heading structure, CSS variables, inline handlers, script count. (10 minutes)
4. Keyboard and zoom pass on header, mobile nav, modal. (10 minutes)
5. Changelog: releases in last 12 months, dependency versions named. (5 minutes)
6. Comments: unanswered questions in last 30 days. (5 minutes)
7. Docs: is there a documented build step, or is it “edit the minified CSS”? (5 minutes)
8. Check the two or three page types you actually need exist, in the layout you need. Not the demos you’ll never use. (10 minutes)

Step 8 is the one people skip and regret. The best HTML template for a 200-page documentation site is not the one with the most beautiful agency homepage. If you need a pricing table with a comparison matrix, a multi-level docs sidebar and a searchable blog index, verify those three components exist as built pages. Building them yourself inside a foreign codebase costs more than building them from scratch.