我想稍微使用dotnetnuke框架的DNNer都知道DNN运行速度是一个瓶颈，尽管框架一直在优化的努力中，从版本2.x到3.x，再到如今的4.6.x，性能已经有了质的飞跃，这是值得欢欣的。但我们也看到，由于一开始就引入了skin动态加载的机制及其模块插件化的模式等等，致使性能有所影响，特别是对于我们国内带宽不是特别充裕的用户来说，访问一个很一般的DNN网站也是极其难受的，可能一开始一片空白，过了几分钟突然所有的内容和图像冒出来，让你觉得很难接受如此蜗牛的加载速度.在此我冒昧以我个人的经验及其论坛的一些成型的做法罗列一些建议，希望对比较关注DNN性能的DNNer有所启发和帮助:
(一)由于最先核心模块为了简单方便，在页面数据绑定上都一致使用了后期绑定反射来呈现数据信息,比如
"<%# Databinder.Eval(Container.DataItem, "Name") %>"
但同时我们也要看到这其中的利和弊,DataBinder.Eval很方便，它是ASP.NET Framework 提供的一种静态方法，计算后期绑定的数据绑定表达式并且可选择将结果格式化为字符串,使用它可消除了开发人员为强迫将值转换为所需的数据类型而必须做的显式转换。这在数据绑定模板列表内的控件时尤其有用，因为通常数据行和数据字段的类型都必须转换。但是 DataBinder.Eval 会对标准数据绑定语法带来很明显的性能损失，因为它使用后期绑定反射,只有在运行时才对所绑定的数据及其参数作绑定检查，也就是说如果你所绑定的对象类型如果出现错误，那也只有等你运行之后才能知道你需要的错误信息，而在编译时你是不清楚的. 故此时使用标准数据绑定语法显示绑定数据无疑是最好的选择。
例如
<%# DataBinder.Eval(Container.DataItem, “yourField”,“{0:c}”) %>
等价的显示绑定表达式为:
<% #String.Format(“{0:c}”,(CType(Container.DataItem,DataRowView)(“yourField”))) %>
(二)尽量只开启必要的调度任务，比如你不需要搜索功能，那就把SearchEngineScheduler这个调度任务屏蔽了，毕竟后台运行这一任务也会影响前台性能。调度任务可在主机管理下的调度任务找到设置信息.
(三)最小化skin文件.抛弃庞大的图像和臃肿的表格排版方式，在web2.0下，无疑使用表格来排版会影响解析和加载时间(当然如果必要的话使用表格也是允许的，毕竟有时表格也有独特的优势，可实现div等很难实现的效果.).同时需要注意一下CSS样式的设计，避免冗余的重复定义，尽量简单明了，一个最基本的原则，同时也是显而易见的原则，那就是DNN的skin文件尽量要小于10k，当然如果可以，5k左右无疑是最佳的做法。把portal.css(DNN默认样式文件)大小归零也是明智的.