The ebook Performance Checklist

HTML

Get rid of useless tags Each tag will create a new element node (with the corresponding text and attributes nodes). While this shouldn’t be a problem in theory, it may cripple performance once bottlenecks are piling up, especially when Reading Systems are manipulating those nodes before you do. Ensure semantic markup More and more, Reading Systems tend to rely on HTML 5 suggested rendering, which means you can benefit from it. It’s just about building on top of it. And it will be easier for RS to apply user settings too. Besides, proper semantic markup helps with accessibility since you don’t have to rely on aria roles. Ensure each HTML file is less than 250 KB It is known older Reading Systems can’t cope with content above 300 KB. But that can already be too much in case you’ve got a lot of images in one single HTML file. In other words, you should divide and conquer. Declare the language of your documents Some Reading Systems will try to add it by themselves if there isn’t any as hyphenation and text-to-speech rely on it, which requires some resources since it is usually achieved through scripts when loading contents.

CSS

Leverage inheritance and the cascade This is all about the DRY concept. By leveraging the cascade, you avoid cruft and end up with a lighter stylesheet. CSS was designed for documents, ebooks are documents. It’s a match made in heaven. Simplify overqualified selectors It should not have a huge performance impact but once again, Reading Systems are a strange beast. Avoid [attribute] selectors whenever possible Compared to tags, classes and ids, attribute selectors might be 5 times less performant on desktop and 10 times less performant on mobile. When your performance budget is constrained, that can make a huge difference. Ensure each HTML file doesn’t contain too many elements with float float can become an issue in older Reading Systems, especially on eInk Readers: too much floats in one HTML file and turning a page might take up to 5 seconds. Ensure each HTML file doesn’t contain too many elements with opacity opacity can become an issue in older Reading Systems. That may even crash some apps or devices. Try to limit the number of CSS files you’re linking (1-2 max) Multiple stylesheets are known to be problematic in older Reading Systems as they affect anchor links. Moreover, your single stylesheet will be cached and users won’t need to request a new stylesheet for each section. Chances are the weight of your ebook stylesheet won’t be an issue—as long as you are taking advantage of the cascade—while multiple stylesheets could. Please also note the performance of @import is really bad. Get rid of unused rules Reading Systems will have less matching to do. That may affect rendering time dramatically. Validate your stylesheets Some older RS will drop your entire stylesheet if they encounter an error, which implies one file will be requested for nothing. As for other RS, don’t let them pause and throw an error in the console while parsing your stylesheet. Minify your CSS files Reading Systems don’t need spaces, tabs and comments for readability. Minify your CSS so that its impact is the smallest possible.

Fonts

Consider dropping fonts which are not necessary Chances are users will pick the typeface they prefer in the settings. Is it really necessary to embed fonts for body copy then? Subset embedded fonts You probably don’t need all glyphs and characters so you could save some weight—for instance, CJK fonts can be 10 MB! Provide sensible font-stacks for your custom fonts This is all about preparing for the future. Custom fonts slow down pages because they are additional resources. Should font-display become the new standard and Reading Systems be impacted, you’ll be covered.

Images

Ensure the best format is used for each image JPEG, PNG and GIF all have their pros and cons. If you don’t need transparency or gorgeous text rendering, why should you use PNG, which is usually bigger than JPEG? And maybe you don’t need more than 256 colors, which means GIF could be the best option? By carefully picking the best format for each image, you can save megabytes! Optimize dimensions Should a small decoration be 5 million pixels? Save images for the web Photo editor apps usually ship with custom exports for the web; image’s loading and rendering can be quite expensive for some devices so take advantage of those exports. Try to export images which are less than 300 KB and 3 million pixels The lighter, the better… especially as older reading systems can’t cope with more than 300 KB and may crash. Unfortunately, those older reading systems can’t reasonably cope with images which are more than 3 millions pixels as well. So if you are targeting them, you’ll have to enforce this limit. Otherwise, it will take an awful amount of time to display them. Optimize your images Export for the web is good but it’s not good enough. And that’s why utilities like ImageOptim, MozJPEG or pngquant are available. Those utilities rely on powerful algorithms which can save a few more kilobytes. Consider the rendering of your images in night mode Once again, prepare for the future. Let’s imagine you don’t care about night mode and your images are unreadable. Then, Reading System developers will use CSS filters… Unfortunately, you can expect a performance hit with heavy CSS filter usage.

SVG

