DEV Community: Serhii Kalyna

I Benchmarked 17 Image Conversions on My Production Server. Some Results Were Not What I Expected.

Serhii Kalyna — Sat, 20 Jun 2026 06:01:01 +0000

I run Convertify, a free image converter built on Rust and libvips. Last week I decided to stop guessing about format performance and actually measure it. I took 50 real images (26 PNGs, 24 iPhone HEIC photos), ran 17 conversions through the production pipeline, and recorded every file size and encode time.

Some results confirmed what everyone says. Others did not.

The three results that surprised me

1. Converting HEIC to JPG makes files 14% bigger, not smaller.

This one hurt. "Convert iPhone photos to JPG" is probably the most common advice on the internet. But HEIC wraps the HEVC codec, which compresses roughly 2x better than JPEG. Going from a better codec to a worse one means the file grows. Every time.

If you actually want smaller iPhone photos: HEIC to WebP saves 43%, HEIC to AVIF saves 57%.

2. AVIF encodes 7x slower than WebP for 10% more compression.

AVIF Q63: 55 KB, 1.30s per image.
WebP Q80: 61 KB, 0.19s per image.

That is a 10% size difference for a 7x speed penalty. For a single hero image, nobody cares. For a batch pipeline processing thousands of product photos, that is the difference between 3 minutes and 21 minutes.

3. PNG at 600 DPI is smaller than PNG at 300 DPI when rasterizing PDFs.

This was the weirdest one. I was benchmarking PDF-to-image and noticed PNG output shrank from 2,221 KB at 300 DPI to 1,660 KB at 600 DPI. I spent an hour convinced I had a bug.

Turns out it is a real property of PNG encoding. Higher DPI renders smoother gradients between adjacent pixels, and PNG's prediction filters (Paeth, sub, up) compress smooth gradients dramatically better than the sharp edges you get at lower resolutions. Not a bug. Just PNG being PNG.

The quick reference table

Conversion	Size change	Speed
JPG to WebP Q80	-64%	0.19s
JPG to AVIF Q63	-68%	1.30s
PNG to WebP Q80	-92%	0.21s
PNG to JPG Q85	-86%	0.07s
HEIC to JPG Q85	+14%	1.90s
HEIC to WebP Q80	-43%	5.64s
HEIC to AVIF Q63	-57%	14.52s
WebP to JPG Q85	+60%	0.09s
AVIF to JPG Q85	+80%	0.15s

What I actually recommend

For most websites: WebP Q80. 64% smaller than JPG, fast to encode, universal browser support since 2020.

For maximum compression with no time pressure: AVIF Q63. 68% smaller than JPG but 7x slower to encode.

For iPhone photos: Do not convert to JPG. Go straight to WebP or AVIF. JPG is a downgrade in both efficiency and file size.

The full benchmark

The complete data with PDF rasterization benchmarks, DPI comparisons, and methodology is in the full benchmark post on Convertify. Every number was measured on June 18, 2026 on the production Rust + libvips server. No theoretical figures, no borrowed data.

Week 14 of building Convertify in public. Previous posts in the series cover the SSG migration, libvips segfaults, and why I stopped trusting my own landing page copy.

Building in public, week 13: the debt week nobody posts about

Serhii Kalyna — Sun, 14 Jun 2026 07:16:50 +0000

I'm building Convertify, a free image converter, in public over 52 weeks. It's a solo project on Rust + Axum + libvips with a Next.js frontend. This is week 13, and I want to write about it honestly because it was a week with no shiny new feature, and those weeks rarely get posts.

Here's what actually happened.

I chased a double-free instead of shipping

My "images to PDF" path had been crashing in production, intermittently, with a GObject assertion failure. Convert a few files, fine. Convert a few more, segfault. The worst kind of bug.

Root cause: a derived Clone on the libvips image type was doing a bitwise pointer copy of a C object without taking a reference. Two Rust values ended up owning one underlying GObject, and when both dropped, g_object_unref ran twice on the same thing. A textbook double-free, wearing a .clone() as a disguise.

// the bug
let copy = image.clone();   // copies the pointer, no g_object_ref

// the fix
let copy = ops::copy(&image)?;   // real new GObject with its own refcount

One line. A couple of evenings to be sure it was that line. I wrote the full story up as a separate dev.to article this week.

I fixed a UX dead-end I'd been ignoring

If you went over the 20 MB upload limit, the convert button disabled itself, and there was no obvious way out. You couldn't remove a single file from the list. People were quietly getting stuck.

So I rebuilt the file list: each file is a card with a remove button, there's a size-limit toast that fires when you cross the limit, and the dropzone goes red.

