尽管前面已经提到了一些设计时应该规避的情况，但即使完全掌握了这些也不能高枕无忧。因为在现实中，经常会有一些用户需求会强迫我们冒着性能风险去挑战那些危险的极限。因此我们需要通过制订或调整开发规范来为性能增加一道保障。
先来了解一下现状：
设计人员的设计不当很少会引起服务端的性能出现问题，服务端的性能问题大都与实现方式有关，因此本章节基本没有涉及到服务端的讨论。
对于客户端而言，主要影响因素就是上面大量讨论到的网络大小和页面复杂度两个各方面。其中网络大小对传输耗时的影响并不难推算，但是页面复杂度和初始化耗时之间的关系是很难量化的。因为初始化耗时与页面的布局方式、控件类型、数据量、页面逻辑等都有着的密切的关系，这些因素间的组合关系十分错综复杂。
解决方法：
要弥补初始化耗时难以估算的弊端，也许只能采取一些制度上的措施了。首先设计人员最好能够提出每个页面的期望性能指标，然后强调开发人员对页面初始化和某些功能按钮的耗时进行测试，并考虑在开发制度中规定，须将测试结果连同程序代码一同作为开发成果提交，利用这份的测试结果不断的对期望性能指标进行落实。这将非常有利于提前发现一些可能存在的性能隐患。
注意，设计人员提出的期望性能指标往往是包含服务端的耗时的，而我们认为要求开发人员在开发阶段对服务端的耗时进行测试统计的意义并不大。因为服务端的运行时间同最终的并发量和服务器硬件环境密切相关，要求开发人员在开发阶段对最终的服务端耗时进行的推测是不切实际的。因此，我们的建议是不必在开发阶段太过在意服务端的耗时，只统计网络传输耗时和客户端耗时。按照期望性能的75%同前两项的总和进行比对。
例如：如果我们期望最终的响应时间是3秒钟，那么网络传输耗时和客户端耗时之和就应该控制在2.25（3 * 75%）秒以内。
对于不同类型的操作，我们可能需要调整这里的乘数。服务端的处理主要都是消耗在数据库操作上。因此，对于数据库操作较密集的场景，例如查询、提交保存等，我们需要下调参数为60%甚至更低；而对于数据库操作较少的场景，如新增页面的打开、查询页面的打开等，我们可以上调参数为85%甚至更高。
设计人员给出的期望值应包括下列的信息：
- 参照客户机的基本配置，主要指CPU的类型和主频。此项可能对于整个系统而言是统一的。
- 参照网络带宽。此项可能对于整个系统而言是统一的。
- 用户可忍耐的响应时间上限。可能没有必要给出期望的响应时间，谁都希望越快越好，不是吗？
- 该功能可能的并发量。
开发人员提交的测试结果应包括下列的信息：
- 开发用客户机的基本配置，主要指CPU的类型和主频。
- 页面的初始化耗时。可利用Dorado的客户端调试器得知。
- 部分可能较繁重的操作的耗时，主要是指带有提交或数据刷新功能的操作。测试方法可参考3.1.2节中的介绍。
- 网页大小。测试方法可参考3.1.3节中的介绍。