What We Shipped in April 2026 — Analytics, Performance, and Polish

This month brought major improvements to how we track and optimize the service — plus a handful of polish updates that make the whole experience feel more refined.

April was about two things: understanding how people use Website Analyzer, and making the parts they use most work better.

Here's what shipped.

Analytics dashboard — see what's being analyzed

We now track every analysis that runs through the service. Not in a creepy way — we're not logging individual user data — but in a way that lets us see aggregate patterns: which domains are analyzed most often, what technologies show up in the wild, which countries are using the tool, and where traffic is coming from.

The analytics dashboard is internal for now, but it's already useful. We can see that the median analysis takes about 2.3 seconds, that most analyses happen during weekday working hours (not surprising), and that about 40% of results are served from cache rather than requiring a fresh scan.

That last stat matters because it directly affects load on our servers. Which brings me to the next thing.

Smarter caching strategy

We've completely reworked how caching works behind the scenes.

Before, we cached every analysis result for 24 hours. That worked, but it wasn't smart. Popular sites were being re-analyzed constantly while obscure domains had stale data sitting in the cache for days.

Now we have a tiered caching system:

The result: frequently-analyzed sites have fresher data, server load is more predictable, and the cache hit rate went from ~40% to ~67%.

Bug reporting improvements

The bug report form at the bottom of every results page now includes a report number and confirmation screen. Small change, but it makes the system feel more legitimate — you know your report was logged, and if you follow up, you can reference the report ID.

We've also started categorizing bug reports automatically based on keywords in the description. Reports mentioning "score", "grade", or "calculation" are tagged as scoring issues. Reports mentioning "SSL", "security", or "headers" are tagged as security-related. This makes triaging much faster.

Card hover behavior fixed

A subtle one: the analysis cards in the Full Analysis section used to scale up slightly on hover. It looked okay on desktop but felt janky on touch devices and made the layout shift in weird ways. We removed the scale effect entirely. Cards now stay static on hover — cleaner and more predictable.

Admin panel enhancements

We've added several new views to the internal admin panel:

These aren't user-facing, but they help us spot patterns, catch issues early, and make better decisions about what to build next.

Export improvements

PDF exports now include the domain name and analysis date in the filename (e.g., `website-analyzer-example-com-2026-04-18.pdf`) instead of a generic name. Another small thing, but it makes managing exported reports much easier.

JSON exports now include a `metadata` field with the analysis timestamp, analyzer version, and cache status. Useful if you're processing the data programmatically.

What's next

We're thinking about:

Historical tracking — showing how a site's score, tech stack, or security posture has changed over time. This would require storing multiple snapshots per domain.

Comparison mode — analyze two sites side-by-side and see differences in their tech stacks, scores, and configurations.

Public API — still the most-requested feature. We're working on rate limiting and authentication before opening it up.

Expanded technology detection — particularly for backend frameworks, databases, and serverless providers.

If you're using the tool and something feels off, or if there's a feature you need, the feedback link at the bottom of the results page goes directly to us. You can also email feedback@websiteanalyzer.dev.