您现在的位置：尚易科技 >> 新闻资讯 >> 技术前沿 >> 浏览文章

.net网站SEO优化为以下分享：

1.减少往返行程(Reduce Round Trips)

　　使用下面的方法可以减少Web服务器和Browser之间的往返行程：

　　(1)为Browser启用缓存

　　如果呈现的内容是静态的或变化周期较长，应启用Browser缓存，避免发出冗余的http请求。

　　(2)缓冲页面输出

　　如果可能，则尽量缓冲页面输出，处理结束后再一次传送到客户端，这可以避免频繁传递小块内容所造成的多次网络交互。由于这种方式在页面处理结束之前客户端无法看到页面内容，因此如果一个页面的尺寸较大的话，可考虑使用Response.Flush方法。该方法强制输出迄今为止在缓冲区中的内容，你应当采用合理的算法控制调用Response.Flush方法的次数。

　　(3)使用Server.Transfer重定向请求

　　使用Server.Transfer方法重定向请求优于Response.Redirect方法。原因是Response.Redirect会向Broswer回送一个响应头，在响应头中指出重定向的URL，之后Brower使用新的URL重新发出请求。而Server.Transfer方法直接是一个简单的服务端调用，完全没有这些开销!

　　需要注意Server.Transfer有局限性：第一，它会跳过安全检查;第二，只适用于在同一Web应用内的页面间跳转。

　　2.避免阻塞和长时间的作业

　　如果需要运行阻塞或长时间运行的操作，可以考虑使用异步调用的机制，以便Web服务器能够继续处理其它的请求。

　　(1)使用异步方式调用Web服务和远程对象

　　只要有可能就要避免在请求的处理过程中对Web服务和远程对象的同步调用，因为它占用的是的ASP.NET 线程池中的工作线程，这将直接影响Web服务器响应其它请求的能力。

　　(2)考虑给不需要返回值的Web方法或远程对象的方法添加OneWay属性

　　这种模式能让Web Server调用之后就立即返回。可根据实际情况决定是否使用这种方法。

　　(3)使用工作队列

　　将作业提交到服务器上的工作队列中。客户端通过发送请求来轮询作业的执行结果。

　　3.使用缓存

　　缓存能在很大程度上决定ASP.NET应用的最终性能。Asp.net支持页面输出缓存和页面部分缓存，并提供Cache API，供应用程序缓存自己的数据。是否使用缓存可考虑下面的要点：

　　(1)识别创建与访问代价较大的数据

　　(2)评估需要缓存数据的易变性

　　(3)评估数据的使用频次

　　(4) 将要缓存数据中易变数据和不变数据分离，只缓存不变数据

　　(5)选择合适的缓存机制(除Asp.net Cache外，Application state和Session state也可以作为缓存使用)

　　4.多线程

　　(1)避免在请求处理过程中创建线程

　　在执行请求的过程中创建线程是一种代价较大的操作，会严重影响Web Server的性能。如果后续的操作必须用线程完成，建议通过thread pool来创建/管理线程。

　　(2)不要依赖线程数据槽或线程静态变量

　　由于执行请求的线程是ASP.NET thread pool中的工作线程，同一个Client的两次请求不一定由相同的线程来处理。

　　(3)避免阻塞处理请求的线程

　　(4)避免异步调用

　　这和1的情况类似。异步调用会导致创建新的线程，增加服务器的负担。所以，如果没有并发的作业要执行，就不要执行异步调用。

　　5.系统资源

　　(1)考虑实现资源池以提升性能

　　(2)明确地调用Dispose或Close释放系统资源

　　(3)不要缓存或长时间占用资源池中的资源

　　(4)尽可能晚的申请，尽可能早的释放

　　6.页面处理

　　(1)尽量减小Page的尺寸

　　包括缩短控件的名称、CSS的class的名称、去掉无谓空行和空格、禁用不需要的ViewState

　　(2)启用页面输出的缓冲区(Buffer)

　　如果Buffer的机制被关闭，可以用下面的方法打开。

　　使用程序打开页面输出缓存：

　　Response.BufferOutput = true;

　　使用@Page开关打开页面输出缓冲机制：

<％@ Page Buffer = "true" ％>

 

　　使用Web.config或Machine.config配置文件的 节点：

　　(3)利用Page.IsPostBack优化页面输出

　　(4)通过分离页面的不同的内容，来提高缓存效率和减少呈现的时间

　　(5)优化复杂和代价较大的循环

　　(6)合理利用客户端的计算资源，将一些操作转移到客户端进行

　　7.ViewState

　　ViewState是Asp.net为服务端控件在页面回传之间跟踪状态信息而设计的一种机制。

　　(1)关闭ViewState

