Progettazione di pagine per download più rapidi (SharePoint Server 2010)

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Microsoft SharePoint Server 2010 include caratteristiche che consentono di ottimizzare il caricamento delle pagine in una WAN. Per migliorare ulteriormente le prestazioni, è inoltre necessario progettare pagine di dimensioni contenute e visualizzabili in tempi rapidi.

Le diverse tecniche disponibili non sono specifiche di Microsoft SharePoint Server 2010. In questo articolo non vengono quindi illustrati in dettaglio i metodi generali utilizzabili in qualsiasi sito Web. L'attenzione è invece focalizzata sulle caratteristiche disponibili in Microsoft SharePoint Server 2010, sugli elementi inclusi nella pagina e sulle tecniche che consentono di velocizzare una visita iniziale a un sito di SharePoint.

Elementi della pagina

Una pagina di un sito di SharePoint è costituita da numerosi elementi diversi tra loro, come illustrato nella figura seguente.

Durante il rendering della pagina vengono combinati la pagina master, la pagina di layout e il contenuto della pagina. Quest'ultimo include i valori relativi ai singoli campi della pagina, nonché numerosi altri elementi, ad esempio il tema, i fogli di stile, le immagini e i controlli di spostamento. Nella tabella seguente è illustrato un esempio dei file e dei flussi presenti in una singola pagina di un sito di SharePoint. L'esempio è costituito dall'acquisizione di tutte le richieste HTTP effettuate durante una visita iniziale alla home page predefinita di un sito Portale di collaborazione.

Notare quanto segue:

• Per scaricare la pagina sono state necessarie in totale 29 richieste.

• La dimensione totale della pagina è 235 kilobyte (KB).

• Nella tabella è rappresentato solo il caricamento iniziale della pagina. Per quasi tutti gli elementi della richiesta è presente una direttiva di memorizzazione nella cache che indica al browser di non caricarli nuovamente per un anno. Per i caricamenti successivi della pagina, a partire dal secondo, vengono create solo tre richieste, di cui due fanno parte della negoziazione NTLM eseguita normalmente. Di conseguenza, viene effettivamente scaricato un solo elemento, ovvero il codice HTML della pagina.

• È stato utilizzato il livello di compressione IIS predefinito, pari a 0, che corrisponde alla compressione minima possibile. Con un'ulteriore compressione è possibile ridurre ulteriormente le dimensioni dei download.

• Dei diversi tipi di file caricati:

  • 4 sono richieste di risorse axd

  • 4 sono richieste di risorse css

  • 12 sono richieste di risorse immagine

  • 6 sono richieste di risorse js (di cui diverse sono duplicati)

  • 3 sono richieste di risorse pagina per default.aspx (due delle quali sono incluse nella negoziazione NTLM)

La maggior parte di questi tipi di file è abbastanza ovvia. L'unica eccezione può essere costituita dal tipo di risorsa axd. La risorsa axd fa parte di una nuova caratteristica disponibile in ASP.NET versione 2.0. Uno sviluppatore può aggiungere una risorsa, ad esempio un file di script o un foglio di stile, a un controllo. Nel controllo lo sviluppatore utilizza la classe ClientScript per includere un metodo denominato GetWebResourceUrl. Durante il rendering del controllo in fase di esecuzione, viene generato dinamicamente un URL per la risorsa. La risorsa stessa viene compilata nell'assembly del controllo, pertanto questa metodologia consente di trasferire la risorsa dall'assembly al client come se si trattasse di un file distinto disponibile nel server Web.

Conoscere le richieste di risorse utilizzate dalla pagina aiuta a comprendere dove e come applicare le ottimizzazioni. Per misurare questo tipo di informazioni, è possibile utilizzare una vasta gamma di strumenti e tecniche diverse. In questo articolo viene utilizzato uno strumento freeware denominato Fiddler (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=108593&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). Fiddler può essere eseguito su una workstation client e consente di tenere traccia di tutte le richieste HTTP effettuate per una pagina. I risultati vengono visualizzati in un'apposita griglia, come illustrato nella figura seguente.

Dopo aver modificato il sito per ottimizzarlo, testarlo con Fiddler. Per ottenere informazioni accurate sugli elementi richiesti e su quelli memorizzati nella cache, nonché sulla dimensione di ogni elemento:

