DEV Community: Dyle Nazarro

Building an Image to Image AI Editor That Actually Ranks: A Performance & SEO Post-Mortem

Dyle Nazarro — Mon, 01 Jun 2026 15:16:03 +0000

I run image2image.ai - an AI image editor that lets users transform photos by describing what they want changed. Think of it as a visual editing layer powered by generative AI: upload a photo, type a prompt, and get a modified result.

After launch, I spent months building backlinks and waiting for Google to notice. Nothing moved. My average position for core terms stayed buried past page 8. I assumed I just needed more links.

I was wrong. The real problem was on the page itself: brutal Total Blocking Time and thin on-page SEO architecture. Fixing those two things moved the needle more than six months of link building.

Here is the exact technical breakdown.

Part 1: Performance — Why TBT Matters More Than Lighthouse Score

My Lighthouse Performance score was 62. But the scarier number was Total Blocking Time: 680 ms. On a tool where the user's first action is usually clicking "Generate," a blocked main thread means the button feels frozen. Users bounce before the AI even starts working.

The Animation Bottleneck

My landing page had a scroll-driven showcase section. The original implementation rendered all image batches in the DOM simultaneously, using CSS transforms to slide them in and out. Visually it worked. Under the hood, it was a disaster.

// BEFORE: Every batch was in the DOM, always.
<div className="relative h-[600px]">
  {batches.map((batch) => (
    <motion.div
      key={batch.id}
      initial={{ opacity: 0, y: 50 }}
      // All 6 batches hydrated, calculated, and painted on load
    >
      {batch.images.map(...)}
    </motion.div>
  ))}
</div>

I refactored it to render only the active batch, using scroll position to swap the rendered node rather than animate hidden layers.

// AFTER: Only the active batch exists in the DOM.
const activeBatch = batches[activeIndex];

return (
  <div className="relative h-[600px]">
    <AnimatePresence mode="wait">
      <motion.div
        key={activeBatch.id}
        initial={{ opacity: 0, y: 30 }}
        animate={{ opacity: 1, y: 0 }}
        exit={{ opacity: 0, y: -30 }}
        transition={{ duration: 0.4 }}
      >
        {activeBatch.images.map((img) => (
          <Image
            key={img.src}
            src={img.src}
            alt={img.alt}
            width={400}
            height={400}
            className="rounded-lg"
          />
        ))}
      </motion.div>
    </AnimatePresence>
  </div>
);

I also stripped out every will-change: transform and translateZ(0) hack I had copy-pasted from old CSS tricks. They were forcing compositor layers on dozens of hidden elements.

Result: TBT dropped from 680 ms to 140 ms. First Input Delay became imperceptible.

Image Loading Discipline

An image to image tool is visually heavy by definition. I had sample outputs, before/after comparisons, and tool screenshots all loading eagerly.

I applied two rules universally:

Only the hero image gets priority. Everything else is lazy by default.
Always provide sizes. Otherwise Next.js sends desktop-resolution assets to mobile users.

<Image
  src="/showcase/portrait-cyberpunk.jpg"
  alt="Portrait transformed by image to image AI editing"
  width={800}
  height={600}
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
  className="rounded-xl object-cover"
/>

Font Blocking

I was loading a custom font via a CSS @import. It blocked rendering for nearly half a second. I moved to next/font/google with display: 'swap':

import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

That single change shaved 0.3 s off First Contentful Paint.

Part 2: On-Page SEO — When Metadata Is Your Only Moat

Once the site was fast enough to not annoy crawlers, I had to give them something to index. A tool site with thin marketing copy gets treated like a doorway page.

Dynamic Route Metadata

I started with static metadata in layout.tsx. That meant my /upscale, /restore, and main editor pages all shared the same title tag. I moved every marketing route to dynamic generateMetadata:

// app/(marketing)/image-to-image/page.tsx
import type { Metadata } from 'next';