Try to use SVG instead of images whenever possible SVG can scale and look great at any resolution. It doesn’t need 5 million pixels for outstanding rendering in fullscreen. Also, they can be inlined in your HTML documents, which means you won’t need an additional request, unlike images. Get rid of useless layers in your vector drawing app Dedicated apps tend to export stuff you don’t really need. For instance, if you save as SVG, some apps will embed all artboards while you only need one. Take that into account since there is no need for XML that won’t be visible in the viewBox. Simplify paths The simpler your paths, the lighter your XML. Let’s make it easier for the rendering engine! Take advantage of CSS Some vector drawing apps will output basic shapes (rect, circle, ellipse, polygon, etc.) as paths, especially when borders are applied. Now, you can style SVG with good old CSS! If you want to apply a border, you can just use stroke and stroke-width. As a result, your SVG will be a hell of a lot lighter and more readable. Consider text instead of vectors Want some text to follow a path? You don’t need to vectorize that, which will result in a huge SVG file (one path for each letter). You can declare font-family for this text using CSS. Optimize SVG Chances are your vector drawing app output extraneous data you don’t really need. Utilites like SVGO can help reduce your SVG by half.

JavaScript

Create and follow a performance budget Reading Systems supporting JavaScript are themselves partly built using JavaScript, which means your performance budget is pretty tight. You’d better create a performance budget as low end devices will undoubtedly suffer. Try to avoid frameworks and plugins Since Reading Systems are also often built using frameworks (Prototype, jQuery, etc.), the performance hit is quite significant before you even throw your own scripts in. You might not need jQuery and plugins are often used as mere shortcuts… You probably won’t use more than 10% of their features but you’ll impose their burden (weight) on users. If you really need a framework to achieve something, consider a custom subset. Design your scripts with performance in mind Scripting is hard. While browsers’ developers are doing their utmost to achieve good performance, providing hints to JavaScript engines can speed up the execution dramatically. Favor document ready The sooner, the better… (even if you’ll probably need a timeout because Reading Systems can be funky). Check the performance impact of your scripts (debug) You don’t want your scripts to screw everything up. By profiling JavaScript in the browser, you’ll spot what creates jank. Ensure your scripts don’t create memory leaks Managing memory is mandatory, especially as some mobile devices might be short on RAM. Avoid creating accidental global variables, running unnecessary timers or keeping references that are not in the DOM anymore. Garbage collection FTW! Avoid overriding Reading System’s default events You could accidentally fire a ton of events, which might have a performance impact (e.g. interactive ebooks for which rendering is an intensive task). Ensure your ebook works well if JavaScript is not supported What if a script is running in the background while the Reading System doesn’t even support the feature you’re relying upon? That would waste quite a lot of ressources, right? Your scripts should be built around features, which means you detect those features first and run the script accordingly. And since “no JavaScript” is quite the standard in practice, you should consider scripting as a progressive enhancement. Don’t let users down because they can’t access the most advanced Reading Systems. Use an external javascript file An external file will be cached, inline scripts won’t. Minify your JS files Reading Systems don’t need verbose functions, spaces and tabs for the sake of readability. By using a compression tool, you can probably reduce the size of your js files by half.

Animations

Ensure animations are meaningful and improve UX There’s nothing worse than useless animations impacting your performance budget because YOLO. Use CSS instead of JS whenever possible This myth might have been busted for the web but… Reading Systems are a lot more constrained than web browsers. It should be repeated for the benefit of everyone, Reading Systems are often built using JavaScript, which means it’s a good idea to use anything else than JS whenever possible. Avoid animating properties which affect layout and paint Browsers can animate transforms and opacity cheaply, this is not the case for properties like width, top or background-image. Avoid properties affecting paint at any cost. Learn more at HTML5rocks. Try to provide users with controls (disabling, pausing, etc.) What if the user doesn’t even want to experience animations? You could save a lot of resources! If you think about it for a second, controls might turn an unpleasing experience into a readable book, especially on low end devices. And don’t forget this is an accessibility issue as well.

Quality Assurance

Check your ebook on various devices, from low to high end Let’s be honest, you just can’t QA your ebook file on a brand new iPhone/iPad and call it a day… A lot of people are using less capable devices in real life. You should at least test your ebook on a $200 Android device and a good old eInk Reader if you want to provide users with the best possible experience. Check if there is no rendering issue with your custom fonts Users wait extra seconds for contents to load only to see custom fonts are completely screwed up. How would you feel about that as a user? Change user settings to make sure everything is OK Reading Systems sometimes reload the whole document to change font-family, font-size, etc. Check if your ebook file doesn’t contain bottlenecks slowing user settings down. Consider the size of your EPUB file Sure, ebookStores set an upper limit but does it mean you should publish a 650 MB or 2 GB file? The bigger your EPUB file, the harder some Reading Systems may fall. And it’s a User eXperience issue as well: this will probably take forever to download then bloat the user’s device, etc. Don’t forget a lot of Android devices out there currently ship with just 8–16 GB of storage.