1. Avviare Fiddler.

2. Eliminare tutti i file temporanei del browser utilizzando il pulsante della barra degli strumenti Clear Cache di Fiddler.

3. Chiudere e riaprire il browser.

4. Richiedere la pagina desiderata.

   Nota

   Verificare che la pagina sia stata richiesta facendo clic su un collegamento. Se si fa semplicemente clic sul pulsante Aggiorna, il sistema richiederà di nuovo gli elementi in modo automatico senza visualizzare in modo accurato eventuali modifiche di ottimizzazione apportate.

Il dashboard di sviluppo disponibile in Microsoft SharePoint Server 2010 consente di identificare eventuali colli di bottiglia nelle prestazioni, ad esempio di web parti e chiamate al database, in altri componenti rispetto alle richieste HTTP. Pur non essendo specificamente uno strumento di ottimizzazione della WAN, il dashboard può contribuire a identificare i problemi di prestazioni relativi a una pagina.

Per ulteriori informazioni, vedere Utilizzo del dashboard di sviluppo (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=224025&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Ottimizzazione dei download di pagine

Dopo aver compreso come comporre la pagina, è possibile utilizzare diversi approcci per ottimizzarne il download. In generale, l'obiettivo è di ridurre al minimo di numero di round trip tra computer client e computer server, nonché di ridurre la quantità di dati trasmessi in rete. È possibile applicare le raccomandazioni incluse in questo articolo a una vasta gamma di implementazioni diverse di Microsoft SharePoint Server 2010.

È consigliabile suddividere le tecniche di ottimizzazione delle pagine in due categorie: richiesta relativa alla prima pagina e richieste relative alle pagine successive.

Le ottimizzazioni per la richiesta relativa alla prima pagina (tempo di caricamento pagina 1 o PLT1) sono quelle implementate la prima volta che una pagina viene richiesta, ma che non necessariamente influiscono sulle richieste relative alle pagine successive:

• Ottimizzare il markup HTML.

• Utilizzare immagini e file consolidati, ad esempio combinare più file CSS in un unico file e combinare immagini in un elenco o cluster immagini.

• Utilizzare tecniche di compressione (crunch).

• Verificare che vengano utilizzate le versioni di produzione dei file JavaScript per i quali sono disponibili sia versioni di produzione che di debug, ad esempio JQuery.

Le ottimizzazioni per le richieste relative alle pagine successive (tempo di caricamento pagina 2 o PLT2) sono quelle che possono migliorare l'esperienza utente di un caricamento di pagine successive. In questo caso è essenziale bilanciare l'eventuale perdita di funzionalità con il guadagno ottenuto. Se il guadagno viene ottenuto solo la prima volta che un utente visita un sito, potrebbe non valere la pena eseguire l'ottimizzazione a scapito della perdita di funzionalità.

È possibile utilizzare direttive di memorizzazione nella cache. Alcuni degli strumenti utilizzabili sono Aptimize e Microsoft Visual Round Trip Analyzer (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=227443&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Comprimere i file (crunch)

È spesso possibile ridurre le dimensioni di file che contengono JavaScript e stili rimuovendo spazi vuoti, ereditarietà degli stili e riutilizzo del codice. In alcune librerie sono disponibili sia versioni normali (debug) che versioni compresse (crunch). In Internet sono disponibili numerosi strumenti per automatizzare il crunching.

Verificare che nei server di produzione vengano distribuite le versioni compresse. In questo esempio viene illustrato come ridurre la dimensione di un file CSS con alcune semplici operazioni di riscrittura. Prima della compressione il file CSS è costituito da 655 caratteri:

.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}

La presenza di parole ripetute più volte indica che il file CSS non è scritto secondo criteri di efficienza. Dopo la compressione il file CSS è costituito da 127 caratteri:

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%}

Prestare attenzione ai tag Entity