export async function generateMetadata(): Promise<Metadata> {
  return {
    title: 'Free Image to Image AI Editor — Edit Photos with Text Prompts',
    description:
      'Transform any photo with our AI image editor. Upload an image, describe the change, and download the result in seconds. No design skills needed.',
    openGraph: {
      title: 'Image to Image AI Editor',
      description: 'Transform photos using text prompts with our free AI image editor.',
      images: [{ url: '/og/image-to-image.png', width: 1200, height: 630 }],
    },
  };
}

Unique metadata per route signals topical depth. After this change, my indexed pages jumped from 4 to 28 within two crawl cycles.

Structured Data for Rich Snippets

I injected JSON-LD on the homepage and each tool landing page. For the product itself, I use SoftwareApplication schema:

const softwareAppLd = {
  '@context': 'https://schema.org',
  '@type': 'SoftwareApplication',
  name: 'image2image.ai',
  applicationCategory: 'DesignApplication',
  offers: {
    '@type': 'Offer',
    price: '0',
    priceCurrency: 'USD',
  },
  aggregateRating: {
    '@type': 'AggregateRating',
    ratingValue: '4.8',
    ratingCount: '1240',
  },
};

For the FAQ section, I added FAQPage schema. It is boring to implement, but it wins SERP real estate immediately.

Semantic HTML & Heading Discipline

I audited the heading tree and found multiple H1s and skipped levels. I enforced a strict structure:

One H1 per page. The homepage H1 is the exact value proposition, not a vague brand slogan.
Logical sectioning. Every major block is a <section> with a clear H2. No more <div> soup.
Descriptive internal links. Instead of "click here" or "learn more," I use anchor text that describes the destination: "Try our AI image editor for background removal" or "Explore more image to image transformations."

Content Architecture Over Keyword Stuffing

Early versions of my hero section crammed "image to image" and "AI image editor" into every sentence. It read like spam and scored poorly on readability audits.

I rewrote the content to use keywords where they naturally fit:

H1: "Free Image to Image AI Editor"
Subtitle: "Transform photos with text prompts"
Body: Explain the workflow. Mention the AI image editor context once in the opening graph, once in a feature description, and once in the CTA.

If you have to force a keyword into a sentence, it does not belong there.

The Numbers

I made these changes over a four-week window. I paused active link building so I could isolate the impact.

Metric	Before	After
Lighthouse Performance	62	94
Total Blocking Time	680 ms	140 ms
Indexed Pages (GSC)	4	28
Avg. Position (core keyword)	> 80	12–18

The lesson: Speed and structure are product features. If your pages do not technically allow Google to understand and trust your content, no amount of domain authority will save you.

Stack & Tools

Framework: Next.js 14 (App Router)
Styling: Tailwind CSS
Images: next/image with WebP fallback
Fonts: next/font with display: swap
Animations: Framer Motion (render-on-demand only)
Schema: Manual JSON-LD injected via next/script

Check the live result at Image to image AI .

If you are building a tool site and treating SEO as a post-launch task, flip the order. Fix the page first. The links you earn later will actually pull weight.

I Built an AI 3D Model Generator — Here's How I Handle Meshes in the Browser

Dyle Nazarro — Mon, 25 May 2026 03:35:20 +0000

I shipped www.imgto3d.ai a few months ago. It's an AI-powered 3D model generator: you upload an image, pick a generator (upscale, denoise, face recovery, or full restoration), and get back a .glb file you can drop into Blender, Unity, or straight into a web page.

The AI backend part — calling Replicate, polling for results, handling credits — was straightforward. The part that actually made me lose sleep? Getting those generated 3D assets to render smoothly inside a Next.js app without turning the user's phone into a hand warmer.

This is the story of how I built the frontend, and the specific performance tricks I had to pull to make browser-based 3D preview not feel like a PowerPoint from 2003.

What the Product Actually Does

ai3dgen.com runs four generators:

Upscale — takes a low-poly preview and bumps the geometry density.
Denoise / Unblur — cleans up noisy AI outputs.
Face Recovery — fixes distorted facial topology on character models.
Restoration — full pipeline for damaged or low-quality inputs.

Users pick their settings, burn some credits, and get an email when the mesh is ready. The critical moment is when they click "Preview" and expect to spin the model around in 3D right there in the browser.

That preview is where everything almost fell apart.

The Problem: AI Doesn't Care About Your Frame Rate

When users want to turn a 2D image into a 3D model online, they expect two things: fast processing and a crisp, interactive preview. The AI pipeline delivers beautiful meshes — thousands of polygons, 4K textures, the works. But it delivers them with zero optimization. There's no LOD. No texture atlasing. No one ran it through a decimation modifier.

My first attempt was embarrassingly naive: dump the raw .glb into a <Canvas> and call it a day. On my M2 MacBook, buttery smooth. On a 2021 Android phone? Tab crash. iOS Safari? "A problem occurred with this webpage so it was reloaded." Every. Single. Time.

I realized I wasn't just building a product — I was building a 3D runtime that had to survive the wild west of consumer hardware.

The Stack

Next.js 14 (App Router) — SSR for SEO, client components for the viewer.
Tailwind CSS — because I'm not writing raw CSS in 2026.
React Three Fiber (R3F) + @react-three/drei — declarative 3D scenes as React components. If you're still wrapping raw Three.js in useEffect, you're making life harder than it needs to be.
Replicate API — the AI pipeline that generates the actual meshes.

R3F makes it easy to get something on screen. It does not make it easy to get something performant on screen. That part is on you.

The Viewer Component (Production Code)

Here's the actual component running in production. Every line in here exists because something broke in production first.

import React, { Suspense, useMemo } from 'react';
import { Canvas } from '@react-three/fiber';
import { OrbitControls, useGLTF, Center, Environment } from '@react-three/drei';

function Model({ url }: { url: string }) {
  // useGLTF caches by URL. But if your URL is a signed S3 link 
  // that changes every refresh, congrats — you just disabled caching.
  const { scene } = useGLTF(url, true);

  // Clone the scene so multiple instances don't share materials
  const clonedScene = useMemo(() => scene.clone(), [scene]);

  return (
    <primitive 
      object={clonedScene} 
      scale={1.5} 
      castShadow 
      receiveShadow 
    />
  );
}

function Loader() {
  return (
    <div className="absolute inset-0 flex flex-col items-center justify-center bg-[#0d0e12] text-white z-10">
      <div className="h-10 w-10 border-2 border-gray-700 border-t-cyan-500 rounded-full animate-spin" />
      <p className="mt-4 text-sm text-gray-400">Decoding mesh...</p>
    </div>
  );
}

export default function Viewer3D({ modelUrl }: { modelUrl: string }) {
  return (
    <div className="relative w-full h-[500px] bg-[#0d0e12] rounded-xl overflow-hidden border border-gray-800">
      <Suspense fallback={<Loader />}>
        <Canvas
          camera={{ position: [0, 1.5, 4], fov: 45 }}
          gl={{ 
            antialias: true, 
            preserveDrawingBuffer: true,
            powerPreference: "high-performance"
          }}
          dpr={[1, 2]} // Clamp pixel ratio — retina screens will murder your FPS otherwise
        >
          <ambientLight intensity={0.6} />
          <directionalLight 
            position={[5, 5, 5]} 
            intensity={1.0} 
            castShadow 
            shadow-mapSize-width={1024}
            shadow-mapSize-height={1024}
          />

          <Center>
            <Model url={modelUrl} />
          </Center>

          <OrbitControls 
            enablePan={false}
            enableZoom={true}
            minDistance={1.5}
            maxDistance={8}
            maxPolarAngle={Math.PI / 1.5} // Prevent going below the ground
            autoRotate
            autoRotateSpeed={1.0}
          />

          <Environment preset="city" />
        </Canvas>
      </Suspense>
    </div>
  );
}

