Optimizing Artifact Load Speeds

by Mr Lawrence

August 4, 2025

Slashing Load Times: From Laggy 20 Seconds to Instant Under 3!

You know, there are some problems in development that just grind your gears. For me, one of the biggest headaches recently was how long it took to load an artifact over at Inkriv. We observed load times reaching the 20-second mark or more in some cases. While this is anecdotal, it was a significant issue for our team. It was, frankly, a deal-breaker for a good user experience, especially when these artifacts are generated by an LLM and meant to be viewed fluidly. We needed a serious change, and fast.

Our setup was using Sandpack by CodeSandbox on the frontend to render artifacts. And let me tell you, while Sandpack has its place, for our specific use case, it was pure agony. It handled the entire bundling; compiling, and then giving us a runtime environment, which was just prohibitively slow for the amount of data we were pushing through. It delivered a build and a runtime, which was just hell for our needs. I knew there had to be a better way to get these cool pieces instantly to our users.

The Search for Speed: From Vite to Custom Simplicity

So, I started digging. My first thought process took me down the path of other bundlers. I experimented with a Vite build for a bit, thinking lighter bundle sizes might be the answer. But what Vite generated was still not what I was looking for. The output was, honestly, proportionally too big and still required a certain environment or setup to be leveraged. It simply didn't achieve the fundamental goal of a simple, standalone asset.

The Breakthrough: A Dedicated Build Flow with Esbuild

That's when an entirely different idea clicked for me. Forget complex runtimes or bloated bundles that are not needed. What if I could create something genuinely slim, fast, and self-contained? My solution involved crafting a custom build process centered around esbuild.

Here's how it shakes out now:

  1. Custom Esbuild Magic: I wrote my own build script using esbuild. This little powerhouse churns out the complete triumvirate: your HTML, CSS, and JavaScript. The critical part is that it generates them to run standalone. No dependencies, no runtime overhead needed on the client-side beyond a web browser.

  2. Build ID and Cloudinary Power: When a build is successfully crafted, the system does something super smart. It assigns a unique buildID to that specific output. Simultaneously, all the critical files of that build, the HTML, CSS, and JS, are instantly uploaded to Cloudinary. Now, this isn't just about storage; Cloudinary brings big guns for content delivery, which means killer caching and globally optimized delivery. You want speedy access? It's right there.

  3. Frontend Rendereing without Friction: When it comes time to actually show this artifact on the user's screen in the frontend, it's astonishingly simple. Your document basically requests that specific buildID. The server responds, sending back the raw HTML content, and here's the kicker: that HTML document already has all the CSS and JavaScript beautifully embedded within it. It's all there, one neat package ready to display.

  4. The Masterpiece: iFrame Perfection: The grand finale of this process is rendering it. And for that, we use what's arguably the simplest and most robust solution for content embedding: an iframe. You just drop it onto your page, point it to a specific URL that corresponds to your buildID, and boom, the artifact just displays. It's clean, it's isolated, and critically, it's blazingly fast.

Universal Access: Just Like Your Favorite Video Site

Beyond Inkriv's internal efficiency, this new system offers an incredible level of portability. Because the build generates standalone HTML with everything wrapped up, and it's served through a request-by-ID, you can use this app anywhere. Literally, anywhere. Embed it right in your own document or project as an iframe, just by pointing to its unique URL.

Think about how common YouTube embeddings are. My solution follows that exact same philosophy. You have a shareable, embeddable artifact that works wherever HTML works, without needing to worry about complex build set up on the host site.

Before all this, and even trying Vite, I’ve been a big fan of React for all the cool things and ease of development it offers. And yes, I wanted to leverage awesome UI components like those from Shadcn when building. But for this particular problem, sometimes the tried and true simple solution is the elegant one. My path was about raw speed and simplicity for the delivery of an LLM-generated artifact, and the results speak for themselves. Forget those crawling 20-second waits, now we’re looking at less than 3 seconds for an artifact to fully load and captivate a user.

It feels good to tame a beast, sometimes you go full circle to re-discover what’s purely effective.