While refactoring the upload handler I also collapsed three separate file-handling paths (choose, drop, remove) into one gate. That killed a whole class of bugs where the three paths had drifted apart (drop wasn't updating the size map, re-selecting the same file silently did nothing, etc).

I audited my own content for honesty

This is the unglamorous one. I went through landing pages and removed claims that didn't match what the backend actually does, checking each against the real Rust code (metadata handling, compression details). I'd rather say less and be correct than pad pages with things that aren't true.

Funny side effect: an SEO audit I ran this week pointed at exactly this kind of honest, specific content as the thing that sets the site apart from templated competitors. The discipline turned out to be the moat.

The most useful thing I did wasn't code

I finally set up Bing Webmaster Tools. Took five minutes (you can import straight from Google Search Console).

It immediately showed me search intent Google had been hiding: around 25 different queries for "pdf to jpg at N dpi" (600, 300, 150), in multiple languages, where I'm already ranking on page one. People who need a specific print resolution. I had no idea that demand existed because Google's console never surfaced it. That's now the top candidate for next week's backend work.

Lesson: if you only watch Google, you're watching most of the market through one keyhole. Other search consoles are free and show you different things.

Numbers, honestly

Impressions and indexing are both at period highs (impressions peaked around 225/day this week). Clicks are still small and spiky, which is normal for a 3-month-old domain with almost no backlinks. Nothing regressed, despite a scary-looking week-over-week dip that turned out to be me comparing a 7-day peak against a 3-month total.

Threads is quietly my best referral source (real sessions every week), and ChatGPT keeps sending people too, which means I'm getting cited in LLM answers even though I haven't seen the AI crawlers hit me directly.

Next week is a real technical week

Backend debt: selectable TIFF compression, multipage TIFF, a CMYK path, and that DPI feature the Bing data justified. Plus refactoring my upload handler properly before I pile more on it, and turning my real benchmark data into a public study people can actually cite (which an audit suggested is a stronger link lever than guest posts).

No new converter pages. The lever this stretch is depth and correctness, not surface area.

If you're building something image-heavy, it's at convertifyapp.net. No account, files deleted 6 hours after conversion. Week 13 of 52 done.

The Rust binding compiled fine. then it started segfaulting in prod

Serhii Kalyna — Thu, 11 Jun 2026 07:59:39 +0000

I run a free image converter, its built on rust + axum + libvips. it had been happily running for months. then one feature, images-to-pdf, started falling over in production with this:

g_object_unref: assertion 'G_IS_OBJECT (object)' failed

and the fun part: only sometimes. convert a couple images, fine. convert a few more, boom. the non-deterministic kind of crash, which is the worst kind, because it makes you sit there wondering if you even understand the language you've been writing for years.

Turns out the bug was mine. the trigger was one tiny innocent .clone(). heres the whole thing because i'm pretty sure other people doing rust over a C lib will eventually step on the same rake.

"But rust is memory safe"

This is what messed with my head for a while. rust is supposed to stop exactly this. no double frees, no use after free, borrow checker has your back. so how am i double freeing anything at all?

One word makes all those guarantees quietly disappear: FFI.

Libvips is a C library built on GObject, and GObject does its own manual reference counting. the rust crate wraps those C objects in rust types. and the second a rust type is holding a raw pointer into C land, the borrow checker just... cant help you anymore. it sees a struct. it does not see that the struct is actually a handle to a refcounted thing living on the C heap. safety stops right at that line and nobody tells you.

The actual cause: a Clone that doesnt clone

Heres roughly what was blowing up. i was building a multi-page pdf and somewhere in the loop i cloned the image:

// the crash version
let copy = image.clone();
// ... use copy ...
// both `image` and `copy` drop here

VipsImage in the crate derives Clone. and a derived clone on a thing that holds a pointer does the obvious dumb thing: it copies the pointer. bit for bit. so now the same C object has two rust owners, and here is the kicker, nobody incremented the GObject refcount. libvips still thinks there is exactly one reference to that object.

Then rust does its job a little too well. both values go out of scope, Drop runs twice, and each drop calls g_object_unref on the same object. first unref takes the count to zero and frees it. second unref runs on already-freed memory, libvips checks G_IS_OBJECT, the assertion blows, and depending on timing you either get a glib critical or a clean segfault.

So. a textbook double free. wearing a .clone() as a disguise. the "random" part was just the allocator deciding whether the freed slot had been reused yet or not.

A correct clone here would have to call g_object_ref so each owner actually accounts for its own reference. the derived one doesnt. so calling it Clone is generous. its an aliased pointer with two destructors aimed at it.

The fix

Stopped cloning the handle, started asking libvips for a real new object instead:

// the fixed version
let copy = ops::copy(&image)?;

ops::copy runs an actual libvips copy and gives you back a fresh GObject with its own refcount. now each rust value owns its own distinct C object, each drop unrefs its own thing, nothing gets freed twice. crash gone.

one line. took me a couple evenings to be sure it was that line, which is always how these go.

a few more libvips + rust landmines from the same evening

since i was already in there bleeding, a few neighbours showed up:

JpegsaveBufferOptions::default() hands you a busted keep value. the default came out as something like keep | 32, which libvips just rejects with a glib critical. fix was to stop trusting the default and set it myself:

keep: ops::ForeignKeep::None,

the operation cache was a second way to die. libvips caches operations by default, and under load that cache plus the lifecycle mess above gave me another crash, this time inside cache trimming. i turned the operation cache off entirely while getting things stable, which killed that path. just know it exists and that its global state.

VipsApp::new(name, false) is not what it looks like. that second bool is detect_leak, not some concurrency switch, which is exactly what i had lazily assumed it was. read the signature, dont pattern-match on vibes.

bumping the crate did not save me. i tried going from 1.7.x up to 2.1.0 hoping the lifecycle stuff was just fixed upstream. nope, changed nothing for this. reverted to 1.7.6 and fixed it properly on my end.

what i actually took from this

a derived Clone on a type that wraps a foreign, refcounted resource is a trap. #[derive(Clone)] assumes a clone is a cheap copy-the-fields job. for a GObject handle thats the exact wrong assumption: copy the pointer without taking a ref and you've got two owners, one refcount, and rust's own Drop happily freeing it twice.

so the rule i walked out with: when a rust type owns a C resource that has its own lifecycle, treat Clone and Drop as suspects, not freebies. need another handle? reach for the library's own copy/ref function before you derive Clone and hope.

if you've hit something like this with libvips bindings or any GObject FFI, i'd genuinely love to hear how you dealt with it, the comments are the fun part. the tool this was all holding up is at convertifyapp.net if you want a look. no account, files get deleted after.

Week 12 building Convertify in public (free image converter, Rust + libvips + Next.js SSG)

Serhii Kalyna — Sun, 07 Jun 2026 16:47:13 +0000

What I shipped:

Two new tools live: Resize Image and Crop Image, both on libvips natively
A long-form guide, "How to Compress Images Without Losing Quality," written to feed my compress JPG/PNG/WebP pages with real internal links and real benchmarks from 24 of my own iPhone photos
A site-wide "Image Tools" block (inline section + footer column) so every page now cross-links to the new tools
Squashed a nasty non-deterministic segfault in the libvips Rust bindings. It was a double-free: the binding derives Clone over the raw image pointer, so cloning copied the pointer without bumping the refcount and Drop freed the same object twice. Replaced the clone with an explicit copy, disabled the op cache, and the crashes plus the G_IS_OBJECT warnings are gone. Happy to write up the war story if anyone wants it.

The numbers (last 7 days):

Clicks doubled, up 100% week over week. Still small in absolute terms, but real and trending the right way for the first time in weeks.
Impressions also up 100%, as the new pages finished getting indexed.
Average position is creeping up, into the mid-40s on the most recent day, from around 51 the week before.
A brand-new long-tail query, "sony hif file to jpg converter," is already sitting at position 6. That is exactly the kind of low-competition query I am betting the whole strategy on.

The honest read:
Clicks and impressions both doubled, which is great, but the absolute numbers are still small and capped by domain authority. I have around 15 referring domains; the big converters have thousands. On competitive terms like "avif to png" (KD 42) I cannot rank without backlinks, and that is a months-long game. So the play stays low-KD long-tail: pages that can reach the top 10 even at low DR. That position-6 result on a niche query is the early proof it works.

Next week:

Concentrate internal links on the low-KD pages that already have impressions
Start background removal (rembg sidecar) research
Keep backlink outreach slow and quality-first

convertifyapp.net

Building in public, week 11: 143 pages indexed, a TinyPNG alternative in Rust

Serhii Kalyna — Sun, 31 May 2026 11:15:26 +0000

Week 11 of building Convertify a free image converter (Rust + Axum + libvips, Next.js SSG frontend) in public. Solo, no funding, 52-week run.

Here's the honest headline: **indexing jumped from 100 to 143 pages, I shipped image compression in Rust, and my clicks are still stuck.

What I shipped

1. Internal linking between blog and converter (the debt I kept dodging)

I launched a blog in week 10 (3 posts, full schema, the works) and immediately got 18 views/week on one post. Great except that traffic had nowhere to go. The blog talked about HEIC; it never pointed at the page that actually converts HEIC.

So week 11 I built a RelatedArticle component and wired it both ways:

Blog -> converter: inline contextual links in the body + a CTA block at the end.
Converter -> blog: a "Learn more" card driven by a related_blog_slug column on each page.

The component went through a small evolution. First version showed one article. Then I made it multi-article it pulls 2–3 related posts, matches them by topic via slug, caps at 3, and (the part that bit me) guards against the literal string "NULL" sneaking in from a missing DB value. Nothing fancy, but it closes the loop: informational traffic can finally flow to the transactional pages.

2. Image compression a free TinyPNG alternative, in Rust.

This was the fun one. TinyPNG does ~3M visits/month. That demand is enormous and I was leaving it on the table. libvips already gives me everything I need, so the backend was fast to stand up:

JPEG -> mozjpeg. libvips can hand JPEG encoding to mozjpeg, which does trellis quantization and smarter Huffman tables. Same visual quality, meaningfully smaller files than baseline libjpeg.
PNG -> imagequant. This is the same lossy-PNG approach pngquant (and TinyPNG) use: quantize a 24-bit PNG down to an optimized palette. Huge size drops on PNGs with limited color, transparency preserved.

The UX is a quality slider (1-100%) and a before/after size readout, so you actually see the reduction. I shipped three landing pages /compress-jpg, /compress-png, /compress-webp positioned as the free alternative.

The interesting signal: Compress JPG Free pulled 24 views in its first week, landing straight in my top pages. Different user intent than conversion (people converting a format vs people shrinking a file), and it showed up immediately. That alone made the cluster worth it.

3. Blog post #4

"Why HEIC Files Won't Open" published, 8 FAQs, FAQ schema embedded in the BlogPosting. Continuing the content momentum and feeding the new internal-linking machine.

Also did a cannibalization audit across blog + landing pages. Came back clean: intent is cleanly split (blog = informational, landing = transactional), so they're not fighting each other in search.

The numbers

Google Search Console (3 months):

Indexed: 100 -> 143 (+43, second-biggest jump ever)
Not indexed: 65 -> 39
Avg position: 40 -> 39.5

Google Analytics (7 days): 31 active users (+29%), 24 new (+33%), 52 sessions (+11%).

Traffic sources had a surprise: l.threads.com sent 13 sessions in a week Threads quietly became a real referrer. chatgpt.com has been a steady trickle for over a month now too (LLMs citing the blog posts).

Housekeeping wins

Cleared a stack of small debts that were quietly rotting: fixed the 404 source (broken internal links), cleared the redirect errors flagged in GSC, and consolidated my project docs into a single source-of-truth file instead of three drifting documents.

Next week (12)

Two new tools that are low-effort / high-ROI: resize + crop and background removal.
A compression-focused blog post to feed the new cluster.
The real work: on-page pushes on my top-impression pages to finally break something into the top 20.

If you've shipped a programmatic-SEO site and watched impressions climb while clicks flatlined I'd genuinely like to hear how (or whether) you broke out of it. That's the wall I'm at.

Convertify is built with Rust + libvips + Next.js. Following along week by week.

Building Image Compression in Rust with libvips Real Benchmarks, Real Tradeoffs

Serhii Kalyna — Fri, 29 May 2026 13:00:32 +0000

I've been building Convertify a free image converter for 11 weeks now. Last week I added compression support (JPG, PNG, WebP) using Rust + libvips. Here's what I learned, with actual numbers.

The Stack

Backend: Rust + Axum
Image processing: libvips 8.15.1 via the libvips crate
JPEG encoder: libjpeg (bundled with libvips)
PNG quantization: imagequant (same algorithm as pngquant / TinyPNG)
PNG parser: libspng (faster than libpng)

One thing worth knowing upfront: libvips does not include mozjpeg by default. You get standard libjpeg. I'll come back to why this matters.

How the API Works

The compression endpoint is the same /api/upload used for conversion — just pass format_to=jpg (or png, webp) with a quality parameter (1–100):

curl -X POST https://convertifyapp.net/api/upload \
  -F "files=@photo.jpg" \
  -F "format_to=jpg" \
  -F "quality=80"

On the Rust side, quality flows into libvips save options via build_output_path, which appends [Q=N] to the output filename — libvips picks it up automatically:

fn build_output_path(base: &str, format: &str, quality: Option<u32>) -> String {
    match (format, quality) {
        ("jpg" | "jpeg" | "webp", Some(q)) => format!("{}[Q={}]", base, q),
        ("png", Some(q)) => format!("{}[Q={}]", base, q),
        _ => base.to_string(),
    }
}

Clean. No separate code path for compression vs conversion.

The Benchmarks

Test image: 1920×1080 synthetic photo, 1.5 MB original JPG (Q=95 source).

JPG → JPG (re-compression)

Quality	Output size	Saved
Q=90	1,172 KB	22.7%
Q=80	890 KB	41.3%
Q=70	737 KB	51.4%
Q=60	627 KB	58.6%
Q=50	542 KB	64.2%

PNG → PNG (imagequant lossy)

Test image: 1024×768, 678 KB original PNG.

Quality	Output size	Saved
Q=90	486 KB	29.8%
Q=80	441 KB	36.2%
Q=70	396 KB	42.7%
Q=60	377 KB	45.5%
Q=50	348 KB	49.7%

JPG → WebP (format switch as compression)

Quality	Output size	Saved vs original JPG
Q=90	1,120 KB	26.1%
Q=80	872 KB	42.5%
Q=70	760 KB	49.9%

The Surprising Part

WebP at Q=80 saves almost the same as JPG at Q=80 — 42.5% vs 41.3%. Not the dramatic 2× improvement you'd expect from the marketing.

Why? On already-complex photographic content (lots of high-frequency detail), the gap between WebP and JPEG narrows significantly. WebP's advantage is most visible on graphics, flat colors, and images with transparency.

The other surprise: if the source JPG is already compressed at Q=70–75 (common for web photos), re-compressing to the same format gives you almost nothing. You're fighting the JPEG DCT artifacts that are already baked in. This is where converting to WebP actually helps different codec, fresh encode.

Why Not mozjpeg?

mozjpeg typically gives 10–15% better compression than libjpeg at the same quality level. To use it with libvips you need to compile libvips from source with --with-mozjpeg. On Ubuntu:

# Not trivial requires building mozjpeg first
git clone https://github.com/mozilla/mozjpeg.git
cd mozjpeg && cmake -G"Unix Makefiles" && make install

# Then rebuild libvips pointing at mozjpeg
./configure --with-jpeg-includes=/opt/mozjpeg/include \
            --with-jpeg-libraries=/opt/mozjpeg/lib

For a production VPS running PM2 + Caddy with system libvips, the operational complexity wasn't worth it. libjpeg at Q=80 already delivers 40%+ savings which covers 90% of use cases.

PNG: imagequant is the real hero

The selected quantisation package: imagequant line in vips --vips-config is significant. This is the same engine behind pngquant and TinyPNG's PNG compression. It works by reducing the color palette to 256 colors (lossy) while preserving perceptual quality.

The Q parameter maps to imagequant's quality range. Q=80 gives ~36% savings with barely visible quality loss on photographic PNGs. For logos and flat graphics the savings are even better since there are fewer unique colors to begin with.

The Sweet Spot

After running these benchmarks, the defaults I settled on for the UI:

JPG: Q=82 (hits the knee of the quality/size curve, ~40% savings)
PNG: Q=80 (36% savings, imagequant artifacts not visible at normal viewing)
WebP: Q=80 (consistent with JPG behavior)

These are close to what Squoosh and Lighthouse recommend. The difference is users can move the slider themselves the before/after size display makes the tradeoff tangible.

What's Next

The compression cluster is live at convertifyapp.net/compress/jpg. Next up: RAW format support (CR2/NEF) for photographers, and eventually mozjpeg as an opt-in for maximum compression.

If you're building something similar libvips in Rust is genuinely great. The libvips crate is well-maintained, the C library is fast (faster than ImageMagick by a wide margin), and imagequant bundled for PNG is a nice bonus.

Building in public week 11 of 52. Follow along if you're into indie dev + Rust + SEO experiments.

Building Convertify in Public Week 10: PDF Cluster + Blog Launch

Serhii Kalyna — Sun, 24 May 2026 18:17:16 +0000

Week 10 of building Convertify (convertifyapp.net/pdf-to-jpg)
in public.

What I shipped

PDF cluster 4 new pages:

/heic-to-pdf (33,100 searches/mo, KD 36)
/pdf-to-png (74,000 searches/mo, KD 42)
/pdf-to-jpg (90,500 searches/mo, KD 86)
/png-to-pdf (3,600 searches/mo, KD 43)

Backend (poppler) was already there from the
images-to-pdf feature — pure content work.

Blog 0 to 3 posts in one week:

"What Are HEIC Files?" KD 20, lowest KD across all 1,192 keywords in my strategy
"How to Convert PDF to JPG 5 Methods"
"AVIF vs WebP vs HEIC 2026"

Full SEO infrastructure from day one: BlogPosting
schema, BreadcrumbList, OG images, canonical,
sitemap updated.

Numbers

Metric	T9	T10
Indexed pages	75	100 (+25) 🔥
Impressions (3mo)	509	520
Avg position	40.1	40

Unexpected: chatgpt.com sent 13 sessions this
month. Blog posts are getting picked up by AI.

First blog post got 18 views in week 1 small
but it's a start.

What I missed

Internal linking blog <-> converter pages (P0 for next week without this, blog traffic doesn't convert)
Showoff Saturday post deleted again

Next week

Internal linking blog <-> converter pages
Blog post #3

Week 1–10 recap: 0 -> 100 indexed pages,
0 -> 520 impressions, 0 -> 3 blog posts.

Convertify

Why I Finally Added a Blog to My Converter Tool

Serhii Kalyna — Wed, 20 May 2026 14:32:11 +0000

Two months in, 75 pages indexed, zero blog posts. That was the plan — ship converter pages, get them indexed, figure out the informational content later.

Then one keyword changed my mind.

The number that changed things

I've been tracking keywords for Convertify across image conversion queries. Most sit between KD 35 and 86 competitive, slow to move, need real backlinks to crack.

While reviewing the list this week I noticed "what are heic files" 3,600 searches per month, KD 20.

For context:

heic to jpg -> KD 67
convert png to pdf -> KD 43
avif vs webp -> KD 35
what are heic files -> KD 20

The SERP is surprisingly weak for a query with this volume. Most results are generic explainers rather than tools solving the problem directly. No converter tool has a proper dedicated page ranking for it.

That felt like the right moment to start.

The logic behind it

The user searching "what are heic files" is usually an iPhone owner who just tried to send a photo somewhere and got confused. They're a couple of clicks away from needing a converter.

The path I'm betting on:

Land on /blog/what-are-heic-files
Understand that HEIC isn't universally supported
Follow an internal link to /heic-to-jpg or /heic-to-pdf
Convert

Informational content converts when the internal linking is tight. A blog post with no clear path to the tool is just a vanity page. The goal here isn't content for content's sake — it's closing the loop between someone learning about a format and actually solving their problem.

What I built this week

The main work was a PDF cluster three new converter pages plus the blog infrastructure.

HEIC -> PDF turned out to be more interesting than expected. PDF has no HEVCDecode filter the spec only defines DCTDecode (JPEG), FlateDecode, and JPXDecode. That means HEIC always requires a transcode to JPEG before embedding. JPG -> PDF by contrast is literally lossless bytes go in untouched. I wrote the full explanation in the page content because this is exactly the kind of depth that thin competitor pages skip.

PDF -> PNG uses pdftocairo for rendering. pdftocairo runs about 3–4x faster than ImageMagick at 300 DPI and produces noticeably better anti-aliasing on text. libvips has a pdfload wrapper that also calls poppler under the hood, so the pipeline stays consistent.

For the blog itself I went with PostgreSQL instead of MDX files. Every new MDX post requires a deploy for a solo developer writing irregularly, that friction compounds quickly. The blog_posts table uses the same JSONB content structure I already use for landing pages, so the renderer was already built. Adding the blog was mostly schema and new routes.

Where things stand

Indexed URLs: 75 -> 82 (target after new pages)
Impressions last 3 months: 509
Blog posts live: 0 -> 2 (target by end of week)

The cross-links I added in week 9 across 64 converter pages should start appearing in GSC by Thursday. Right now I'm prioritizing site structure and internal linking before investing time into backlink outreach. Structural fixes take a few crawl cycles to surface each one is slow feedback, but it compounds.

Why this feels different

The interesting part about SEO at this stage isn't traffic yet it's feedback loops.

You ship a structural change, wait through a few crawl cycles, and slowly learn which assumptions were right. Most changes take weeks to show up. You're essentially running experiments with a 3-week delay on results.

The KD 20 HEIC query is the first time the feedback loop feels short enough to actually compound. If a new domain can rank for KD 20 in a reasonable timeframe, that's a signal worth building on.

Next check is Thursday's GSC analysis.

Convertify is a free image converter built with Rust + libvips and Next.js SSG.
Week 1–10 archive: https://dev.to/serhii_kalyna_730b636889c

Building in public, week 9: cross-links, positions going up, and 246 new dev.to followers in 7 days

Serhii Kalyna — Sun, 17 May 2026 05:55:34 +0000

tl;dr: Week 9 was infrastructure week. Closed the biggest SEO gap internal cross-links on 100% of pages. Average position improved for the first time in a month.

The numbers

Metric	Week 8	Week 9
Indexed URLs	72	75
Impressions (3 months)	463	509
Avg. position	43.8	40.1
Cross-links coverage	40/64	64/64
dev.to followers	156	402

GA last 7 days: 36 active users (+56.5%), 61 sessions (+38.6%). Traffic sources: Google organic is now the consistent #1.

What I actually did

Cross-links: 40 -> 64/64 ✅

This was the main P0 for the week. Convertify has 64 landing pages (62 format-pair conversions + home + images-to-pdf). In week 8, only 40 had contextual cross-links inline <a href> inside the body text pointing to related conversions.

I added 2-3 cross-links per page across the remaining 24 pages, batched over Monday–Wednesday. The links are semantic, not just alphabetical a page about AVIF->JPG links to AVIF->PNG and JPG->AVIF, not to BMP->TIFF.

The effect on positions isn't instant. Internal links take 1-2 crawl cycles to register. But average position went from 43.8 to 40.1 the first improvement in a month. Expecting more in T10–T11 as Googlebot re-crawls.

Semrush on-page fixes

Four pages got H1/title/meta updates based on Semrush priority scores:

avif-to-webp priority 3.35 (highest), added missing semantic terms
avif-to-png priority 0.78, H1 and title now contain "avif to png" exactly
heif-to-jpg priority 0.48, body + H1 + title now include "heif image converter"
avif-to-jpg priority 0.19, title updated to match "online convert avif to jpg"

Also simplified readability on 4 pages (Semrush flagged them as "difficult to read") shorter sentences, fewer compound clauses.

Content gaps closed

4 pages brought from 5 to 6+ sections, 2 pages got FAQ expanded from 6 to 8 questions. Home page schema_faq synced (was 4 questions in JSON-LD, 7 in the DB now 7 everywhere).

Also added a comparison table to /images-to-pdf the only page that was missing one.

Google confirmed 35 canonical fixes

Got an email from Google Search Console team confirming that the canonical issues I fixed in T8 (35 pages were flagged as "Alternate page with proper canonical tag") have been resolved. The "Variant page with canonical tag" count dropped to 0.

SaaSworthy listing

Added Convertify to SaaSworthy full listing (Basic Details + Media + Pricing + FAQs). Free tier was actually free, no "Talk to Us" required.

Created an account, verified the domain via meta tag, published 3 pins:

HEIC->JPG: "Convert HEIC to JPG Free Online No Signup"
AVIF->PNG: "Convert AVIF to PNG Free Preserve Transparency"
PNG->WebP: "Convert PNG to WebP Free 30% Smaller Files"

Not expecting traffic from this. Image search visibility is the goal AVIF and WebP pages might surface in Pinterest search for people looking for format examples.

What I deliberately didn't do

Researched whether adding "Last updated: May 2026" to pages would help CTR. Found two case studies showing it hurt CTR by 13-22% on tool pages. Probably because it signals the tool is old and was manually touched, not that it's actively maintained. Skipped it.

The unexpected thing: dev.to followers +246 in one week

I publish weekly "Building in public" posts on dev.to + a technical article each week. Week 9 posts:

"Building in public, week 8: impressions exploded 71% and I think I know why"
"AVIF encoding speed".

The AVIF article is the one that seems to have triggered the follower spike. It's pure technical content benchmarks comparing AVIF encoding speed at different quality settings across formats. No promotion, no "check out my tool." Just data.

My theory: dev.to surfaces content in the weekly digest or the tag feeds, and technical posts about specific formats get picked up by people in the web performance / image optimization community. The followers are probably devs who bookmarked the article and followed for future posts.

What's not working

Clicks aren't moving. The pages are showing up in Google avif-to-png has 85 impressions, avif-to-jpg has 66, png-to-webp has 59. But average position is still ~40. Need to be in top 20 for these before clicks appear. The on-page and cross-link work is aimed at exactly this.

Plan for week 10

Keyword targeting on top pages: avif-to-png, avif-to-jpg, png-to-webp are the three pages with the most impressions. These need to move from position ~40 to position ~20. That means: content depth, more FAQ, better semantic coverage, maybe longer-form sections.

The honest take

Cross-links: was at 62.5% coverage, now 100%
Content: 0 pages below minimum threshold
Schema: all mismatches resolved

The position improvement (43.8 -> 40.1) is the first concrete signal that the on-page work is landing. 509 impressions.
Real clicks need top-20 positions. That's the only thing that matters in T10.

Convertify is a free image converter built with Rust + libvips and Next.js SSG. convertifyapp.net

Week 1–9 archive: dev.to/serhiizahornyi

AVIF encoding speed — the numbers nobody talks about

Serhii Kalyna — Thu, 14 May 2026 16:16:27 +0000

Everyone talks about how small AVIF files are.

Almost nobody talks about what it costs to generate them in production.

I run a free image converter built on Rust + libvips. After processing thousands of conversions, here are the numbers that changed how I think about format choice.

The compression story you already know

AVIF beats WebP on file size. For photos and gradients:

AVIF saves ~50% vs JPEG (median across 600 photos)
WebP saves ~31% vs JPEG
At the same DSSIM score, AVIF produces files ~50% smaller than WebP

Real and impressive. But that's only half the equation.

The encoding cost nobody talks about

Here's what actually happens when you encode with libaom (the default AVIF encoder):

Format	Encoding time (1080p)	Peak CPU	Peak RAM
WebP	~90ms	~20%	~200MB
AVIF (libaom, default settings)	1–4 seconds	~400% (4 cores)	~2.5GB
AVIF (maximum quality)	up to 48 seconds	-	-

In my tests, AVIF encoding with libaom was up to 47× slower than WebP at comparable quality settings. Peak memory usage during a single 4000px AVIF conversion reached ~2.5GB in Sharp/libvips using libaom. WebP used ~200MB for the same image.

The memory usage surprised me most. For a service handling concurrent batch uploads, that's not a benchmark number - it's a capacity planning problem.

AVIF optimizes bandwidth. WebP optimizes compute.

The `effort` parameter an oversimplification

If you use Sharp, you've probably assumed: higher effort = smaller files.

In practice, it's not that simple.

quality is the primary driver of file size. effort controls how much time the encoder spends searching for better compression decisions. Depending on the image, higher effort can slightly reduce or even increase output size. The effect is unpredictable and usually marginal.

This is documented behavior in Sharp's issue tracker (#3418): at fixed quality, increasing effort sometimes produces larger files.

Practical starting point for AVIF in Sharp:

sharp(input).avif({ quality: 72, effort: 5 }).toBuffer()

effort: 5-6 hits a reasonable balance. Going to effort: 9 adds seconds of encoding for marginal and unpredictable gains.

When to use which format

Scenario	Best format
User uploads processed on-the-fly	WebP
Static assets, pre-generated at build	AVIF
Real-time transforms	WebP
Maximum compression for photos	AVIF
Low-memory servers	WebP
Screenshots, UI, flat graphics	WebP
Photography, gradients, textures	AVIF

The rule I follow: AVIF for static, WebP for dynamic.

A 4-second encoding time is fine in a CI pipeline. It's not fine when a user is waiting for their converted file.

What this looks like in a converter pipeline

In my converter pipeline, the challenge with AVIF isn't throughput it's memory spikes under concurrent load. If multiple users upload large images simultaneously, AVIF jobs can spike memory hard across all cores.

Current approach:

Concurrency limits on AVIF jobs
Default effort: 4 for interactive conversions fast enough for real-time use
SVT-AV1 encoder is worth watching: roughly 2× faster than libaom, 5× faster than rav1e at comparable quality

Browser support

Effectively solved:

WebP: ~95.6% global support (Safari 14+, all modern browsers)
AVIF: ~94.3% global support (Safari 16.4+, Chrome 85+, Firefox 93+)

The standard fallback pattern still makes sense:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

The actual takeaway

"Better compression" and "better for your use case" aren't the same thing.

AVIF is technically superior for compression. But if you're encoding on-the-fly, the encoding overhead is a real operational cost not a benchmark footnote.

WebP is fast, lightweight, and produces files dramatically smaller than JPEG. It's not a consolation prize.

The best setup: pre-generate AVIF for static assets, encode WebP dynamically, serve both via <picture> or CDN content negotiation.

Building Convertify a free image converter powered by Rust + libvips. Week 9 of building in public.

Sources: Sharp GitHub issues #2597, #3418 · libheif AVIF Encoder Benchmark · SpeedVitals WebP vs AVIF · W3Techs image format statistics (May 2026) · Can I Use

Building in public, week 8: impressions exploded 71% and I think I know why

Serhii Kalyna — Sun, 10 May 2026 12:21:24 +0000

So this week something actually happened.

I've been building Convertify - a free image converter (Rust + libvips backend, Next.js frontend) - for about 2 months now. Writing content, fixing schema, submitting to directories, watching Google mostly ignore me.

This week the numbers moved.

The numbers

Google Search Console, 3-month view:

Impressions: 271 -> 463 (+71%)
Indexed pages: 59 -> 72 (+13)
External links: 40 -> 65 (+25)
Average position: 40.8 -> 43.8 (worse, but I'll explain)

That impressions jump is the biggest I've ever had.

What I think caused it

I don't think it was one thing.

Week 7 I updated 19 pages - added content sections, cross-links, fixed a schema bug where 189 FAQ entries were missing from JSON-LD.

Week 8 I did Semrush-driven fixes - put target keywords in H1s and titles, simplified sentences for readability, added semantic terms that competitors use but I wasn't. Also brought 16 pages up to 8+ FAQ each.

My theory is Google re-crawled the batch of updated pages and suddenly saw: "oh wait, these pages actually have real content now, not just a converter widget and two paragraphs."

The position thing

Average position went from 40.8 to 43.8 which looks bad. But 13 new pages got indexed this week, and they all start at positions 50-80. That drags the average down even though the older pages are actually climbing.

One page - jpg-to-webp - is at position 5.8 with 39 impressions. Position 5.8! That's basically page one. Zero clicks though. Working on the title/description to fix CTR.

What I built this week

Shipped batch image-to-PDF. You drop up to 10 images, pick page size (A4/Letter) and orientation, get one combined PDF. Built the PDF from raw bytes in Rust — no PDF library, just manually constructing xref tables and DCTDecode streams. Was it overkill? Probably. Was it fun? Absolutely.

Also refactored the entire Rust backend - split a 1200-line main.rs into proper modules (db, errors, image, notification, path, pdf). Should've done this weeks ago.

Backlinks update

Got on StackShare (DR ~89) and submitted to Capterra (DR ~91, pending review). Capterra was interesting - one submission potentially gets you on Capterra + Software Advice + GetApp, all three owned by Gartner.

Tried a few other directories from my backlink plan. Turns out FeedMyApp is dead (domain expired in 2022), Go2Web20 is dead, VentureBeat Profiles doesn't exist as a free thing anymore, and BetaList wants $39 minimum. So that saved me some future time at least.

Organic search is now #1 traffic source

This is the thing I'm most excited about. search.google.com has been the top traffic source for two weeks straight now. It's small numbers but the trend is clear.

The new /images-to-pdf page immediately became the #2 most viewed page on the site. Google picked it up fast.

What's next (week 9)

Biggest gap right now: 24 out of 64 pages have no cross-links in their body text. Plan is to add 2-3 natural cross-links per page across all 24 this week.

Also rewriting titles and meta descriptions for pages that are ranking but not getting clicks.

If you want to try it: convertifyapp.net. 40+ format pairs, batch conversion, image-to-PDF. Free, no signup.

Previous weeks: week 7 | week 6

From 0 to 72 indexed pages in 2 months: what Google actually does with new sites

Serhii Kalyna — Fri, 08 May 2026 19:57:15 +0000

I've been building Convertify — a free image converter in Rust + Next.js — for about 2 months. Here's where I am in GSC right now:

72 indexed pages
Average position: 40.8
Impressions: ~90/day
Clicks: basically 1

Not glamorous. But I spent time researching what's actually happening under the hood, and it changed how I think about the whole thing.

The "Google Sandbox" thing

Everyone talks about it. New site, no traffic, must be the sandbox right?

John Mueller said it directly in 2019: "There is no sandbox." Google doesn't penalize new sites — it just hasn't collected enough trust signals yet. There's a difference.

What actually happens is closer to this timeline:

Week 1: pages get crawled and indexed
Weeks 2–6: Google tests your pages on low-volume queries
Month 2–3: first stable positions for long-tail keywords
Month 4–6: rankings start to stabilize
Month 6–12: meaningful traffic growth

I'm at month 2. Right on schedule for "still basically nothing."

What actually moved the needle for me

A few things that made a real difference early:

Static site generation. I migrated from a Vite React SPA to Next.js SSG specifically because Google wasn't indexing my pages. Dynamic JS rendering was killing crawlability. After the migration: 186 static pages, all indexable. Impressions jumped within 2 weeks.

Internal linking. Added RelatedConversions component — every page links to 10-14 related conversion pages. Before this, new pages were getting zero impressions. After: slow but steady crawl pickup.

FAQ schema. Every landing page has FAQPage JSON-LD with 8-10 real questions. Not for rich snippets (those don't show for this type) — for entity clarity and content depth signals.

Content depth over breadth. Instead of 5 shallow pages, I focused on making each conversion page actually useful — real technical comparisons, format history, use cases. Some pages now have 10+ sections.

What didn't work (yet)

Backlinks. I spent time on directory submissions, Reddit posts, forum comments. Honest assessment: the directories that matter have 2-4 month queues. The "best image converter" articles are written by competitors. Forum comments get removed.

The only backlink strategy that feels real right now is writing content that people actually want to link to. Which is why I'm writing this.

CTR is also rough — 1 click total at position 40. That's expected. You can't get clicks from page 4. The only fix is ranking higher, which takes time.

What I'm watching now

GSC shows a spike in impressions at end of April — new pages entering the index. Then a drop. Mueller warned about this: "a site may get a spike, then return to normal — that's when you need patience."

I'm in the patience phase.

Month 4-6 is supposedly when things stabilize. I'll report back.

The honest summary

If you launched a site recently and have basically no traffic — you're probably fine. Google isn't punishing you. It's just waiting to see if you're serious.

The things that seem to matter most in the first 3 months: static rendering, internal linking, content depth, and schema markup. Not backlinks. Not social media. Just making the site technically solid and giving Google something worth indexing.

We'll see if that holds at month 6.

Building Convertify in public — free image converter, Rust + libvips backend, Next.js SSG. Week 8 of the build.

DEV Community: Serhii Kalyna

I Benchmarked 17 Image Conversions on My Production Server. Some Results Were Not What I Expected.

The three results that surprised me

The quick reference table

What I actually recommend

The full benchmark

Building in public, week 13: the debt week nobody posts about

I chased a double-free instead of shipping

I fixed a UX dead-end I'd been ignoring

I audited my own content for honesty

The most useful thing I did wasn't code

Numbers, honestly

Next week is a real technical week

The Rust binding compiled fine. then it started segfaulting in prod

"But rust is memory safe"

The actual cause: a Clone that doesnt clone

The fix

a few more libvips + rust landmines from the same evening

what i actually took from this

Week 12 building Convertify in public (free image converter, Rust + libvips + Next.js SSG)

Building in public, week 11: 143 pages indexed, a TinyPNG alternative in Rust

What I shipped

1. Internal linking between blog and converter (the debt I kept dodging)

2. Image compression a free TinyPNG alternative, in Rust.

3. Blog post #4

The numbers

Housekeeping wins

Next week (12)

Building Image Compression in Rust with libvips Real Benchmarks, Real Tradeoffs

The Stack

How the API Works

The Benchmarks

JPG → JPG (re-compression)

PNG → PNG (imagequant lossy)

JPG → WebP (format switch as compression)

The Surprising Part

Why Not mozjpeg?

PNG: imagequant is the real hero

The Sweet Spot

What's Next

Building Convertify in Public Week 10: PDF Cluster + Blog Launch

What I shipped

Numbers

What I missed

Next week

Why I Finally Added a Blog to My Converter Tool

The number that changed things

The logic behind it

What I built this week

Where things stand

Why this feels different

Building in public, week 9: cross-links, positions going up, and 246 new dev.to followers in 7 days

The numbers

What I actually did

Cross-links: 40 -> 64/64 ✅

Semrush on-page fixes

Content gaps closed

Google confirmed 35 canonical fixes

SaaSworthy listing

Pinterest

What I deliberately didn't do

The unexpected thing: dev.to followers +246 in one week

What's not working

Plan for week 10

The honest take

AVIF encoding speed — the numbers nobody talks about

The compression story you already know

The encoding cost nobody talks about

The effort parameter an oversimplification

When to use which format

What this looks like in a converter pipeline

Browser support

The actual takeaway

Building in public, week 8: impressions exploded 71% and I think I know why

The numbers

What I think caused it

The position thing

What I built this week

Backlinks update

Organic search is now #1 traffic source

The `effort` parameter an oversimplification