　　如果不需要跟踪页面状态，例如页面不会 回传(PostBack)、不需要处理服务端控件事件或者每次页面刷新时都会重新计算控件内容，那么就不需要用ViewState来记录页面状态了。可以对特定的WebControl设置EnableViewState属性，也可以在页面一级设置：

<％@ Page EnableViewState="false" ％>

 

　　(2)在恰当的时间点初始化控件属性

　　ASP.NET的控件在执行构造函数、初始化的期间设置的属性不会被跟踪变化;而在初始化阶段之后对属性的修改都会被跟踪，并最终记录到IE页面的__VIEWSTATE之中。所以，选择合理的初始化控件属性的执行点，能有效的减小页面尺寸。

　　(3)谨慎选择放到ViewState中的内容

　　放到ViewState中的内容会被序列化/反序列化，Asp.net为String、Integer、Boolean等基本类型的序列化做了优化，如果Array、ArrayList、HashTable存储的是基本类型效率也较高，但其它类型则需要提供类型转换器(Type Converter)，否则将使用代价昂贵的二进制序列化程序。

　　总结：光有了这些技术方法还不够，还需要将这些方法根据你网站的情况灵活运用，适时调整方法，集中解决重要问题，这有这样网站性能才能得到大幅度的优化。

　　

　　8.使用缓存

1、使用Output Cache缓存数据

提供缓存功能是ASP.net中非常强大的一种功能。曾看到过某些评测说：ASP.net程序的性能比SUN的JSP应用程序性能快上几倍，实际上，该评测程序非常重要的一点就是使用了很多ASP.net的缓存功能。

　　如果你的组件是要在Asp.net应用程序中运行，你只要把System.Web.dll引用到你的项目中就可以了。然后用HttpRuntime.Cache属性就可访问Cache了（也可以通过Page.Cache或HttpContext.Cache访问）。

　　有以下几条缓存数据的规则。第一，数据可能会被频繁的被使用，这种数据可以缓存。第二，数据的访问频率非常高，或者一个数据的访问频率不高，但是它的生存周期很长，这样的数据最好也缓存起来。第三是一个常常被忽略的问题，有时候我们缓存了太多数据，通常在一台X86的机子上，如果你要缓存的数据超过800M的话，就会出现内存溢出的错误。所以说缓存是有限的。换名话说，你应该估计缓存集的大小，把缓存集的大小限制在10以内，否则它可能会出问题。在Asp.net中，如果缓存过大的话也会报内存溢出错误，特别是如果缓存大的DataSet对象的时候。

　　这里有几个你必须了解的重要的缓存机制。首先是缓存实现了“最近使用”原则（ a least-recently-used algorithm），当缓存少的时候，它会自动的强制清除那些无用的缓存。其次 “条件依赖”强制清除原则（expiration dependencies），条件可以是时间，关键字和文件。以时间作为条件是最常用的。在asp.net2.0中增加一更强的条件，就是数据库条件。当数据库中的数据发生变化时，就会强制清除缓存。

　　使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代码清除和垃圾回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。

切记：

应该：
应该缓存那些经常被访问、同时变化频率不大的数据
应该缓存整个应用程序都要使用的设置或对象，但这些设置和对象必须在其生存期内不会变化
不应该：
不要缓存个人信息。如果缓存个人信息，其他人很容易取得这些信息。
不要缓存包含基于时间值的页面，否则浏览者将无法理解为何时间总是滞后。
不要缓存用户随时都会修改的对象，如购物车。

9.ASP.net中常用的缓存方式有：

1）页面缓存(对整个页面进行缓存)

<%//Response.AddHeader("Last-Modified", DateTime.Now.AddHours(-1).ToString("r"));%>
<% Response.AddHeader("Cache-Control", "max-age=86400"); %>
<%//Response.AddHeader("Date", DateTime.Now.AddMinutes(-59).ToString("r"));%>

<%@Page OutputCache VaryByParams=”classid;page” Duration=”3600” %>

.net2.0中为：
<%@OutputCache VaryByParam=”classid;page” Duration=”3600” %>

你就可以有效的利用第一次请求里生成的页面输出缓存内容，3600秒后重新生成一道页面内容。这种技术其实也是运用一些低层的Cache API来实现。用页面输出缓存有几个参数可以配置，如上面所说的VaryByParams参数，该参数表示什么时候触发重输出的条件，也可以指定在 Http Get或Http Post 请求模式下缓存输出。

例如当我们设置该参数为VaryByParams=”classid;page”的时候，default.aspx?classid=3&page=1 请求的输出都会被缓存起来。没有参数，或不用参数时用none。如果传递的参数不止一个，那么即使字符串参数与值都相同，但排列次序不同，那么在请求页面时，也将生成不同的缓存页。例如default.aspx?first=1&last=1 和default.aspx?last=1&first=1虽然参数完全相同，但由于排列次序不同，将生成两个不同的缓存页。

