前言
在开发中为了紧赶项目进度而未去关注性能的问题，在项目逐渐稳定下来后发现性能令人感到有点忧伤，于是开始去关注这方面，本篇为记录在开发中遇到的问题并解决，不喜勿喷。注意：以下问题都是在移动端上出现，无法确定在网站中是否也同样会出现。
卡顿问题
请求方式
项目属于移动端，在手机上查看某一列表时并进行向下滑动时经常性卡顿问题，滚动的插件采用的是iscroll，当然怀疑是不是这个插件问题，但是很快就排除了这个问题，在其他页面未出现这个问题，后来接着想因为在脚本中进行Ajax请求超时时间设置为30秒，是不是有可能请求接口耗时导致的呢，经过测试并查看日志文件也不是这个问题，于是我开始查看写的脚本文件，吓我一跳，在请求获取数据列表时，请求方式居然写的POST，这是同事所为，我改为GET后这样的问题得到了大大的改善，我询问同事为什么用POST而不用GET，他说了一句进行GET请求有问题出现错误，这时我才明白他指的是什么，在MVC中在进行GET请求获取JSON数据时，需要进行如下设置：
return Json("",JsonRequestBehavior.AllowGet);
建议：在进行Ajax请求时，是什么请求方式，请采取对应的方式来进行请求，要不然给出其他请求方式干嘛，吃饱了撑着吗！
路径问题
通过上述请求方式改善后问题得到一定的改善（评论也有指出不是这个导致快慢的问题，同意评论观点，应该是其他原因导致，还是觉得对应的请求采取对应的方式才是），但是还是存在问题，我们继续查看脚本，我们可能会经常这样做：我们将需要用到的一些脚本方法，比如格式日期转换，获取cookie等封装在一个公用脚本中来方便调用。下面我们进行演示下。
在脚本中进行请求时我们一般进行如下：
$(function () {
type: 'get',
url: "/home/Info",
data: {},
success: function () { },
dataType: "application/json"
});
});
但是同事却是这样做的，将请求路径写在公用脚本中如下：
var path = "/"
此时我们的请求就变成了这样：
$(function () {
$.ajax({
type: 'get',
url: path + "home/Info",
data: {},
success: function () { },
dataType: "json"
});
});
这样写肯定没错，但是事实时当我们改成了第一种时效率马上提上来了，而用第二种方式时会请求很长时间，方式不同，但是貌似没什么区别，至于原因我也不明白，为什么如同事那样写不行。
建议：当进行请求时，请直接写路径而不要上述那样，有时候在你看来，方式一样，却导致了不同的结果。
至此也就大致上解决了在手机上滑动时卡顿的问题，当然也不排除脚本写的有问题的情况。
缓存问题
在页面请求时为了那些不会改变的脚本或者数据从而加快页面加载速度，我们通常使用缓存来解决。
脚本、样式缓存
在进行请求时，有些不会改变的脚本我们需要进行缓存，而不是每请求一次而又重新加载一次，当然此时就有人想到了怎么样去缓存脚本的问题，比如如下：
<script src="~/Scripts/video.js?2016040901"></script>
在脚本文件后加上一段数字就ok了，是的确实是这么简单，当我们对脚本文件进行了修改再去改变下后面的数字即可，但是你有没有想过，如果项目中脚本文件多的数不胜数而且一旦你修改了大量的脚本文件，你还去页面中进行大量的更改，你不累吗，反正我会累死。而我想到的是将那些一些引入的脚本在后面直接加上数字肯定是没问题，因为这样的脚本我们基本不会去动了，例如引入jquery脚本（有些人可能会钻空子了，去修改也是有可能的），好吧，那我们统一一点诺：我们在配置文件中可以将其后面的数字作为我们去要修改的脚本，当我们修改了脚本直接改变配置文件中的版本不就得了，这样方便管理，一劳永逸，何乐而不为。我们下面来看看。
（1）我们在配置文件中添加修改的脚本版本（当然你可以随便写一串数字，下次修改了脚本直接改变其数字即可）
<add key="version" value="2016040901"/>
（2）接着我们写一个HtmlHelper的扩展方法，如下：
public static class FileHtmlHelper
{
private static readonly string s_version = ConfigurationManager.AppSettings["version"].ToString();
private static readonly string s_root = HttpRuntime.AppDomainAppPath.TrimEnd('\');
public static MvcHtmlString RefFileHtml(this HtmlHelper htmlHelper, string path)
{
string filePath = s_root + path.Replace("/", "\");
return new MvcHtmlString(string.Format("<script type="text/javascript" src="{0}?{1}"></script>
", path, s_version));
}
}
（3）此时我们在MVC视图页面进行如下调用脚本：
@Html.RefFileHtml("/Scripts/video.js")
这样我们就解决了脚本缓存以及方便管理的问题。
建议：在进行脚本缓存为了方便管理可以通过配置文件读取修改的版本进行管理脚本文件的缓存。样式缓存也是如此。
页面输出缓存
在MVC中我们可以对Action缓存，如下：
[OutputCache(Duration = 30)]
public ActionResult Cache()
{
return View();
}
那要是当我们有参数来达到缓存时，又该如何做呢？直接对整个页面所有请求的参数进行缓存，如下：
[OutputCache(Duration = 30,VaryByParam="*")]
public ActionResult Cache()
{
return View();
}
此上对JsonResult也是如此，当我们通过参数来筛选不变的列表时，此时我们完全可以将其进行缓存，此时我们明确的参数类型也就是自定义缓存。
我们通过配置文件来进行配置即可，如下：
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<add name="customProfile" duration="900" location="Server" varyByParam="UserId" />
</outputCacheProfiles>
</outputCacheSettings>
</caching>
在上述还有许多参数供你选择，选择你需要的缓存参数即可。
在控制器中我们只需添加自定义缓存名称即可：
[OutputCache(CacheProfile="customProfile"]
public JsonResult Info()
{
return Json(new { result = "ok" }, JsonRequestBehavior.AllowGet);
}
注意：上述caching节点是位于system.Web节点下，而非system.webServer节点下。
配置文件修改以及其他
（1）删除不需要的httpModules，如下：
<httpModules>
<remove name="Session"/>
<remove name="RoleManager"/>
<remove name="PassportAuthentication"/>
<remove name="Profile"/>
<remove name="ServiceModel"/>
</httpModules>
（2）由于利用表单验证，也可以删除如下httpModules
<httpModules>
<remove name="WindowsAuthentication"/>
<remove name="FileAuthorization"/>
</httpModules>
（3）在IIS上启用压缩，压缩响应结果减少网络传输时间。
苹果日期问题注意
当数据进行数据库存储时发现在安卓上存储成功，而在苹果上存储失败，这个问题纠结了很久，并查看日志文件最终发现苹果上对日期有特殊的格式传递，否则为空，于是利用js中的replace方法来进行替换。
date.replace("-", "/");
此时发现利用replace方法只能替换第一个横线，最终采用正则表达式全部替换并解决
date.replace(/-/g, "/");
注意：在苹果上日期进行传递时必须是如"2016/04/09"而不能为"2016-04-09"。
结语
部分参考来源：不修改代码就能优化ASP.NET网站性能的一些方法。
通过对问题的出现以及解决花费了一点时间，最终使得在手机上请求数据耗时得到大大的改善、页面加载的速度提高了许多以及滑动数据顺畅而由此告一段落。有些细小的问题平时不太注意，感觉各种方式都能实现，殊不知这样做的结果是否是一样，实现的结果一样，但是呈现出的效果却是天壤之别，实际开发中发现一些小的细节对整个项目的成败是多么的重要。
检讨：对于文中评论观点持认同，第一个对于请求方式这块应该是其他原因所导致，第二个对于协议这块确实需要更深入的了解和学习，感谢评论中的精彩回答，涨知识了，在此一并表示感谢。
转载自：http://www.cnblogs.com/CreateMyself/p/5353533.html