Three Things I Learned the Hard Way

1. Draco Compression Is Non-Negotiable

The AI backend originally served raw GLBs. A typical output was 45MB. On a 3G connection, that's 30+ seconds of staring at a spinner. Users bounce before the first vertex loads.

I added server-side Draco compression. File sizes dropped to ~8MB. Visually identical. The catch? You need to tell useGLTF to use a Draco decoder, and that decoder needs a .wasm file. Host that .wasm on a different domain without CORS headers? Silent failure. The model just never loads, and you get no error in Sentry.

// In your app entry or a useEffect
useGLTF.setDRACOLoader(new DRACOLoader().setDecoderPath('/draco/'));

Also, Draco decoding is CPU-intensive. I throttle it by limiting concurrent loads — if a user rapidly switches between models in the gallery, I cancel the previous request. Otherwise, the main thread chokes and the UI freezes.

2. iOS Safari Is the Final Boss

Apple's WebGL implementation on iOS has a hard memory limit. Not a suggestion — a hard ceiling. Exceed it, and Safari nukes your tab without warning. No exception. No graceful degradation. Just reload.

I discovered this testing a high-poly model with an 8K texture. Chrome desktop? Perfect 60 FPS. iPhone 14? Instant reload.

My fixes:

Cap texture resolution at 2K for mobile (detected via navigator.hardwareConcurrency + touch event sniffing).
Clamp dpr to [1, 1.5] on mobile instead of [1, 2].
Implemented a "Lite Mode" toggle that swaps to a lower-poly version of the mesh. I hate that it exists, but users on older devices love it.

3. Don't Trust the Default Lighting

A 3D model under default lighting looks like a plastic toy from a gas station. I spent way too long tweaking individual lights before realizing R3F's <Environment> component with a preset solves 90% of the problem. It gives you realistic reflections and ambient occlusion for free.

The other 10%? A subtle contact shadow under the model using <ContactShadows> from Drei. It grounds the object and makes it feel like it's sitting on a surface, not floating in a void.

Why This Architecture?

I chose Next.js + R3F because I needed two things that usually fight each other:

SEO — the marketing pages need to rank. Next.js App Router handles that.
Interactive 3D — the viewer needs to be a rich client experience. R3F handles that.

The split is clean: server components for landing pages, metadata, and auth. Client components wrapped in 'use client' only where the Canvas lives. I keep the bundle small by dynamically importing the viewer:

const Viewer3D = dynamic(() => import('@/components/Viewer3D'), { ssr: false });

This way, the Three.js payload only hits users who actually click "Preview." Everyone else gets a fast, lightweight landing page.

Where It Stands Now

ai3dgen.com is live. It handles four distinct generation pipelines, serves 12 languages, and processes thousands of conversions per week. The 3D viewer went from "crash my phone" to "smooth on a 4-year-old mid-range Android."

The hardest part wasn't the AI. It was respecting the user's hardware.

Try It / Break It

If you're building something with in-browser 3D — an AI tool, a product configurator, a portfolio — the ecosystem is mature enough that you don't need a graphics PhD. R3F + Drei + a bit of performance paranoia gets you 90% of the way there.

If you want to stress-test your own 3D viewer, image-to-3d AI will give you some gloriously unoptimized GLBs to throw at it. Upload an image, grab the mesh, and see if your renderer survives.

How are you handling 3D assets in your web apps? Running into the same memory limits, or have you jumped to WebGPU already? Drop a comment — always curious to see how others are solving this.

Zero to Printable: How Image-to-3D AI Is Changing Rapid Prototyping Workflows

Dyle Nazarro — Wed, 13 May 2026 15:45:25 +0000

The Bottleneck No One Talks About

Rapid prototyping is supposed to be rapid. You have an idea, you model it, you print it, you iterate. In reality, the "model it" phase often kills the momentum. If you are not fluent in CAD or sculpting software, getting from a concept—whether a photo, a sketch, or a mental image—to a physical object can take days. Even experienced makers spend hours on mesh cleanup before the model is slicer-ready.

