Every tool page on ramrom.io — TikTok, Instagram, Facebook, YouTube — runs the same small JavaScript file. One shared engine handles the paste box, the resolve call, the quality list, and the download click. It is the kind of file that grows quietly: a helper here, a fallback there, until it is a few hundred lines long and loaded on every page.
On shared hosting there is no build step. No bundler, no pipeline, no npm run build before deploy. So when I wanted that file smaller, I had to minify it by hand — or rather, with a simple minifier run on my own machine before upload — and then prove nothing had broken. Minifying sounds trivial until the file in question is the one thing standing between a visitor and their download.
What the engine actually does
The shared script does four jobs, and only four:
- Reads the pasted link and works out which platform it belongs to.
- Sends it to
resolve.phpand shows the formats that come back. - Sorts the quality options best-first, with honest labels for what each one really is.
- Hands the chosen format to the download proxy and forces a real download instead of playing the video in the tab.
That is it. No framework, no analytics in this file, no tracking. Keeping it small is the whole point, because it loads on every tool page and the mobile score notices every kilobyte.
How I minified it without a build step
I keep two copies: engine.js, the readable source, and engine.min.js, the one the pages actually load. The minified copy is produced on my own machine with a plain minifier — strip comments, drop whitespace, shorten local variable names — and nothing else. No mangling of property names, no clever transforms, because the file talks to the page through element IDs and form names, and a rename there would silently break the wiring.
The upload order matters: the minified file goes up first, then the pages that reference it, and the cache-bust query string (?v=) on the script tag goes up last, so no visitor ever gets a new page pointing at an old script, or an old page pointing at a script that is not there yet.
Proving it still works
This is the part people skip, and it is the only part that matters. A minified file that loads is not a minified file that works. Before I called it live, I ran the same checklist against the minified copy that I run after any change to the engine:
- Paste a TikTok link, an Instagram reel link, a Facebook reel link, and a YouTube link. Each one must resolve to a real list of formats, not an error box.
- Check the quality list is still sorted best-first, and that the labels still say what each format really is — video with sound, video only, audio only.
- Click download on each platform and confirm the browser downloads a file instead of opening a player.
- Paste a nonsense link and confirm the page says plainly that it is not a supported platform, instead of spinning forever.
- Paste a deleted-video link and confirm the message says the video is gone, not that the site is down.
Every check passed on the minified copy before it went live. The file is roughly a third smaller, the pages load it the same way, and nothing about the visitor's experience changed — which is exactly the result I wanted.
The rule I kept
Never edit the minified file by hand. If a fix is needed, it goes into engine.js, gets minified again, and goes through the same checklist. The moment you patch the minified copy directly, the two copies drift apart and the next minify wipes your fix without telling you.
Minifying is not glamorous work. Nobody writes home about a smaller JavaScript file. But on a plain PHP site with no build step, it is one of the few performance wins that costs nothing, breaks nothing — as long as you test it like it might — and stays done once it is done.
