DEV Community: Awais

A repeatable image export check before publishing a web page

Awais — Sun, 11 Oct 2026 14:42:38 +0000

An image can look fine in an editor and become unreadable in an article. The useful comparison is the exported file at the width where readers will see it.

This is a practical workflow for web builders preparing photos and screenshots. It proposes a repeatable method; it does not report a compression benchmark.

Disclosure: I am affiliated with TinyImage, HEIC to PNG, HEIC to JPEG and DR Checker. This article includes competing tools and was prepared with AI assistance. Product-page details were checked on 11 October 2026.

Start with the layout

Write down the content width before opening a compressor. A screenshot displayed in an 800-pixel article column has different requirements from a full-width photograph.

Keep the original privately. Crop a working copy to the useful subject, then create candidate sizes. Compare those candidates at the actual article width. If a screenshot's labels need zooming, a tighter crop or two separate screenshots may communicate more clearly than a larger download.

Choose an output for the content

For a photograph, start with JPEG and compare WebP or AVIF when the publishing stack supports them. For interface screenshots, start with PNG or a lossless alternative and inspect fine text. For an existing vector logo, consider retaining SVG.

The MDN image format guide explains the tradeoffs. There is no format that is smallest and most appropriate for every image.

If a CMS rejects a phone's HEIC file, conversion is a compatibility step. HEIC to JPEG offers a direct photographic output; HEIC to PNG offers a PNG intermediate for subsequent editing. Both describe browser-local conversion and omission of EXIF. Preserve the original if capture metadata matters.

Compare exports with the same dimensions

Use Squoosh for an interactive local comparison, your CMS's image pipeline, or a hosted tool such as TinyImage. Choose the processing model that fits the image and your workflow.

TinyImage documents 250 successful website conversions per month. Its API allowance is a separate one-time trial. Compression and conversion can use temporary server storage; consult its privacy policy before uploading sensitive media.

For a fair first comparison, keep dimensions and output format constant. If one output is half the width, the size difference cannot be attributed to compression alone. Quality slider values from different encoders also need not be equivalent.

Record actual file bytes. Then calculate:

savings_percent = 100 * (original_bytes - output_bytes) / original_bytes

Keep negative values. An export that grows is a useful observation, not a result to discard.

Give the browser appropriate candidates

Here is an illustrative example, not a tested production configuration. Generate the files and adapt the layout values before using it:

<img
  src="/images/workbench-800.jpg"
  srcset="/images/workbench-800.jpg 800w,
          /images/workbench-1600.jpg 1600w"
  sizes="(max-width: 840px) calc(100vw - 32px), 800px"
  width="1600"
  height="1000"
  alt="Woodworking tools arranged on a workbench"
>

The sizes value should match the CSS layout. The dimensions should match the actual aspect ratio. Check the final rendered page rather than assuming the CMS preserves the markup exactly.

Google's image guidance is a useful primary reference for discoverable image elements and descriptive context.

Keep a small evidence log

For each candidate, record source hash, date, tool, browser, output format, dimensions, quality setting, original bytes, output bytes and visual notes. Inspect at article width and at 100% pixel view. Look for halos, unreadable labels, changed colors and broken transparency.

If you time the process, define the start and end events and repeat the run. A single stopwatch result mixes too many variables to support a general claim that one service is faster.

Finally, open the published URL on a narrow screen and a desktop. Check the image, caption, alternative text and download behavior. The goal is a page readers can use comfortably, with measurements that another editor can reproduce.

The expanded Practical Image Workflows resource includes tool-limit tables, metadata considerations and a comparison protocol.

I Built a Free SEO Tool With One API and a Lot of Vibes: Here's Everything I Learned

Awais — Sun, 13 Sep 2026 18:36:00 +0000

I've spent years in SEO. And if there's one thing that has never stopped annoying me, it's this:

Simple SEO questions require way too many steps to answer.

You want to check a domain before pitching for a guest post or backlink. Sounds simple, right?

Not really. Here's what that "simple" check actually looks like:

Open one tool to check Domain Rating.
Open another tool (or tab) to check Domain Authority.
Open a third tool to check referring domains.
Manually look up the domain age.
Run a SERP check to see who's actually ranking.

Five tools. Five tabs. Five logins. For one decision: is this domain worth my time?

I got tired of tab-switching just to make a five-second judgment call. So I built DR Checker — a free tool that answers all of that in one place.

This post is the story of how I built it, what I learned building it fast with AI-assisted ("vibe") coding, and — more importantly — why the tool itself was never really the point.

The Real Problem Wasn't "I Need a DR Checker"

Here's something I want you to sit with for a second: the API is not the product.

Anyone with a credit card can subscribe to Ahrefs, Moz, or a dozen other SEO data providers. The data is available to almost anyone willing to pay for it. That's not a moat. That's a commodity.

What is scarce is this: knowing exactly which five steps a person goes through to solve a problem, and then ruthlessly cutting that down to one.

That's the actual insight behind DR Checker. I didn't set out to build "a domain rating tool." I set out to remove steps from a workflow I personally repeat dozens of times a week — vetting domains for backlink and guest post opportunities.

Key takeaway: if you're building a tool right now, stop asking "what can I build with this API?" Start asking "what am I doing manually, five times a day, that could be one click?"