　　许多人都没有意识到当用页面输出缓存的时候，asp.net也会生成HTTP头集（HTTP Header）保存在下游的缓存服务器中，这些信息可以用于Microsoft Internet安全性中以及加速服务器的响应速度。当HTTP缓存的头被重置时，请求的内容会被缓在网络资源中，当客户端再次请求该内容时，就不会再从源服务器上获得内容了，而直接从缓存中获得内容。

　　虽然用页面输出缓存不提高你的应用程序性能，但是它能减少了从的服务器中加载已缓存页面内容的次数。当然，这仅限于缓存匿名用户可以访问的页面。因为一旦页面被缓存后，就不能再执行授权操作了。

2）片断缓存(对页面的某一部分,如某个User Control进行缓存)

<%@ OutputCache Duration="60" VaryByParam=”TextBox1;TextBox2” %>

在ASP.net中，除了在页面范围内使用缓存，也还可以针对User Control使用Output Cache参数实现对用户控件的缓存。同样的，一个页面中相同类型的控件也可以有多个不同的缓存。可以根据参数来实现不同的缓存。页面缓存和片断缓存可以同时使用。

3）数据缓存

数据缓存是一种强大而又非常简单的缓存机制，它可以在缓存区中为每个应用程序保存各种对象，这些对象可以根据http的请求被调用，但是在各个不同的应用程序中这些对象都是私有的。
数据缓存是通过Cache类来实现的。当应用程序建立时，一个Cache类就同时被建立，缓存实例的生存周期就是应用程序的生存周期，它会随着应用程序的重新运行而重建，通过Cache类的方法，我们可以将数据对象放入缓存区，然后通过关键字匹配寻找并使用这些对象。
Cache类通过一个借口来控制所有需要缓存的内容，包括规定缓存的时间和缓存方式，可以通过如下方法添加缓存对象：

最后要注意：
在Web Form调试期间不能使用缓存，否则你对页面所做的修改在缓存过期之前不会得到显式加载。正确的做法应该是在调试结束之后，给需要放入缓存的页面、用户控件或对象加上缓存指令。最后建立部署和安装项目，生成安装数据包，这时候就可以到服务器上去发布你的产品了。

2、预请求缓存

　　虽然Cache API设计成用来保存某段时间的数据，而预请求缓存只是保存某个时期的某个请求的内容。如果某个请求的访问频率高，而且这个请求只需要提取，应用，修改或者更新数据一次。那么就可以预缓存该请求。我们举个例子来说明。

　　在CS的论坛应用程序中，每一个页面的服务器控件都要求得到用于决定它的皮肤（skin）的自定义的数据，以决定用哪个样式表及其它的一些个性化的东西。这里面的某些数据可能要长时间的保存，有些时间则不然，如控件的skin数据，它只需要应用一次，而后就可以一直使用。

　　要实现预请求缓存，用Asp.net 的HttpContext类，HttpContext类的实例在每一个请求中创建，在请求期间的任何地方都可以通过HttpContext.Current属性访问。HttpContext类有一个Items集合属性，在请求期间所有的对象和数据都被添加到这个集合中缓存起来。和你用Cache缓存访问频率高数据一样，你可以用HttpContext.Items缓存那些每个请求都要用到的基础数据。它背后的逻辑很简单：我们向HttpContext.Items中添加一个数据，然后再从它里面读出数据。

五、配置web.config

1、一定要禁用调试模式

　　在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调试模式，应用程序的性能可能受到非常大的影响。

<compilation defaultLanguage="c#" debug= "false" / >

2、必要时调整应用程序每个辅助进程的线程数

　　ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。

　　当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。

　　为缓和这种情况，可以通过更改 Machine.config 配置文件 <processModel> 节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。

注意 辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。
分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。

　　注意 进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。

 

4、 其他

　　根据适当的请求和响应编码设置来配置应用程序。ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。

　　 考虑对应用程序禁用 AutoEventWireup。在 Machine.config 文件中将 AutoEventWireup 属性设置为 false，意味着页面不将方法名与事件进行匹配和将两者挂钩（例如 Page_Load）。如果页面开发人员要使用这些事件，需要在基类中重写这些方法（例如，需要为页面加载事件重写 Page.OnLoad，而不是使用 Page_Load 方法）。如果禁用 AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性能提升。

　　 从请求处理管线中移除不用的模块。默认情况下，服务器计算机的 Machine.config 文件中 <httpModules> 节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的需要自定义它。

例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从 <httpModules> 列表中移除它们，以便请求在不执行其他有意义的处理时，不必执行每个模块的进入和离开代码。