Traditionally, bridging the 2D-to-physical gap meant one of two things: learning parametric CAD for geometric parts, or using photogrammetry for organic shapes. Both work, but both impose heavy upfront costs in time, skill, or hardware setup.

Over the last year, a third path has emerged: single-image 3D reconstruction powered by diffusion and depth-estimation models. The idea is seductively simple—upload one picture, get back a textured mesh. But anyone who has actually tried to print one of these meshes knows the reality: raw AI output is rarely printable. The devil is in the topology.

In this post, I want to walk through the full technical pipeline from a flat image to a physical 3D print, explain why manifold geometry is the silent gatekeeper most AI tools ignore, and show how modern pipelines are finally automating the parts that used to require manual cleanup.

The Pipeline: From Pixels to Plastic

Let us trace the journey of a single input image as it becomes a printable object.

Stage 1: Monocular Depth and Surface Normal Estimation

The system starts by inferring 3D structure from a single 2D view. This is fundamentally an ill-posed problem—there are infinite 3D scenes that could produce the same 2D projection. Modern approaches use a combination of:

Monocular depth estimators (MiDaS, ZoeDepth, or proprietary variants) to generate a disparity map.
Surface normal prediction to understand local surface orientation.
Semantic segmentation to separate foreground subjects from background clutter.

The depth map alone is not enough. A naive extrusion—pushing pixels back according to depth—creates a "relief" or heightmap, not a true volumetric object. Heightmaps are fine for embossing, but they are not closed meshes. You cannot print a heightmap because it has no back face, no thickness, and no sidewalls.

Stage 2: Volumetric Reconstruction

To get a printable object, the pipeline must infer the occluded geometry—the parts of the object hidden behind the visible surface. This is where neural reconstruction methods differ from simple extrusion. The model hallucinates (or more generously, reasons about) the back side of the object based on learned priors from millions of 3D shapes.

The output at this stage is usually a dense point cloud or an implicit neural representation (like an SDF or NeRF-like field). The challenge is extracting an actual polygon mesh from this representation. Marching Cubes or differentiable rasterization converts the field into triangles, but the resulting mesh is often noisy, over-tessellated, and geometrically inconsistent.

Stage 3: The Hard Part—Making It Printable

Here is where most "image-to-3D" demos stop, and where the real engineering work begins. A 3D printer slicer (PrusaSlicer, Cura, Bambu Studio) expects a watertight, manifold mesh in STL format. Let us break down what that means in practice.

Manifold geometry means every edge in the mesh is shared by exactly two faces. No more, no less. If an edge belongs to only one face, you have a boundary edge—an open hole. If three or more faces meet at an edge, you have a non-manifold junction. Both cases break the slicer.

AI-generated meshes are notorious for non-manifold artifacts because the reconstruction process does not inherently respect topological constraints. You get:

Zero-area faces from degenerate triangles in flat regions.
Internal faces where the front and back surfaces intersect incorrectly.
Holes where the model failed to close the volume.
Floating islands of disconnected geometry.

Before printing, these must be fixed. Traditionally, this meant importing the mesh into Blender or Meshmixer, running "Make Manifold" or "Close Holes," manually deleting internal faces, and remeshing. For a complex organic shape, this could take 30 minutes to an hour.

Modern pipelines automate this cleanup through a post-processing stack:

Voxel-based remeshing: Convert the mesh to a voxel grid, dilate/erode to close small holes, then extract a clean isosurface. This is computationally expensive but robust.
Implicit surface regularization: Rather than extracting a raw mesh from the neural field, apply a smoothness prior that naturally produces closed surfaces.
Topology-aware decimation: Reduce polygon count while preserving manifold structure, so the STL file is not unnecessarily large.

Stage 4: Format and Export

For 3D printing, STL is still the universal standard, even though it is a terrible format (no color, no units, redundant vertices). GLB and OBJ are useful for visualization and game engines, but slicers prefer STL because it is unambiguously a shell of triangles.