Why I Used Vibe Coding (And Why It Actually Matters Here)

Before I get into what DR Checker does, I want to talk about how I built it — because this is the part that changed my thinking more than the tool itself did.

Historically, building even a small utility like this meant weeks of dev time. Backend setup. Frontend. API integration. Hosting. Deployment pipeline. By the time you ship, you've already sunk 40+ hours into something that might get zero traction.

Vibe coding flips that math entirely.

I built DR Checker on Vercel, using the Ahrefs API as the data backbone, and leaned on AI-assisted coding to write the plumbing — the domain input handling, the API calls, the UI to render the score cleanly. The first version wasn't fancy. It did exactly one thing:

Enter a domain
Get the Domain Rating

That's it. No accounts. No paywall. No unnecessary friction.

The shift here isn't "AI writes code faster." The real shift is in how you're allowed to think about product development:

Before: Think for weeks, plan the full feature set, then build.
Now: Build the smallest possible version in a day, put it in front of real use cases, and let usage tell you what to build next.

That second model is just a better way to build small, focused tools — regardless of who or what is writing the code.

What DR Checker Actually Does Today

The tool didn't stay a single-metric checker for long. Once real usage started, the gaps became obvious fast. Today, DR Checker is a bundled domain research tool that checks:

Domain Rating (DR) — via the Ahrefs API
Domain Authority (DA) — via Open PageRank
Domain Age — via RDAP lookups
Referring Domains — to gauge link profile strength
SERP Preview — to see how a domain's pages actually show up in search
Bulk domain checking — for anyone vetting a list of prospects instead of one at a time

Each one of those was added because it removed a specific extra tab someone doing link-building or guest-posting research would otherwise have to open.

This is the part most tool-builders skip: they ship the MVP, then keep adding features because features feel like progress. I added features because each one mapped to a real step in a real workflow I could point to.

The Math That Makes This Worth Using

Here's the part that actually gets people to switch tools: cost.

Subscribing to Ahrefs and Moz individually, just to get DR and DA on the same domain, can run you $200–$300 a month — before you've even looked at referring domains or run a single SERP check.

DR Checker bundles four of those metrics into one free lookup. For anyone doing outreach or link-building at volume, that's not a nice-to-have. That's a meaningful chunk of budget freed up every single month.

That's the pitch I lead with in every piece of content I write about the tool now, because it's the one thing that actually moves people from "interesting" to "I'm switching."

Where I Got It Wrong (And the Traffic Lesson That Followed)

I want to be honest about the part of this story that didn't go smoothly, because that's usually the more useful part.

After launch, I did the content work you'd expect — wrote comparison posts, built out a keyword-targeted blog, positioned DR Checker against the other "free domain checker" tools out there. Then I hit a stretch where traffic actually dropped.

When I went back into Ahrefs to figure out why, the keyword data told a clear story:

"domain rating checker" — 4,200 monthly searches, 56 difficulty, ~69,000 traffic potential. This was the real prize, and I was sitting at positions 14–22 for it — capturing maybe 50 visits a month against a 69K ceiling.
"domain age checker" — 4,000 monthly searches, 49 difficulty. Lower competition, faster potential win.
"bulk DR checker" — only ~50 searches a month. Useful as a feature to mention, not worth targeting as a standalone keyword.

The lesson here:

I had been treating my content strategy like I had five different tools to promote, instead of one dominant pillar with supporting posts underneath it. Scattering authority across a dozen loosely related keyword targets instead of building depth around one or two high-value terms is a mistake I see constantly in SEO — and I was making it myself.

The fix going forward is a tighter structure: a Tier 1 pillar built entirely around "domain rating checker" (the term with real volume and real traffic potential), a Tier 2 supporting cluster around "domain age checker" for the faster win, and everything else — the bulk checker, the SERP simulator — folded in as features and internal links rather than standalone keyword bets.

What I'd Tell Anyone Trying to Build a Small SEO Tool

If you're sitting on API access and wondering whether it's worth building something small around it, here's what I'd tell you, in order:

Don't start with the API. Start with your own repeated frustration. The tool that gets used is the one that removes a step you personally hate repeating.

Ship the one-metric version first. DR Checker's first version did one thing. That was enough to learn whether anyone cared.
Let usage — not your roadmap — decide the next feature. Every metric I added existed because I watched people (myself included) reach for a second or third tool right after using the first.

Price your tool against the stack it replaces, not against a single competitor. "$200–300/month saved" is a stronger hook than any feature comparison.

Pick one keyword to actually win before you spread across ten. Traffic potential means nothing if you're ranking at position 18 for it.
The Bigger Point

I'm not trying to build the next Ahrefs or Moz. That's not the goal, and it was never the goal.

The goal is smaller and, I think, more useful: find one annoying, repeated workflow, strip out the unnecessary steps, and ship it fast enough to find out if anyone else was annoyed by the same thing.

Vibe coding didn't hand me a business. It just removed the excuse to spend six weeks planning before I found out if the idea worked at all.

I'm still building more of these — small, focused tools around problems I run into myself while doing actual SEO work, not hypothetical ones. If you're an SEO or a builder sitting on API access and a recurring annoyance, that's usually all you need to get started.