如果您不是电子书生产商，那么您可能不会对本文感兴趣。
事实上，即使您是，但您可能已经经历了痛苦的表现，但这并不是我们习惯谈论的事情，因此兴趣不大。
现在，如果我们看一下网络，性能无处不在：良好的性能是必须的，因为它是用户体验的一部分，延迟3秒可能会导致销售急剧下降，开发人员试图达到每秒60帧的速度，等等等等。
我们当中有多少人（电子书生产商）实际上对移动应用程序或电子墨水读者的表现有确切的了解？ 您可以列出CSS或JS瓶颈吗？ 您是否根据绩效定义规则或最佳做法？ 您知道阅读系统如何工作吗？ 真？
- O livro como objeto
- Kindle Unlimited的Amazon Ebook定价策略
- 儿童互动度最高的电子书Android应用
- 每日交易– Gbolahan Ethan Onadeko –中
- Kobo Aura ONE使用感想
我当然不能广泛回答这些问题。 而且您可能也不可能，因为缺乏调试工具令人困惑。 因此，所有这些都是关于在大量设备上进行测试并感觉不正常的事情， 被动地做出决策，从而浪费了大量时间。
由于去年我一直在广泛地进行此操作，因此让我们分享一些有用的信息。
移动就是地狱
欢迎！
请告知在移动设备上的性能太差了。
祝您住宿愉快，世界末日快乐！
听着，我并不是说eInk读取器是低端设备，但他们使用的某些RS（例如RMSDK）肯定会让您感觉它是低端的……
问题是，在廉价的Android设备上，情况可能更糟 。 如果您从未在200美元的Android手机上对固定版式文件进行过质量检查，请注意，它只是不可用，不是因为固定尺寸提供了糟糕的UX“ PDF格式”，而是因为性能（渲染，交互… ）简直可怕 。
事实是，使用iOS的Webkit并不会更好，这就是为什么Kobo或Google在可能的情况下（例如漫画）使用基于图像的固定版面阅读器的原因。
综上所述，您应该以非常紧凑的性能预算来设计项目。 换句话说，使用iBooks所获得的性能绝不代表您在整个生态系统中所获得的平均性能 ，应将其视为最高性能-如果需要最低要求，则可以使用Android上的Adobe Digital Editions您正在搜索，因为它甚至不能仅在图像上在低端设备上显示整个页面。
从经验来看，如果您在iBooks上获得了OK，但不是那么出色，那么它将在很多设备和应用（甚至是iOS）上都是绝对的废话。 您必须在iBooks中达到出色的性能！
请将该前一个节点附加到头部。
显然，这意味着您也永远不应信任全能的台式机 。
明显的瓶颈
- 图像的加载和渲染非常昂贵，请优化这些图像。
- 与SVG相同。 不要怜悯！
- 字体在低端设备上会极大地影响您的性能预算， 仅在需要时才使用字体，并始终将它们作为子集 。
- xhtml文件越大，性能越差，尤其是当您有很多图像的时候。 分而治之。
- 最后，不要用无用的标签和废话肿您的标记。 这可能会有所不同，但有时可以节省您的时间。
CSS瓶颈
是的，我知道，CSS可能会出问题，对吧？
其实很多 。 我在设计Blitz框架时发现了这一点，它解释了其功能CSS方法。
让我们谈谈选择器的性能：
- 标签，#id，.class和：pseudo-class具有良好的性能；
- [attribute =“ stuff”]，[attribute〜=“ stuff”]，[attribute ^ =“ stuff”]等具有令人讨厌的表现。
供您参考， 前者在台式机上的性能可比后者高5倍，在移动网络视图中可提高10倍。 如果您不相信我，可以发起压力测试。
并且不要忘记，我们在电子书上要多付一些费用，即额外的RS层，这可能是一个令人讨厌的JavaScript文件和一个默认的CSS。 而且，如果移动应用使用的是Webview，这是要考虑的一个额外因素：性能不断提高，但很容易搞砸。 不幸的是，您可能会成为附带损害的受害者……
因此，总而言之， 利用级联来发挥自己的优势并设计可重用的类 ，不要重复自己，也不要将类“作用”于诸如InDesign输出之类的标签上。 期。
不要使用
[class =“ stuff”] {…}
[epub | type〜=“ stuff”] {…}
如果不需要的话 不要过分选择器，例如
.class> ol.class> li {…}
如果可能的话。
当然，这取决于您如何使用它们，一些例外不会有很大的不同，但是如果您的整个CSS是围绕这些选择器设计的，那么一旦瓶颈堆积起来，它们就会大大削弱性能 。
然后是属性和值…
如果您想破坏旧版RMSDK的性能，那么确定浮动和不透明度是最可靠的支持。
xhtml文件中的浮点数或不透明度太多，因此可能需要4到5秒钟才能在不太旧的eInk Reader中翻页 。 我不拉你 不用说这是糟糕的UX。
最后，如果您喜欢CSS 3动画，请阅读此HTML5rocks教程。 TL; DR：使用变换（+不透明度）以实现高性能，避免道具影响布局（不良）和绘制（最差）。
这导致我们……互动的东西。
JS瓶颈
再次提醒您，RS可能是一大堆JavaScript，这意味着您的脚本会影响它们的脚本。
结果，很容易通过显示/隐藏内容来在可重排的文本中实现糟糕的性能-无论如何，这在供应商的规范中不建议使用，因为他们没有预见到需要在作者一级更新分页…。
如我们所见，重涂很昂贵。 如果您可以在不影响道具重绘 （颜色，可见性，背景等）的情况下实现它 ，则只需执行 …即使它意味着重新设计小部件以使其以不同的方式工作。 否则，请尝试重涂。 检查您的效果预算！
至于JavaScript…
如果您知道JavaScript并且可以不用jQuery或插件就可以使用，请使用普通JavaScript。 说真的
首先，请不要忘记jQuery是附加的抽象层：您不是在操纵原始DOM元素，而是在操纵jQuery对象。 因此，根据RS的实现，您可能必须处理两个嵌套的抽象层。 并且这可以产生明显的变化-是否想过为什么iBooks开发人员提供特定的iBooks.js框架？
其次，JavaScript现在非常好用（只需看一下ES 2015），它是避免性能问题的最佳方法-只要不造成内存泄漏即可。 事实上，基于我们在电子书中最常做的事情，很少有人赞成jQuery。并且，不，您对学习JavaScript的渴望并不是一个可靠的论点，尤其是因为它会大大提高您的生产率。
一旦开始为页面上的大量元素设置动画并加载了整个怪异的jQuery lib +一个插件，我就可以保证某些应用程序甚至无法继续绘画 。
另外，不要在每个XHTML文件中重复脚本（不会被缓存），如果没有必要，也不要强制进行手动初始化。 您将节省几毫秒，这可能会在预算有限的RS中带来明显的不同。
如果您确实需要jQuery，请加载自定义子集， 因为这是一个额外的250 Kb未分配子集。 而且不要忘了缩小 。 还是尝试其他框架？
结论
所有这些建议都是相对的 。 这一切都取决于您的性能预算和用户的感知 。 我知道优化需要很多时间，而您不一定会花很多时间…因此，可以说，只要感觉流畅就可以。
用户的看法也是为什么您应该在各种设备上（从低端到高端）进行全面测试的原因。 但是，不要落入为单个RS实施的陷阱，如果您不像疯子一样优化JS，iBooks就很容易在第一代Retina设备上崩溃，这是众所周知的……您可能不会注意到它。
为了所有人的利益，应该重复执行此操作，在iBooks或ADE / Readium台式机中获得的性能并不是在任何地方都能获得的性能。
我们都知道-至少我希望我们都知道-我们应该优化（图像和SVG）子集（字体）并最小化（JS和CSS），因为“这是最佳实践”。 但是，性能不仅仅是细分和缩小， 它在设计和实现时要牢记性能 。
如果您的CSS和JS设计不当，缩小功能将无济于事。 如果只是为了切换类而加载jQuery，则子集jQuery将无济于事，这对于普通的旧JavaScript来说并不困难-在文档中获取元素，添加eventListeners，在classList中进行切换。
性能不是事后的想法，而是主要目标。 我希望我已经说服您，您应该关心。
