How can I optimize an epub file, in order, but not limited to:
- limit the chances of compatibility issues?
- make it faster to load and to be processed from the reader?
- keep its look consistent throughout different devices and readers?
Limiting compatibility issues
Making it faster to load
<b>tags for italic and bold text instead of their relative
Keeping it consistent
Keep the visual look as simple as possible; if you want to include some fancy layout (i.e. for chapter titles or other particular portions of text like quotes and so on) try to define it as properly and accurately as possible with CSS styles, and test the outcome with the greater number of reading devices and software that you can.
If you want to use any specific font, be sure to include it in the epub file and to define its
@font-face and styles in the CSS file.
The EPUB 3 specification1 suggests including embedded fonts for compatibility:
EPUB 3 does not require that Reading Systems come with any particular set of built-in system fonts. As occurs in Web contexts, Users in a particular locale might have installed fonts that omit characters required for other locales, and Reading Systems might utilize intrinsic fonts or font engines that do not utilize operating system installed fonts. As a result, the text content of an EPUB Publication might not natively render as intended on all Reading Systems.
To address this problem, EPUB 3 supports the embedding of fonts to facilitate the rendering of text content, and this practice is recommended in order to ensure content is rendered as intended.
Support for embedded fonts also ensures that characters and glyphs unique to an EPUB Publication can be embedded for proper display.
1Epub 3 Overview - Draft Specification 8 November 2013
You cannot optimize and make it faster to load and to be processed from the reader in a generic way for all possible readers and probably not for all available readers¹.
The reason is that there are conflicting elements involved that lead to different loading results on different device hardware configurations. For the reading device these configurations include:
From the above the SD card speed is most obviously variable, as SD cards are sold in different classes.
Assuming there is no DMA involved all of the EPUB data has to go through the CPU. Uncompressing data from an EPUB (ie. ZIP
If the storage is slow and CPU speed high, you better compress the data in an EPUB (use zip DEFLATE). If storage is fast and CPU speed low than you better not compress the data in an EPUB (use zip STORE). Decompressing compressed data from an EPUB file is non-trivial, including bit manipulations and tables. Implementing a decoding library for DEFLATE—although to a lesser extend then encoding—involves trade-offs between speed and memory requirements.
So just deciding² whether you should compress the data in an EPUB file or not—in order to make them faster to load is a hard to answer in general, although you should be able to do so for a specific reader after some testing.
¹ In this example I only approach the compression vs non-compression issue to make a point. Other elements that at first glance don't seem to have a global optimal solution: 1) Size of images so they don't require rescaling on any device and have maximum detail. 2) Use the deflate algorithm on JPEG images to get a little bit of extra compression for a double decompression to pixel information. 3) EPUB2 vs. EPUB3 issues. E.g. EPUB3 forces use of CSS for things like font size (as
<font> is not supported in HTML5). However an EPUB2 device might render
<font> faster than something specified in a separate CSS file, especially if applied only once in the HTML file.
² The resulting difference of any particular trade-off might be minuscule compared to other things that influence loading speed. That is of course irrelevant: every tiny bit helps, some just more than others.