Does minifying matter for an APK?
Less than it does on the web, and more than nothing. On a website every kilobyte crosses the network; inside an APK the file is on the phone already, so download size is not the issue. What still matters is parse time — the WebView reads the whole document before it paints anything, and a 400 KB indented file with a hundred comments takes measurably longer to reach first paint than the same page at 180 KB — and the bundle limit: 5 MB of source content on the free tier, 18 MB on Pro. If you are near either, whitespace is the cheapest thing to remove.
It is also a mild form of tidiness. Comments that say <!-- TODO remove before launch --> ship to every user's phone otherwise, and anyone can read them by unzipping the APK.
What is removed, and what is not
- Removed: HTML comments, runs of whitespace between tags, indentation, blank lines; comments and spacing inside
<style>; block comments that stand alone on a line, indentation and blank lines inside<script>. - Kept exactly: everything inside
<pre>and<textarea>, conditional comments, all your JavaScript tokens. The script tidy never touches//comments (a URL contains one) or anything inside a line, so it cannot change what your code does.
That last point is the design choice. A real JavaScript minifier renames variables and rewrites expressions, which needs a full parser and can break code that uses eval or relies on function names. This tool is safe to run on anything; the price is that it saves less on script-heavy pages. If you need aggressive JS minification, run your build tool's minifier first and then this on the HTML.
Where it fits in the workflow
Write and test with the readable version. When you are ready to build, run the page through the merger if it is split into files, then through this minifier, and upload the result. Keep the readable source — the minified file is an output, not something to edit.