[KevinH]

FWIW ...

In epub2 the OPF guide section can include ids (fragments in the url) which point into xhtml files that should not be removed.

And under epub2 the adobe pagemap.xml can and typically do point to ids in xhtml files that will break if removed.

And, technically the same id can be re-used as long as they are in different xhtml files, so determining if used or not should really keep track of filenames.

And, technically under epub3, EPUB Canonical Fragment Identifiers (cfis) can use ids to point to specific spots in xhtml files for either internal or external cfi links, bookmarks, annotation points that may exist outside the epub itself (from cloud based web cfi links).

And technically, under epub3 that supports javascript, those ids could be referenced for dynamic searching or popup footnotes or by the js code itself.

So you really need you take care of all of the potential use points or you can never know if an id is used or not.

Therefore, without a really good reason, removing ids is probably not the best idea ... unless you truly know or control the epubs full production.

Even numbered paragraph ids are useful for reflowable epub locations used in printed academic citations and are more correct than page numbers in many cases.

The overhead of parsing even a thousand ids in a single xhtml file is minuscule compared to the time takes the parser to parse and create the initial DOM tree itself. So removing them is rarely or ever necessary from a performance perspective.


My 2 cents ...