Optimizar el rendimiento de la página en SharePoint
Obtenga información sobre las características para mejorar el rendimiento de las páginas en SharePoint. Estas características se pueden usar para mejorar la experiencia en implementaciones distribuidas geográficamente.
Proporcionado por: David Crawford, Microsoft Corporation
Este artículo proporciona instrucciones que le ayudarán a optimizar el rendimiento de SharePoint. SharePoint incluye características que le ayudarán a optimizar la carga de página en una red de área extensa (WAN). El diseño de páginas de modo que se reduzca su tamaño y sean más eficaces complementa estas mejoras de rendimiento.
Estrategia de descarga mínima (MDS)
Estrategia de descarga mínima (MDS) se basa en la capacidad de descargar sólo partes específicas de una página que se representa totalmente en el servidor. Descargar sólo las partes específicas, proporciona un modelo de carga muy eficaz. La página representada totalmente no se devuelve al cliente. El servidor debe poder identificar con precisión los elementos que se deben formar parte de la respuesta y aquellos que no sean necesarios. Las piezas que pueden ser o no parte de la respuesta incluyen scripts, estilos y formato.
En la siguiente tabla se muestran algunas de las ventajas del uso de MDS.
Tabla 1. Ventajas del uso de MDS
| Rendimiento | Elementos visuales |
|---|---|
| Menos cantidades de datos descargados por solicitud de página. | Se elimina el parpadeo del explorador que se produce cuando se vuelve a cargar una página completa. |
| El explorador solo tiene que actualizar las regiones de la página que han cambiado desde la última solicitud. | Animaciones fáciles de identificar. |
| Poco procesamiento necesario por parte del cliente. Nota: La mitad del tiempo de carga de página 1 (PLT1) del cliente se debe a la representación de la hoja de estilos en cascada (CSS) de cromo y al análisis y ejecución de JavaScript. | Los cambios en la página atraen la atención del usuario. |
AJAX y MDS son tecnologías que solicitan sólo las secciones de la página a fin de minimizar datos descargar y mejoran la capacidad de respuesta de la página. En la siguiente figura muestra la arquitectura MDS.
Figura 1. Arquitectura de MDS
El marco de trabajo MDS se da por hecho que una página maestra define un cromo y áreas de contenido. En MDS, SharePoint navegar hasta una página significa que solicita sólo el contenido de las regiones y los recursos que depende de la página. Una vez que el contenido se descarga en el explorador, código de script aplica el formato o los recursos a la página según corresponda. El explorador se comporta como si la página solicitada hubiera cargado completamente desde el servidor.
Figura 2. Cromo de página y regiones en una página de SharePoint
Cuando los usuarios naveguen por un sitio Web de SharePoint en modo MDS, no provocarán la devolución de datos de página completa ni que se tenga que volver a cargar toda la página. En vez de eso, la dirección URL de la página que estén visitando seguirá siendo la misma y lo que cambiará será el identificador del fragmento (un signo "#") para contener esa página. El formato de la dirección URL es [Path to site (spweb)] + /_layouts/15/start.aspx# + [path to page] + [query string]
En la tabla siguiente se muestran algunos ejemplos de direcciones URL con formato en modo MDS.
Tabla 2. Direcciones URL con formato en modo MDS
| Direcciones URL que no están en modo MDS | DIRECCIÓN URL EN MODO MDS |
|---|---|
http://server/SitePages/ |
http://server/_layouts/15/start.aspx#/SitePages/ |
http://server/subsite/SitePages/home.aspx |
http://server/subsite/_layouts/15/start.aspx#/SitePages/home.aspx |
http://server/_layouts/15/viewlsts.aspx?BaseType=0 |
http://server/_layouts/15/start.aspx#/_layouts/viewlsts.aspx?BaseType=0 |
El objeto utilizado para la navegación de AJAX es AjaxNavigate. De forma predeterminada, hay una instancia de AjaxNavigate disponibles para su uso con nombre ajaxNavigate. Para usar la instancia de ajaxNavigate:
ajaxNavigate.update(serverRelativeURL, null);
Si desea un control o un elemento web para escuchar los eventos de navegación, puede usar el controlador add_navigate. Cuando se llama al controlador, la función de devolución de llamada recibe una referencia al objeto de navegación y los valores hash analizados en un diccionario. El control o el elemento web puede recuperar el valor del parámetro de interés del diccionario, compararlo con el valor actual y decidir qué acción debe tomar. Una acción común es enviar una solicitud de AJAX al servidor para recuperar datos o cambiar el orden de los elementos de la vista. Una vez finalizada la escuchan los eventos de navegación de un control, puede usar el controlador remove_navigate.
MDS también admite varias marcas de hash en pares clave/valor. MDS agrega las almohadillas después de la dirección URL. El formato de las almohadillas en la dirección URL es http://server/_layouts/15/start.aspx#/SitePages/page.aspx#key1=value1#key2=value2. En el ejemplo de código siguiente se muestra cómo actualizar las almohadillas.
var updateParts;
updateParts = {key1: "value1", key2: "value2", keyn: "valuen"}
ajaxNavigate.update(null, updateParts);
Si observa que las páginas de su sitio Web constantemente retroceden para descargar la página completa, es posible que desee considerar posibilidad de desactivar la característica MDS. También es posible que desee desactivar la característica MDS si necesita usar una estrategia diferente para mejorar el rendimiento.
Un elemento determinado de la página debe asegurarse de que se conocen los recursos críticos necesarios para que funcione a la infraestructura MDS en tiempo de representación de servidor. Para convertir un proyecto existente para usar MDS, tiene que actualizar los archivos y los componentes siguientes:
- Páginas principales
- Páginas ASP.NET
- Páginas maestras personalizadas para los errores
- Archivos JavaScript
- Controles y elementos web
Páginas principales
El cambio principal en la página maestra es encerrar las regiones de marcado HTML que se van a enviar al cliente con un control especial denominado SharePoint:AjaxDelta. Los elementos más comunes que deben estar encerrados entre un control de SharePoint:AjaxDelta son los controles incrustados en el cromo de página maestra y los marcadores de posición de contenido. Si un control es el mismo en todas las páginas de un sitio, no deben estar contenido en un control de SharePoint:AjaxDelta. El siguiente marcado muestra un marcador de posición de contenido visible rodeado por un control SharePoint:AjaxDelta.
<SharePoint:AjaxDelta
id="DeltaPlaceHolderMain"
IsMainContent="true"
runat="server"
>
<asp:ContentPlaceHolder id="PlaceHolderMain" runat="server" />
</SharePoint:AjaxDelta>
Controles que tienen contenido depende de la dirección URL actual deben ajustarse en un control de SharePoint:AjaxDelta. El siguiente marcado muestra un menú rodeado por un control SharePoint:AjaxDelta.
<SharePoint:AjaxDelta id="DeltaBreadcrumbDropdown" runat="server">
<SharePoint:PopoutMenu
runat="server"
ID="GlobalBreadCrumbNavPopout"
IconUrl=IMGCLUSTER_FG_IMG
IconAlt=LOC_ATTR_WSS(master_breadcrumbIconAlt)
IconOffsetX=IMGCLUSTER_FG_LEFT(BREADCRUMBBUTTON)
IconOffsetY=IMGCLUSTER_FG_TOP(BREADCRUMBBUTTON)
IconWidth=IMGCLUSTER_FG_WIDTH(BREADCRUMBBUTTON)
IconHeight=IMGCLUSTER_FG_HEIGHT(BREADCRUMBBUTTON)
AnchorCss="s4-breadcrumb-anchor"
AnchorOpenCss="s4-breadcrumb-anchor-open"
MenuCss="s4-breadcrumb-menu">
</SharePoint:PopoutMenu>
</SharePoint:AjaxDelta>
Nota:
[!NOTA] El control de SharePoint:AjaxDelta no debería estar anidado dentro de sí mismo. Especifique este control en el nivel más alto requerido.
Si necesita incluir un archivo (CSS) de la hoja de estilos en cascada, debe utilizar los controles de SharePoint: CssLink y SharePoint:CssRegistration. Estos controles se han actualizado para que funcione en modo MDS y no son MDS. El marcado siguiente muestra cómo usar los controles de SharePoint: CssLink y SharePoint:CssRegistration.
<SharePoint:CssLink runat="server" Version="15" />
<SharePoint:CssRegistration Name="my_stylesheet.css" runat="server" />
Precaución
[!PRECAUCIóN] Puede tener solo un control de SharePoint: CssLink por página. En el modo MDS, obtendrá un error si tiene más de un control de SharePoint: CssLink en una página. No se admite la inclusión de un archivo CSS mediante un elemento de estilo HTML en el modo MDS, debido a que la lógica del servidor no puede identificar el archivo como un recurso necesario cuando se procesa la respuesta.
Para incluir un archivo JavaScript, use el control de SharePoint: ScriptLink. El marcado siguiente muestra cómo usar el control de SharePoint: ScriptLink.
<SharePoint:ScriptLink
language="javascript"
name="my_javascriptfile.js"
runat="server"
/>
Precaución
No se admite la inclusión de un archivo de JavaScript con la etiqueta de secuencia de comandos HTML en el modo MDS, debido a que la lógica del servidor no puede identificar el archivo como un recurso necesario cuando se procesa la respuesta.
Para representar el elemento de título dentro del elemento head en la página, se usa un patrón especial mediante el control de SharePoint:PageTitle. El marcado siguiente muestra cómo usar el control de SharePoint:PageTitle.
<SharePoint:PageTitle runat="server">
<asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" />
</SharePoint:PageTitle>
Nota:
Cada página individual debe invalidar el título mediante un reemplazo para el control asp: ContentPlaceHolder dentro del control SharePoint:PageTitle.
Páginas ASP.NET
Para incluir un archivo CSS o de JavaScript, use los mismos controles de SharePoint: ScriptLink y SharePoint: CssLink que se describe en la sección anterior.
En versiones anteriores de SharePoint, algunas páginas escribir contenido mediante el uso de la propiedad Response.Output. Si usa MDS, ya no está permitido. Debe cambiar las llamadas a Response.Output a usar una nueva API. En la siguiente tabla muestra las API que se usan con frecuencia en páginas de SharePoint y la nueva API compatible con MDS.
Tabla 3. API usadas con más frecuencia y sus alternativas compatible con MDS
Si una página, un control o un elemento web dirige los resultados a la propiedad Response.Output, se volverán a producir errores en MDS. Cuando estos errores en MDS ocurren, se realiza una navegación completa a la página solicitada. Puede encontrar el control afectado mediante el uso de la propiedad DeltaPage ._shipRender durante la depuración del componente de servidor.
Debe reemplazar los elementos de secuencia de comandos HTML en línea con los controles de SharePoint:ScriptBlock. A continuación se muestra un elemento de secuencia de comandos HTML en línea y su alternativa compatible con MDS: el control de SharePoint:ScriptBlock.
Elemento de secuencia de comandos HTML en línea
<script type="text/javascript"> // Your JavaScript code goes here. </script>Alternativas compatibles con MDS
<SharePoint:ScriptBlock runat="server"> // Your JavaScript code goes here. </SharePoint:ScriptBlock>
La introducción de la SharePoint:ScriptBlock en la página puede cambiar el ámbito de las variables en la página. En ocasiones es necesario mover la declaración de variables de <% %> a <script runat="server"> <script>. Para probar esto, cargue la página en el explorador después de realizar las actualizaciones.
Nota:
[!NOTA] La infraestructura MDS no admite VBScript, debido a no se puede registrar como una secuencia de comandos en ASP.NET. Secuencias de comandos tienen que va a convertirse a JavaScript.
Los hipervínculos en las páginas ASP.NET deben actualizarse para usar el tipo SPUpdatePage. A continuación se muestran hipervínculos en páginas ASP.NET y los mismos vínculos actualizados con el tipo SPUpdatePage.
Hipervínculo en ASP.NET
<a id=<%_STSWriteHTML("viewlist" + spList.BaseTemplate.ToString());%> href=<%_STSWriteURL(listViewUrl);%> .. </a>Alternativas compatibles con MDS
<a id=<%_STSWriteHTML("viewlist" + spList.BaseTemplate.ToString());%> href=<%_STSWriteURL(listViewUrl);%> onclick="if (typeof(SPUpdatePage) !== 'undefined') return SPUpdatePage(this.href);"> .. </a>
Páginas maestras personalizadas para los errores
Puede mostrar mensajes de error en el modo MDS, incluso cuando se usa una página maestra personalizada para errores. Para usar una página maestra personalizada para errores en modo MDS, debe definir un AjaxDelta en la página maestra de error que tiene la propiedad id establecida en la cadena "DeltaPlaceHolderMain". El contenido del mensaje de error se debe representar en el AjaxDelta. Cuando la página de error se devuelve al explorador desde el servidor, el explorador lo identifica como el contenido principal para mostrar y lo muestra al usuario.
Aunque la página principal de la página de error y la página maestra para start.aspx no son una coincidencia explícita, puede detectar el explorador que se ha producido un error. El explorador permite MDS usar el contenido del mensaje de error pertinente dentro de la página principal existente con el fin de mantener una experiencia de usuario coherente y uniforme.
Archivos JavaScript
archivos de JavaScript deben incluir sólo las declaraciones de función. Sin embargo, hay muchas secuencias de comandos heredados que contienen las inicializaciones de variables globales. Las variables globales necesitan reinicializar cuando se procesa una página nueva en modo MDS. Puede usar el ExecuteAndRegisterBeginEndFunctions para inicializar variables globales. En el ejemplo de código siguiente se muestra cómo utilizar el ExecuteAndRegisterBeginEndFunctions.
function ExecuteAndRegisterBeginEndFunctions(tag, beginFunc, endFunc, loadFunc)
El ExecuteAndRegisterBeginEndFunctions tiene los siguientes parámetros:
- tag: el nombre del archivo que registra las devoluciones de llamada; se utiliza únicamente con fines de depuración.
- beginFunc: una función que se llama antes de solicitar la diferencia de la página.
- endFunc: una función que se llama después de recuperar el delta, pero antes de aplicar el código HTML y JavaScript para la nueva página.
- loadFunc: una función que se llama una vez que el código HTML y JavaScript se ha aplicado a la nueva página.
Controles y elementos web
Para usar MDS, controles y elementos web, se deben registrar los recursos de la página mediante el objeto SPPageContentManager. Los recursos registrados más frecuentemente con SPPageContentManager son fragmentos de código JavaScript (funciones o variables JSON) y campos ocultos. En la siguiente tabla se muestran patrones comunes para insertar los campos ocultos y fragmentos de JavaScript y cómo hacer lo mismo utilizando el objeto SPPageContentManager.
Tabla 4. Procedimientos habituales para representar el contenido y sus alternativas compatibles con MDS
| Procedimientos habituales para representar el contenido | Alternativas compatibles con MDS |
|---|---|
output.Write("<input type=\\"hidden\\" name=\\"");output.Write(SPHttpUtility.NoEncode("HiddenField));output.Write("\\" value=\\"");output.Write(DigestValue);output.Write("\\" />"); |
SPPageContentManager.RegisterHiddenField(this, "HiddenField", DigestValue); |
Page.ClientScript.RegisterClientScriptBlock(typeof(MyType), "MyKey", "var myvar=1", true); |
SPPageContentManager.RegisterClientScriptBlock(this, typeof(MyType), "MyKey", "var myvar=1"); |
Nota:
Las funciones RegisterHiddenField y RegisterClientScriptBlock en el objeto SPPageContentManager esperan un objeto del tipo Control o página en el primer parámetro.
El motor MDS utiliza el primer parámetro para filtrar las secuencias de comandos. Aquí están las reglas de filtrado cuando se procesa una página en modo de delta MDS:
- Si el primer argumento es del tipo Página, las secuencias de comandos se ejecutarán en el explorador.
- Si el primer argumento no es del tipo Página y el control está incluido en SharePoint:AsyncDelta, los scripts se ejecutarán en el explorador.
- Si el primer argumento es un elemento web, las secuencias de comandos se ejecutarán en el explorador.
Muchas API en versiones anteriores de SharePoint no proporcionaban el control actual como argumento. El modelo de objetos público de SharePoint se diseñó para proporcionar un método alternativo para registrar los recursos. Los métodos que no proporciona el control actual como argumento siguen en la API para compatibilidad con versiones anteriores.
Puede navegar entre dos páginas mediante el uso de una nueva función denominada SPUpdatePage. Cuando se representa un control o elemento Web en modo MDS delta, los controles de HyperLink deben agregar el controlador de onclick y llamar a SPUpdatePage.
Debe actualizar el XSLT que usan los elementos web porque todos los recursos deben agregarse a través del objeto SPPageContentManager para que sean compatibles con MDS. Puede agregar fragmentos de código JavaScript a XSLT utilizando los métodos RegisterScriptLink y RegisterScriptBlock del objeto SPPageContentManager.
Optimizar las descargas de páginas
Una vez que comprenda la composición de una página, puede usar diferentes métodos para optimizar la experiencia de descarga de esta. En general, el objetivo es minimizar el número de recorridos entre los equipos del cliente y del servidor y reducir la cantidad de datos que viajan a través de la red. Las instrucciones de este artículo contienen recomendaciones generales que puede aplicar a gran variedad de implementaciones de SharePoint.
En la tabla 5 se muestran ejemplos de tiempos de carga que ilustran la diferencia entre la primera carga de página, la segunda y las posteriores.
Tabla 5. Tiempos de carga de página
| Hito | Duración |
|---|---|
| Primera carga de página | 3-4 segundos |
| Segunda carga de página | 15 segundos |
| Carga de páginas posteriores | 1 segundo |
Nota:
[!NOTA] Tiempos de carga pueden ser diferente en su escenario concreto. Tiempos de carga se ven afectados por muchas variables, incluidos, pero sin limitarse a, tamaño de página, la latencia y la carga del servidor.
Debe clasificar las técnicas de optimización de página en dos categorías: primera solicitud de página y siguientes solicitudes de página. Las optimizaciones para la primera solicitud de página (tiempo de carga de página 1 o PLT1) son los tipos de optimizaciones que son efectivos la primera vez que se solicita la página, pero que no necesariamente afectan a las solicitudes de página siguiente. Las siguientes son algunas optimizaciones para PLT1:
- Optimice el marcado HTML.
- Use imágenes y archivos; consolidados Por ejemplo, combine varios archivos CSS en uno. Combinar imágenes en una franja de imágenes o clúster.
- Utilice técnicas de compresión (análisis). Para obtener más información, vea Comprimir (compresión) JavaScript y los archivos CSS.
- Compruebe que hace referencia a la versión de producción de las bibliotecas de JavaScript comunes, como jQuery, en lugar de a las versiones de depuración.
- Considere el uso de una buena red de entrega de contenido (CDN) como la Red de entrega de contenido de Microsoft Ajax. Los archivos necesarios en las páginas ya pueden tener una caché por el explorador del cliente.
Optimizaciones para las solicitudes de página siguiente son las que pueden mejorar la experiencia del usuario para una carga de página siguiente. La clave es que necesita equilibrar pérdida en la funcionalidad contra la mejora de lograr. Si las ganancias sólo se experimentan la primera vez que un usuario visita un sitio, puede que la optimización no compense la pérdida de funcionalidad.
Comprimir (compresión) JavaScript y los archivos CSS
Archivos que contienen JavaScript y estilos podrán reducirse considerablemente en tamaño mediante la eliminación de los espacios en blanco, la herencia de estilo y la reutilización de código. Algunas bibliotecas se incluyen en normal (depuración) y versiones comprimidas (eliminan). Puede encontrar una gran variedad de herramientas para automatizar la eliminación de archivo mediante la búsqueda de Internet.
Compruebe que las versiones comprimidas se implementan en servidores de producción. En este ejemplo se muestra cómo se puede reducir un archivo CSS en tamaño a través de algunos reconfiguración relativamente simple.
.article-ByLine {
font-family: Tahoma, sans-serif;
font-size: 9.5pt;
font-style: normal;
line-height: normal;
font-weight: normal;
color: #000000;
}
.article-Caption {
font-family: Tahoma, sans-serif;
font-size: 8pt;
font-style: normal;
line-height: normal;
font-weight: normal;
color: #000000;
}
.article-Headline {
font-family: Tahoma, sans-serif;
font-size: 14pt;
font-style: normal;
line-height: normal;
font-weight: bold;
color: #000000;
}
.article-SubHead {
font-family: Tahoma, sans-serif;
font-size: 11pt;
font-style: normal;
line-height: normal;
font-weight: normal;
color: #000000;
}
.article-Text {
font-family: Tahoma, sans-serif;
font-size: 10pt;
font-style: normal;
line-height: normal;
font-weight: normal;
color: #000000;
}
Normalmente puede encontrar maneras para lograr el mismo estilo y reducir el tamaño de los archivos mediante la reconfiguración de forma eficaz los archivos CSS. En el ejemplo siguiente se muestra cómo optimizar el tamaño CSS anterior mediante la herencia de los estilos de un elemento primario.
BODY {
font: 100% Tahoma, sans-serif;
}
.art-By {
font: 79%;
}
.art-Cap {
font: 67%;
}
.art-Head {
font: bold 117%;
}
.art-Sub {
font: 92%;
}
.art-Txt {
font: 83%;
}
La primera versión de CSS tiene 783 caracteres de longitud y la segunda, solo 140.
Etiquetas de entidad
Etiquetas de entidad (ETags) pueden provocar el cliente a innecesariamente cargar archivos. ETags están diseñados para identificar de forma exclusiva los archivos mediante el uso de un número que genera el servidor. En los clústeres de servidores, cada servidor creará un número diferente. Por ejemplo, un explorador está enviando un método Get con un campo de encabezado If-Modified para un archivo que encuentra en su memoria caché. Si no hay un único servidor, probablemente coincidirá con el archivo y se enviará un código de estado http 304 Not-Modified. Sin embargo, si el usuario tiene acceso a una granja de servidores de gran tamaño, probablemente alcanzará a un servidor diferente con una etiqueta de entidad diferente, lo que provoca que ese servidor enviar el archivo en el explorador.
Configuración de la memoria caché
Use Fiddler u otra herramienta similar para comprobar si la memoria caché es atender las solicitudes. Algunas de las razones almacenamiento en caché no servir peticiones incluyen:
- Los recursos no tiene un valor de fecha de caducidad.
- La cadena de consulta se cambia constantemente.
- La suma de encabezado de directiva de control de caché max-age y el encabezado last-modified da como resultado una fecha anterior a hoy.
- Los servidores proxy no admiten la propiedad max-age.
- El encabezado de control de caché tiene un valor de no almacenar en caché. Un valor de private almacena en caché el recurso sólo para el usuario que emite la solicitud.
Número y tamaño de imágenes
Debería minimizar el número de imágenes en su sitio. Para hacer esta tarea más sencilla, puede insertar varias imágenes en un único archivo y hacer referencia a las imágenes individuales en la página. No solo se reduce el tamaño de descarga del archivo, sino que, además, al haber menos archivos se producirá menos tráfico de red. Es más complicado crear páginas mediante esta técnica, pero en situaciones donde cada recorrido y el tamaño del archivo cuentan, puede ser una manera útil de mejorar el rendimiento.
La figura 3 muestra un ejemplo de un archivo de imagen único que contiene varias imágenes.
Figura 3. Archivo de imagen único que contiene varias imágenes
La figura 4 muestra cómo el archivo de imagen se cambia posteriormente para mostrarse como imágenes individuales en una tabla.
Figura 4. Varias imágenes mostradas en una tabla
La manipulación de las imágenes se realizó completamente mediante clases de hojas de estilos. Se usaron dos clases principales en los elementos div y img en cada celda de la tabla. Esas clases son las siguientes:
BODY {
font: 100% Tahoma, sans-serif;
}
.art-By {
font: 79%;
}
.art-Cap {
font: 67%;
}
.art-Head {
font: bold 117%;
}
.art-Sub {
font: 92%;
}
.art-Txt {
font: 83%;
}
.cluster {
height: 50px;
position: relative;
width: 50px;
}
.cluster img {
position: absolute;
}
Cada imagen tiene una clase asociada en función del identificador (Id.) de la imagen. Ese estilo recorta la imagen y define un desplazamiento desde la imagen inicial en el clúster. Esas clases son las siguientes:
#person {
border: none;
clip: rect(0, 49, 49, 0);
}
#keys {
clip: rect(0, 99, 49, 50);
left: -50px;
}
#people {
clip: rect(0, 149, 49, 100);
left: -100px;
}
#lock {
clip: rect(0, 199, 49, 150);
left: -150px;
}
#phone {
clip: rect(0, 249, 49, 200);
left: -200px;
}
#question {
clip: rect(0, 299, 49, 250);
left: -250px;
}
Páginas de vistas de lista
Microsoft ha trabajado para cuantificar y mejorar el rendimiento de los tiempos de representación de páginas de vista de lista. Una página de vista de lista es la página AllItems.aspx que se usa por cada lista y biblioteca para habilitar la exploración de contenido. El tiempo de representación de la página puede variar ampliamente según el número de columnas que están visibles en la vista y el formato de las columnas. Por ejemplo, mostrar opciones y la habilitación de iconos de presencia pueden afectar significativamente el tiempo de representación. La opción de agrupación contraído ha tardado considerablemente más procesamiento que la opción de agrupación expandida y, a continuación, ambos estaban más lentos que no hay ninguna opción de agrupación en absoluto.
Estos tipos de matices son por qué es importante considerar detenidamente cómo se construyen las vistas en las páginas de vista de lista, especialmente a través de conexiones de red lentas. Al trabajar con listas que contienen una gran cantidad de datos, es importante diseñar cuidadosamente todas las vistas, especialmente en la vista predeterminada. En general, puede acelerar el tiempo de procesamiento de páginas de vista de lista mediante el uso de las siguientes recomendaciones:
- Mostrar solo las columnas estrictamente necesarias.
- Si es posible, excluya las columnas que contengan información de presencia.
- Use un vínculo en lugar de un menú de edición para ver los detalles del elemento.
En la siguiente tabla se describen las personalizaciones que reducen el tiempo necesario para representar una vista.
Tabla 6. Personalizaciones que reducen el tiempo necesario para representar la vista
| Item | Descripción |
|---|---|
| Tipo de vista | Permite crear una vista como una vista de hoja de datos en lugar de una vista estándar. |
| Vista: límite de elementos | Cuando el número de elementos es superior a 1000, se representará más lentamente. Con una conexión lenta, es importante que experimente hasta encontrar el equilibrio entre la cantidad de datos que se muestran en una hora y el número de recorridos de ida y vuelta necesarios para ver todos los datos. Cuantas más filas se muestren de una vez, menos serán los recorridos de ida y vuelta, pero más grandes las páginas. |
| Vista: Filtro | Use las palabras clave [Hoy] y [Yo] para filtrar elementos por momento de publicación o tarea. Use los campos de estado para mostrar solo los elementos activos en vistas predeterminadas. |
| Vista: Columnas | Incluya el menor número de columnas. Cree una vista predeterminada con pocas columnas para una exploración de alto nivel para que después los usuarios puedan profundizar. |
La siguiente tabla describe las personalizaciones que aumentarán el tiempo necesario para que se represente una vista. Cada columna adicional aumenta ligeramente el tiempo de representación: hasta medio segundo por columna en una conexión de red rápida para una lista de 1.000 elementos. Algunas columnas pueden aumentar el tiempo de representación más que otras, tal y como puede observarse en la tabla.
Tabla 7. Personalizaciones que aumentan el tiempo necesario para representar la vista
| Item | Descripción |
|---|---|
| Agrupar por | La agrupación agrega HTML y JScript, lo que reduce la representación para listas grandes. Marcar todos los grupos contraídos de forma predeterminada aumenta aún más el tiempo de representación a causa de las operaciones adicionales en el modelo de objeto del explorador. |
| Columna: título vinculado al elemento con menú de edición | La opción "vinculado al elemento con menú de edición" es la que más tarda. La opción similar "vinculado al elemento" no mejora el tiempo de procesamiento notablemente. |
Panel del desarrollador
Se volvió a crear el Panel del desarrollador de SharePoint para proporcionar más información, incluida MDS. Se ejecuta en una ventana independiente para no afectar a la representación de la página actual y proporciona información detallada de solicitud por página con una vista de diagrama. También incluye una pestaña dedicada a las entradas de registro del sistema de registro unificado (ULS) para una solicitud determinada. Se incluye información adicional detallada para el análisis de la solicitud. Se usa un servicio dedicado de Windows Communication Foundation (WCF) (diagnosticsdata.svc) diseñado para proporcionar información de seguimiento.
Para obtener más información sobre el Panel del desarrollador:
- Usar el Panel del desarrollador
- Panel del desarrollador renovado (presentación de PowerPoint).
Para habilitar el panel del desarrollador, use el siguiente fragmento de código de Windows PowerShell.
$content = ([Microsoft.SharePoint.Administration.SPWebService]::ContentService)
$appsetting = $content.DeveloperDashboardSettings
$appsetting.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
$appsetting.Update()
Figura 5. Panel del desarrollador
Es importante que comprenda cómo estas solicitudes y el número de imágenes y consultas afectan al rendimiento. Hay similitudes respecto a las vistas de lista representadas del lado servidor (XSL o CAML), puesto que siguen las mismas recomendaciones de tamaño que las vistas de lista representadas del lado cliente. Sin embargo, la recomendación para la vista de lista del servidor es crear solo las vistas de lista estrictamente necesarias para cumplir los requisitos cuando el objetivo sea un rendimiento óptimo, ya que miles de vistas provocarán una mayor degradación del rendimiento debido a la administración de la memoria caché de compilación. Las características físicas del equipo, como la memoria y la velocidad del procesador, se tendrán en cuenta en la velocidad general.
También se tienen en cuenta aspectos como dónde se redirigen las solicitudes o cómo se distribuyen. Para comprender mejor cómo SharePoint redirige y distribuye las solicitudes, puede usar la herramienta Administrador de la solicitud. Sin embargo, la distribución de la solicitud queda fuera del ámbito de este artículo. Para obtener más información, vea Configurar el administrador de solicitudes en SharePoint.
Conclusión
Gran parte de la orientación sobre la optimización del rendimiento de página de SharePoint 2010 se aplica a SharePoint. Este artículo ofrece algunos de los elementos orientativos para SharePoint 2010, a la vez que profundiza en las nuevas áreas que podrían mejorar el rendimiento específicamente. Se han incluido algunos cambios o mejoras evidentes, por ejemplo, MDS y el Panel del desarrollador mejorado. Para concluir, nos centramos en las instrucciones clásicas: comprimir JavaScript y las hojas de estilos en cascada, usar una red CDN para bibliotecas comunes de JavaScript (si es posible para almacenar en caché(, combinar y comprimir imágenes tanto como sea posible, limitar o eliminar los datos innecesarios de la vista y crear vistas de lista de forma sensata. Las técnicas y características descritas en este artículo contribuyen a que logre sus objetivos de rendimiento.