I tag Entity (ETag) sono spesso la causa di problemi di prestazioni. Vengono in genere utilizzati per identificare in modo univoco i file mediante un numero generato dal server. Nei cluster di server ogni server crea un numero diverso. Si supponga ad esempio che un browser invii un metodo Get con un campo di intestazione If-Modified per un file trovato nella propria cache. Se è presente un solo server, il file molto probabilmente corrisponderà e verrà inviato un errore 304 - Non modificato. Se invece l'utente accede a una server farm di grandi dimensioni, è molto probabile che venga utilizzato un server diverso con un tag Entity diverso e che pertanto l'intero file venga ricaricato nel browser.

Verificare il funzionamento della cache

Utilizzare Fiddler o uno strumento analogo per verificare che la cache funzioni come previsto. Di seguito sono elencati alcuni motivi comuni correlati al mancato funzionamento della cache:

• Non è stata impostata alcuna data di scadenza.

• Viene modificata una stringa di query.

• La somma di max-age e data dell'ultima modifica non è maggiore della data odierna.

  Nota

  Il valore di max-age ha la precedenza sulla data di scadenza. Se si utilizza max-age, la scadenza verrà ignorata in Internet Explorer.

• È possibile che i server proxy non supportino max-age. Vengono preferite le date di scadenza.

• Se cache-control = no-cache, la cache non funzionerà. Lo stesso problema tende a verificarsi anche con "Private".

Cache BLOB

È possibile utilizzare la cache BLOB (binary large object) per applicare direttive della cache a elementi di una pagina archiviati in Microsoft SharePoint Server 2010. Se si includono tali direttive della cache, il browser non proverà a scaricare nuovamente gli elementi fino alla scadenza dell'elemento memorizzato nella cache. Come illustrato nell'esempio di home page precedente, a quasi tutti gli elementi inclusi nella home page predefinita del modello di sito predefinito Portale di collaborazione è associata una direttiva di memorizzazione nella cache ed è per questo motivo che non sono stati richiesti nelle successive visite alla pagina. Per ulteriori informazioni sull'impostazione e sulla configurazione della cache BLOB, vedere Ottimizzazione della memorizzazione nella cache BLOB per ambienti WAN (SharePoint Server 2010).

Ridurre al minimo gli elementi protetti nella pagina

Quando un utente esegue l'autenticazione a Microsoft SharePoint Server 2010, si verificano due eventi. In primo luogo, il sistema convalida le credenziali per confermare l'identità dell'utente. In secondo luogo, il provider di ruoli enumera l'elenco di gruppi di SharePoint di cui l'utente è membro. A ogni richiesta di una pagina, il provider di ruoli viene nuovamente chiamato per enumerare tutti i gruppi di cui l'utente è membro.

Questa chiamata relativa all'appartenenza ai gruppi può verificarsi più volte in un'unica pagina. Ad esempio, per la pagina predefinita del modello di sito Portale di collaborazione sono necessarie due chiamate al provider di ruoli per passare alla home page, una per la pagina stessa e l'altra per l'immagine presente nella pagina. Ogni immagine nella pagina archiviata in una raccolta SharePoint implica un'ulteriore chiamata al provider di ruoli per la verifica delle autorizzazioni, anche se tutte le immagini sono archiviate nella stessa raccolta immagini. La verifica viene eseguita sia se le immagini vengono aggiunte sotto forma di campi nella pagina (ovvero nel contenuto della pagina), sia se vengono aggiunte alla pagina master del sito.

È consigliabile progettare un sito sviluppato per una larghezza di banda limitata o un ambiente con latenza elevata in modo da ridurre al minimo il numero di immagini nella pagina. Nella pagina master di molti siti vengono utilizzate più immagini per creare effetti visivi diversi. Poiché la latenza aumenta se aumentano i controlli di sicurezza, progettare i siti per questi ambienti utilizzando il minor numero possibile di immagini.

Ridurre al minimo il numero e le dimensioni delle immagini

Come descritto nella sezione precedente, è consigliabile ridurre al minimo il numero di immagini nel sito. A tale scopo, è possibile incorporare più immagini in un unico file e fare riferimento a singole immagini nella pagina. In tal modo non solo si ridurranno le dimensioni di download dei file, ma diminuirà anche il traffico di rete perché generato da un numero minore di file. È certo più complicato creare pagine in questo modo, tuttavia in situazioni in cui il numero di round trip e le dimensioni dei file sono rilevanti, questa tecnica può rivelarsi di fondamentale importanza per migliorare le prestazioni. Nella figura seguente viene illustrato un esempio di un unico file di immagine contenente più immagini.