A production-ready pipeline must therefore handle format conversion, unit scaling, and vertex welding automatically. The user should not need to know what a "non-manifold edge" is to get a successful first print.

Photogrammetry vs. Single-Image AI: A Practical Comparison

I have used both extensively for prototyping, and they serve different purposes.

Dimension	Photogrammetry	Single-Image AI Reconstruction
Input	20–200 photos from multiple angles	One photo or sketch
Capture time	10–30 minutes of shooting	Instant upload
Compute	High (hours on CPU/GPU)	Low (seconds to minutes in cloud)
Accuracy	Millimeter-precise for scanned objects	Approximate, artistically faithful
Surface handling	Struggles with reflections, glass, mono-color	Handles any visible surface, hallucinates occluded
Mesh cleanup	Moderate (noise, holes from missing angles)	Heavy without post-processing; light with automated cleanup
Best use	Reverse-engineering existing physical parts	Concept validation, artistic prototypes, character models

Photogrammetry is a measurement tool. Single-image AI is an ideation tool. If you need to replicate a broken drone propeller with exact tolerances, use photogrammetry or calipers. If you want to turn a character sketch into a figurine, AI reconstruction is the faster path.

The critical evolution is that the cleanup gap is closing. Early AI-to-3D tools dumped raw, broken meshes on the user. Newer pipelines—built specifically for makers rather than demo videos—handle the manifold conversion and decimation server-side.

A Real-World Walkthrough

Last week I needed a physical prototype of a stylized robot head for a hardware project. I had a front-facing concept render, but no time to sculpt it.

I ran the image through a pipeline that handles the full stack: depth estimation, volumetric reconstruction, automated manifold cleanup, and STL export. The raw mesh extraction had 340,000 triangles and multiple non-manifold edges around the antennae. After automated voxel remeshing and topology repair, it dropped to 82,000 clean triangles. I loaded the STL into Bambu Studio, added tree supports for the overhanging chin, and hit print.

Total time from image to G-code: under three minutes. The print came out clean, and the surface detail from the original render was preserved well enough to serve as a paintable master mold.

This is the workflow that matters: not replacing the modeler, but eliminating the blocking time between "I have an image" and "I can hold it."

What to Look For in an Image-to-3D Pipeline

If you are evaluating tools for your own prototyping stack, here are the technical criteria that actually matter:

Watertight guarantee: Does the output pass a manifold check without manual repair? Run it through Meshmixer’s Inspector or Blender’s 3D-Print Toolbox before committing to a print.
Format flexibility: You need STL for printing, but GLB/OBJ are useful for previewing the textured model in a viewer before you commit filament.
Topology control: Can you choose between a fast, coarse mesh for draft prints and a dense, detailed mesh for final pieces? Look for tiered generation modes that let you trade speed for fidelity.
Background handling: If your input is a photo with a cluttered background, the pipeline needs segmentation to isolate the subject. Otherwise you will print the floor and the wall too.

Closing the Gap

The biggest lie in 3D printing marketing is that "anyone can print anything." The truth is that mesh preparation is still the hidden skill barrier. AI image-to-3D does not eliminate the need for engineering judgment, but it does compress the front end of the pipeline. It turns the sketch-to-mesh stage from a multi-hour modeling task into a sub-minute automated process.

For makers, this means you can validate form factors faster. For product designers, it means you can generate physical study models from reference photos during client meetings. For hobbyists, it means the distance between seeing something cool online and printing it just got a lot shorter.

If you have a sketch or a photo sitting in a folder that you always meant to model someday, the technical excuse is evaporating. Upload it and try the loop. Slice it, and print it.

I run a free image to 3d model platform called AI3DGen that automates this exact pipeline—single-image input, server-side manifold cleanup, and export to STL/GLB/OBJ. If you are building a rapid prototyping workflow and want to skip the mesh cleanup phase, it is built for that.