Nella figura seguente viene illustrato in che modo questa immagine viene successivamente modificata in modo da visualizzare singole immagini in una tabella.

La modifica delle immagini è stata effettuata interamente tramite classi di fogli di stile. Negli elementi div and img di ogni cella della tabella sono stati utilizzate due classi principali. Le classi sono le seguenti:

.cluster {

   height:50px;

   position:relative;

   width:50px;

}

.cluster img {

   position:absolute;

}

A ogni immagine è associata una classe sulla base dell'identificatore (ID) dell'immagine. Tale stile ritaglia l'immagine e definisce un offset dall'immagine iniziale del cluster. Le classi sono le seguenti:

#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;

}

Il codice HTML per la tabella include i tag div e img con i valori di ID e i nomi di classe appropriati, come illustrato di seguito:

<table border="1">

   <tr>

      <td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

   <tr>

      <td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

</table>

Questa tecnica è ora utilizzata in più proprietà e prodotti Web Microsoft, ad esempio Microsoft Office Outlook Web Access (OWA). Il team MSN ha eseguito alcuni test sulle prestazioni per analizzare l'impatto delle modifiche e ha notato un miglioramento compreso tra il 50 e il 75% dei tempi di caricamento per la prima pagina.

Se si creano pagine in Microsoft SharePoint Designer 2010, è opportuno considerare un aspetto importante. Quando si crea una nuova pagina in Office SharePoint Designer 2007, il markup dello schema XHTML seguente viene aggiunto automaticamente alla pagina:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Viene quindi aggiunto questo spazio dei nomi all'elemento HTML:

<html xmlns="http://www.w3.org/1999/xhtml">

Utilizzando questo schema, le immagini non verranno allineate correttamente. Per visualizzare le immagini come previsto, è necessario rimuovere l'attributo xmlns dal tag HTML.

Ottimizzazione delle pagine di visualizzazioni elenco

Il team di Microsoft Services ha lavorato per quantificare e migliorare le prestazioni relative ai tempi di rendering delle pagine delle visualizzazioni elenco. Una pagina di visualizzazione elenco corrisponde alla pagina AllItems.aspx utilizzata da ogni elenco e raccolta per abilitare l'esplorazione del contenuto. I tempi di rendering della pagina possono variare notevolmente in base al numero di colonne visibili nella visualizzazione e al formato delle colonne. Ad esempio, la visualizzazione delle opzioni e l'abilitazione delle icone di presenza possono influire significativamente sui tempi di rendering. Il rendering di un gruppo di pagine compresso richiede molto più tempo di quello di un gruppo di pagine espanso, mentre entrambi richiedono più tempo rispetto al rendering di pagine non organizzate in gruppi.

Queste precisazioni sono essenziali per comprendere per quale motivo è importante prestare attenzione a come creare le visualizzazioni nelle pagine di visualizzazioni elenco, in particolare se si utilizzano connessioni di rete lente. Quando si utilizzano elenchi contenenti molti dati, è importante progettare con attenzione tutte le visualizzazioni, in particolare quella predefinita. In generale, è possibile velocizzare i tempi di rendering delle pagine di visualizzazioni elenco adottando le tecniche seguenti:

• Visualizzare un numero minore di colonne.

• Escludere le colonne che includono informazioni sulla presenza.

• Utilizzare un collegamento (senza menu Modifica) per visualizzare i dettagli sull'elemento.

Nella tabella seguente sono illustrate le personalizzazioni che riducono il tempo necessario per il rendering di una visualizzazione.

Nella tabella seguente sono illustrate le personalizzazioni che comportano un incremento del tempo necessario per il rendering di una visualizzazione. A ogni ulteriore colonna aggiunta i tempi di rendering aumentano leggermente: fino a mezzo secondo per colonna con una connessione di rete veloce per un elenco di 1000 elementi. Come indicato nella tabella, alcune colonne comportano un maggior incremento dei tempi di rendering.

Nella tabella seguente sono illustrate le personalizzazioni che hanno un impatto relativamente ridotto sul tempo necessario per il rendering di una visualizzazione.