WordPress alla velocità della luce

Pubblicato il 20 febbraio 2012
Autore:
L'articolo tratta di Wordpress .

PREMESSA

L'articolo spiega come ottimizzare al meglio WordPress al fine di ottenere la massima velocità di caricamento delle pagine che lo compongonoPur essendo consapevole dell’importanza della velocità delle pagine web, anche in termini di posizionamento nei motori di ricerca, non avevo mai condotto una ottimizzazione, per così dire, rigorosa. In genere mi limito ad effettuare una veloce analisi tramite GTmetrix o Google Speed Online e ad attuare solo alcune delle modifiche suggerite. Del resto, come in molti sostengono, ritengo che la velocità sia uno dei tanti parametri che concorrono a migliorare il posizionamento di un sito web, non l’unico, non il più importante, per cui mi sembra inutile esasperare la sua applicazione, giacché, in tal caso, i costi superebbero sicuramente i benefici.

Per una volta, tuttavia, ho deciso di apportare tutti i correttivi proposti da quei tool proprio al sito che più mi rappresenta: Ranked.it, che utilizza la piattaforma WordPress.
Si è trattato di un “esercizio compulsivo” che presumo si possa concludere con questo articolo, giacché, difficilmente, ripeterò le medesime operazioni con altri siti, miei o di clienti.

Ebbene, al termine di parecchie ore di lavoro sono riuscito ad ottenere i seguenti risultati:

GTmetrix, al termine dell'ottimizzazione, assegna un valore prossimo al 100% a Ranked.it
Rapporto Gtmetrix

Google Speed assegna 100% a Ranked.it a seguito dell'ottimizzazione
Rapporto Google Speed

Eccellenti, oserei dire!

Prima dell’intervento, l’home page del mio blog veniva caricata in oltre 5,5 secondi, ora in poco più di 2! Come ho anticipato, tuttavia, solo alcune delle attività che ho messo in pratica determinano miglioramenti consistenti. Molte altre, pur avendo contribuito ad ottenere parte di quel risultato, hanno un costo, a mio avviso, di molto superiore al beneficio apportato.

IL METODO

L’analisi della velocità di esecuzione della pagine di Ranked è stata effettuata tramite i tool precedentemente elencati:

L’attività è stata ripartita in sei step, a loro volta suddivisi in un certo numero di task:

  • OTTIMIZZAZIONE DELLE COMPONENTI DEL TEMA DI WORDPRESS

    • eliminazione hack e script per browser obsoleti;
    • ottimizzazione del css;
    • compressione del css tramite Cleancss;
    • ottimizzazione immagini del tema tramite Sumsh.it e Optipng;
    • creazione di sprite css tramite Spriteme.
  • DISINSTALLAZIONE PLUGIN INUTILI O OBSOLETI

    • generazione report Plugin Performance Profiler (P3);
    • disattivazione e cancellazione dei plugin non utili o inefficienti;
    • sostituzione dei plugin utili ma inefficienti;
    • sostituzione di plugin con funzioni omologhe nel tema di WordPress;
    • ottimizzazione del database e pulizia del sistema.
  • DEFINIZIONE DI UN SISTEMA DI CACHING

    • installazione di W3 Total Cache;
    • installazione di Wp Smush.it.
  • CONFIGURAZIONE DEL SERVER

    • attivazione della direttiva HTTP Keep Alive;
    • attivazione delle direttive gzip e deflate.
  • OTTIMIZZAZIONE DEL JAVASCRIPT DI GOOGLE ANALYTICS

    • spostamento dello script prima della chiusura del body;
    • trasferimento dello javascript in locale;
    • vari esperimenti.
  • UTILIZZO DI UN CDN (CONTENT DELIVERY NETWORK)

Ho utilizzato il font rosso per evidenziare le operazioni che ritengo indispensabili per aumentare la velocità delle proprie pagine web; le rimanenti possono anche essere tralasciate in tutto o in parte.

Due avvertenze:

  • alcuni task potevano essere completati tramite lo stesso tool Gtmetrix (che, al termine di ogni analisi, fornisce, ad esempio, immagini e css ottimizzati), ma ho preferito utilizzare tool online specifici;
  • non sono un esperto di sistemi e, soprattutto, di server, mi scuso, pertanto, se risulterò impreciso e/o omissivo nella trattazione di certi argomenti.

OTTIMIZZAZIONE DEL CSS E DELLE IMMAGINI

Ranked è realizzato tramite la piattaforma Open Source WordPress ed è on-line da diversi anni; grafica e codice del template sono stati costruiti “sartorialmente” quando ancora era attivo quel surrogato di browser denominato Internet Explorer 6. Per cui, prima dell’ottimizzazione, il sito presentava elementi che ora non hanno più ragione di essere e che, ovviamente, ho rimosso. Nella fattispecie alcuni hack nel css ed i fix per le immagini in formato .png (formato, al tempo, non supportato dal pessimo software di navigazione di Microsoft).

Terminata quella fase, ho provveduto a rivedere il css del mio template, rimuovendo classi ed id non più utilizzati e razionalizzando i rimanenti (ridefinendo il codice in maniera virtuosa, laddove possibile, per le classi con più di due selettori discendenti). A questo punto ho compattato il file tramite il tool Cleancss.

Consiglio di non esagerare con la compressione: prima o poi sarà necessario effettuare ulteriori modifiche al foglio di stile, per cui è preferibile che sia ancora leggibile al termine dell’operazione.

Smush.it permette di ottimizzare le immagini del vostro sito in tempo reale, è disponibile anche un plugin per WordPress che effettua l'operazione automaticamenteInfine ho ottimizzato le immagini del tema tramite Smush.it e Optipng.

Il primo è un tool di Yahoo! (che vedremo, poi, verrà utilizzato anche tramite plugin) che permette di ottenere una versione ottimizzata delle proprie immagini in tempo reale, il secondo un software specifico per l’ottimizzazione dei file .png, che si è reso necessario in quanto l’applicazione del primo non è stata sufficiente a rimuovere un warning di GTmetrix.

Ho effettuato, a dire il vero, un ulteriore operazione: la creazione di uno sprite css. Si tratta di una tecnica di Web Design che prevede di accorpare un set di elementi grafici (ad esempio, header, pulsanti, icone e quant’altro) in una unica immagine, che verrà richiamata quale background dal codice css delle varie classi e id contenuti nella pagina. Ciascun css, tramite l’imposizione di determinate coordinate, visualizzerà solo una porzione specifica della stessa immagine, quella che, ovviamente, gli appartiene.

L’operazione, almeno per il mio sito, è risultata fine a sé stessa, lo ammetto! Mi ha, tuttavia, consentito di familiarizzare con un tool online, Spriteme, che adotta un funzionamento che ha del geniale, almeno a mio parere:

  • si memorizza nei preferiti la sua home page;
  • si accede al sito che si vuole ottimizzare;
  • si richiama il preferito precedentemente memorizzato;
  • il cambio di pagina non avviene ed appare, invece, una finestra controllata dal tool che analizza il codice e permette, poi, di effettuare il download delle immagini che compongono gli sprite e del relativo codice css.

Ho provato diversi altri tool, ma ritengo che questo sia, in assoluto, il più semplice da utilizzare.

DISINSTALLAZIONE PLUGIN INUTILI O OBSOLETI

Per ottenere una veloce installazione di WordPress ritengo sia essenziale l’installazione di P3, Plugin Performance Profiler realizzato da GoDaddy.

L’applicazione permette di determinare il peso di ciascun plugin installato nell’infrastruttura misurandone l’impatto in termini di velocità e numero di query.

Non dispongo, purtroppo, di immagini precedenti all’ottimizzazione, posso assicurare, tuttavia, che i tempi di caricamento e il numero di query, al termine dello step, si sono quanto meno dimezzati.

Tramite il report di P3 è possibile individuare il "peso" di ciascun plugin di WordPress, in termini temporali e di numero di query
P3 Report

Il runtime di P3 visualizza, in un grafico a torta, i tempi di caricamento di ciascun plugin installato in WordPress
P3 Runtime

L’analisi offerta da questo strumento dovrebbe condurre ad un solo risultato: l’eliminazione dei plugin non indispensabili e/o obsoleti.

L’installazione di un plugin, infatti, consente di ampliare in maniera sensibile le funzionalità di un sito o di un blog, ma, di contro, determina anche degli effetti collaterali:

  • un aumento delle query che il sistema è costretto ad effettuare;
  • spesso una diminuzione del rapporto tra contenuti e html, che rappresenta un fattore determinante per il posizionamento dei siti web; tale inconveniente è dovuto alla scarsa ottimizzazione del codice utilizzato da molti developer di plugin: sovente css, javascript ed altri elementi che li compongono vengono inseriti nella sezione head della pagina o addirittura inline, anziché in file separati;
  • un’affidabilità, quanto a codice e ottimizzazione, non paragonabile a quella del sistema base di Automattic, l’azienda che ha creato WordPress.

Pertanto, la permanenza di un plugin dovrebbe essere determinata sulla base di un’analisi costo – beneficio. Se il costo, espresso in termini di riduzione della velocità di esecuzione delle pagine, supera il beneficio (il cui valore, ovviamente, può stabilirlo solo chi gestisce il sito), il plugin deve essere eliminato!

Si badi bene, con quel termine intendo la cancellazione definitiva dell’elemento, operazione che può essere effettuata manualmente, tramite ftp, o dal backend del sistema. WordPress, infatti, effettua un controllo su tutti i plugin installati, per poi processare solo quelli attivi; pertanto la semplice disattivazione non è sufficiente a raggiungere lo scopo che ci siamo prefissi: la velocità della luce!

Se un plugin è utile ma inefficiente, si può provvedere ad individuare un suo sostituto che non presenti gli stessi inconvenienti.

Infine, qualora si sia sufficientemente esperti, è raccomandabile sostituire, laddove possibile, i plugin con funzioni all’interno della pagina functions.php del tema di WordPress. Per esempio, nel mio caso specifico, ho inserito a mano il codice di Analytics e quello relativo alla paginazione degli articoli e altrettanto potrei fare con i pulsanti di condivisione social.

In rete vi sono centinaia di siti che propongono snippet che attivano funzionalità omologhe a quelle ottenibili tramite l’uso di plugin, che consentono, rispetto a questi ultimi, di ridurre notevolmente il consumo di risorse.

ATTENZIONE: la disinstallazione di un plugin elimina tutti i file che lo compongono, ma, molto spesso, non tutti i suoi riferimenti nel database. Per effettuare l’operazione di eliminazione di questi elementi è possibile utilizzare il plugin Clean Option: il procedimento è piuttosto complesso e presenta qualche rischio, pertanto deve essere effettuato da utenti esperti e, comunque, previo backup del database.
Può, inoltre, essere installato, anche contemporaneamente, il plugin WP Cleanfix che permette di ottimizzare il database e di rimuovere gli elementi del sistema (revisioni, commenti in spam, bozze, file cestinati, ecc.) che non hanno più ragione di esistere.

DEFINIZIONE DI UN SISTEMA DI CACHING

Nella fase successiva ho implementato il sistema di caching. Esistono numerosi plugin che permettono di attivare tale funzionalità. Ho notato, tuttavia, che la maggioranza delle pagine che trattano dell’argomento consigliano di utilizzare W3 Total Cache e così ho fatto.

Il plugin, di fatto, ottimizza le prestazioni del server, consente di ridurre i tempi di caricamento degli elementi html, css, javascript e media che compongono un sito web attraverso compressione e Minify (operazione che elimina spazi bianchi, commenti e tutto ciò che non è strettamente indispensabile per eseguire un file di codice).

La configurazione del plugin è piuttosto ostica: ritengo, tuttavia, che le impostazioni di default siano adeguate per la maggioranza dei siti web. Ad ogni modo, per approfondire, sono presenti in rete numerose guide sull’argomento.

A questo punto ho installato Wp Smush.it che, in maniera totalmente automatica, utilizza le Api del servizio di Yahoo! (di cui ho parlato in precedenza) al fine di ridurre il peso delle immagini di cui si è effettuato l’upload.

Infine, qualora il vostro tema utilizzi custom query, è possibile attivare una procedura di caching modificando lo snippet che segue.

  1. <?php
  2. // Get any existing copy of our transient data
  3. if ( false === ( $special_query_results = get_transient( 'special_query_results' ) ) ) {
  4. // It wasn't there, so regenerate the data and save the transient
  5. $special_query_results=new WP_Query('cat=5&amp;order=random&amp;tag=tech&amp;post_meta_key=thumbnail');
  6. set_transient( 'special_query_results', $special_query_results );
  7. }
  8. // Use the data like you would have normally...
  9. ?>
<?php 
// Get any existing copy of our transient data
if ( false === ( $special_query_results = get_transient( 'special_query_results' ) ) ) {
// It wasn't there, so regenerate the data and save the transient
$special_query_results=new WP_Query('cat=5&amp;order=random&amp;tag=tech&amp;post_meta_key=thumbnail');
set_transient( 'special_query_results', $special_query_results );
}
// Use the data like you would have normally...
?>

CONFIGURAZIONE DEL SERVER

Nonostante le ottimizzazioni precedenti l’indice Page Speed Grade di Gtmetrix difficilmente si discosta dal valore C se non sono attivate nel server che ospita il sito due direttive di Apache:

  • Keep alive (si tratta di una componente di Apache che permette di realizzare connessioni persistenti con uno stesso TCP; si tratta di un concetto alquanto complicato, che va al di là dello scopo dell’articolo, per cui, volendo approfondire l’argomento, consiglio questa lettura);
  • Gzip e deflate (si tratta di direttive che si occupano di gestire la compressione di alcuni degli elementi che compongono un sito web, potete ottenere maggiori informazioni tramite Wikipedia).

Ovviamente l’attivazione di tali direttive deve essere richiesta al proprio hosting.

JAVASCRIPT DI GOOGLE ANALYTICS

Forse è eccessivo dedicare un intero paragrafo all’ottimizzazione del codice di Google Analytics. Si tratta, tuttavia, di un javascript un po’ “scomodo” e piuttosto pesante, anche se invocato in modalità asincrona. Peraltro le conclusioni a cui sono giunto possono essere applicate a qualsiasi Javascript che, per vari motivi, Total Cache non riesce a processare correttamente.

Le istruzioni di Google impongono il caricamento dello stesso nella sezione head della pagina html; io però mi sono chiesto se potevo ottenere qualche vantaggio ponendolo, invece, giusto prima della chiusura body. In effetti, così facendo, si ottiene un leggero aumento delle prestazioni.

Di contro, non vengono più tracciati gli utenti che chiudono il browser prima che sia completamente caricata la pagina web, particolare trascurabile, per quanto mi riguarda.

Al riguardo consiglio la lettura degli articoli che seguono:

Quale sia la posizione dello script, sottoponendo il sito a Google Speed Online, si ottiene comunque un warning:

Le seguenti risorse memorizzabili nella cache hanno una durata di aggiornamento breve. Specifica una scadenza di almeno una settimana in futuro per le seguenti risorse:
http:// www. google-analytics. com/ga.js (2 ore).

Esaminando tutte le opzioni di Total Cache non ho trovato alcun elemento con data di scadenza posta a due ore; per cui sono giunto alla conclusione che questo parametro è immodificabile e viene determinato da Google stessa e che il plugin di caching non è in grado di processarlo correttamente, ma non ho certezze su questa affermazione e, soprattutto, su quelle che seguiranno.

Un ulteriore modifica mi ha consentito, comunque, di risolvere, almeno in parte, il problema: anziché inserire direttamente il codice di Analytics in footer.php del tema di WordPress, ho creato un action e l’ho posta in functions.php. Di seguito il suo codice:

Lo script viene caricato automaticamente tramite wp_footer() che, ovviamente, deve essere presente nella pagina footer.php del tema e posto giusto prima della chiusura del body. Nella quarta riga dell’action è necessario inserire il codice dello script fornito da Google. Codice che, volendo, potrebbe pure essere ottimizzato attraverso un tool Minify.

  1. <?php
  2. add_action('wp_footer', 'add_googleanalytics');
  3. function add_googleanalytics() { ?>
  4.  
  5.  
  6. // Inserire codice Analytics
  7. <?php } ?>
<?php 
add_action('wp_footer', 'add_googleanalytics');
function add_googleanalytics() { ?>


// Inserire codice Analytics
<?php } ?>

Al termine di questa operazione l’indice di Page Speed Online ha raggiunto il 100%, mentre GTmetrix presentava un ulteriore warning, argomento dello step successivo.

Ma non ero ancora del tutto soddisfatto, per cui, complicando ulteriormente le cose (ne sono consapevole!) ho provato anche a “prendere il controllo” del Javascript di Analytics copiandolo in locale, nella cartella del tema di WordPress, modificando, di conseguenza, lo script che lo invoca (a questo punto, per poter disporre di un Javascript sempre aggiornato, sarebbe necessario creare una procedura di cron job nel server che, periodicamente, confronti l’esemplare in locale con quello fornito da Google e provveda alla sostituzione del primo qualora il secondo sia più aggiornato).

Questa procedura ha portato un incremento di velocità del sito meno che trascurabile (perlomeno quando ho effettuato la misurazione, nulla si può dire, tuttavia, nel caso in cui la rete sia congestionata) ma, soprattutto, ha generato un nuovo warning: il Javascript di Analytics, infatti, non viene compresso da Total Cache. A questo punto ho sospeso, almeno temporaneamente, i test.

UTILIZZO DI UN CDN (CONTENT DELIVERY NETWORK)

La posizione di questo step è volutamente ultima: non ho effettuato, infatti, tale ottimizzazione che, presumo, mi avrebbe consentito di ottenere 100% nell’indice Yslow di Gtmetrix.
Un servizio di Content Delivery Network consente di effettuare la copia della maggior parte dei contenuti del proprio sito web (in genere, i cosiddetti media) presso una rete distribuita di server. L’uso di tale applicazione permette, molto sinteticamente, di:

  • offrire all’utente la copia dei contenuti posta nel nodo a lui geograficamente più vicino, aumentando quindi la velocità di fruizione degli stessi;
  • migliorare la distribuzione dei contenuti in caso di congestione delle rete (se, ad esempio, un server è sovraccarico, in un dato istante, può esserne utilizzato un altro che dispone di una copia degli stessi elementi);
  • gestire in maniera automatica la propagazione degli aggiornamenti dei contenuti tra tutti i server che ne ospitano una copia.

Total Cache è già predisposto per l’utilizzo del CDN offerto da Cloudflare (gratuito o a pagamento), ma consente anche di utilizzare qualsiasi altro servizio similare.

Personalmente ho ritenuto del tutto inutile l’attivazione di tale funzionalità per un sito di modeste dimensioni quale Ranked; in effetti Gtmetrix consiglia di utilizzare il CDN per sole dieci immagini del mio blog, il beneficio sarebbe alquanto limitato.

La pratica, invece, può risultare piuttosto efficace per siti di dimensioni più generose, soprattutto per quelli che contengono numerosi media. Aggiungo, inoltre, che l’attivazione del servizio comporta delle modifiche ai DNS, operazione che, per la maggior parte degli utenti, risulta alquanto complessa e che, generalmente, deve essere demandata all’hosting.
A questo punto l’ottimizzazione può dirsi terminata!

Di seguito propongo uno schema visuale che riassume tutto il procedimento adottato.

Lo schema visuale descrive tutte le fasi dell'ottimizzazione di wordpress al fine di ottenere la massima velocità di esecuzione

28 commenti all'articolo “WordPress alla velocità della luce”

  1. 20 febbraio 2012 alle 14:30

    Interessante, sto ottimizzando le immagini con uno dei tool.

    W3 Total Cache non me lo fa installare però, dice che c’è un errore fatale…

    • 20 febbraio 2012 alle 15:34

      Mandami l’url del sito o la sintassi dell’errore.

      • 25 ottobre 2013 alle 18:30

        ciao enrico, bellissimo post, solo che anche a me installando w3 total cache mi da errore fatale….
        Cosa dovrei fare?

        • 25 ottobre 2013 alle 20:40

          Ciao Raffaele, così, di primo acchito, mi viene da pensare a php.ini, prova a far aumentare la memoria di php a 128Mb, poi, al limite, scendi, se tutto funziona.

          • 28 ottobre 2013 alle 12:33

            Ciao, ho cancellato wp super cache e sono riuscito ad installare w3 total cache.
            Solo che usando le configurazioni del plugin mi da diversi problemi ( mi cambia il font del mio menu e piccoli problemi nel css dei widget)
            Ho letto parecchi commenti e mi hanno consigliato di disabilitare la voce minify…
            Che ne pensi?

          • 28 ottobre 2013 alle 12:45

            Ciao Raffaele, potrebbe essere. Il minify comprime il css, eliminando spazi e ogni altro elemento accessorio. Io farei questa prova, controllerei, innazitutto, che il css è valido, puoi usare il tool del w3c. Se lo è disabilità il minify. Per fare la prova definitiva scarica un plugin che effettui solo il minify e controlla se compare lo stesso inconveniente…

          • 28 ottobre 2013 alle 15:05

            Scusami l’ inesperienza, ma come faccio a vedere se il mio css è valido o meno? e come faccio ad usare il tool di w3 total cache.
            grazie anticipatamente

          • 28 ottobre 2013 alle 21:49

            Raffaele ti aiuto volentieri, però, insomma, qui basta fare una ricerca molto semplice in google: https://www.google.it/search?ie=UTF-8&q=css%20validation
            Usa il tool W3C non ti total cache per validare il tuo css e quindi effettua le altre operazioni…

            Ciao
            Enrico

  2. 20 febbraio 2012 alle 21:11

    Era da parecchio che non leggevo un articolo così utile, sia negli spunti che nelle applicazioni puntuali bravo Enrico!

  3. 21 febbraio 2012 alle 05:05

    prova ad accoppiare DB Cache Reloaded + Hyper Cache si hanno risultati strabilianti.

  4. 21 febbraio 2012 alle 11:32

    @Enrico: il sito è quello in firma :)

  5. 22 febbraio 2012 alle 14:11

    a me, su aruba, il pluging per wordpress di smush mi dava errori (non ricordo quali, il blog funzionava, ma in maniera “strana” e faceva andare in conflitto altri plugin)
    e normale?

    m

    • 22 febbraio 2012 alle 15:42

      Non uso Aruba ma non dovrebbe essere normale, credo.
      Ma mi viene il dubbio che uno o più plugin che hai installato vadano in conflitto con quello di Smush.it.
      Potresti provare a disattivarli tutti e attivare solo quello e controllare se l’errore persiste…

  6. 24 febbraio 2012 alle 14:35

    Un articolo assolutamente favoloso. È da tempo che sto dietro a questa roba ed è la prima volta che vedo una serie di procedure e strumenti (gratuiti!) per implementare i miglioramenti in modo semplice (ehm, più o meno) e immediato. Alcuni di questi strumenti li conoscevo già e li usavo, altri mi hanno aperto un mondo. Mi metto subito a lavoro. Grazie mille! 10+

    • 24 febbraio 2012 alle 15:48

      Ti ringrazio molto per i complimenti Emanuele. Dimmi pure dove non è chiara la trattazione, nulla vieta di migliarla anche dopo la pubblicazione dell’articolo! :)

  7. 25 febbraio 2012 alle 10:26

    Ciao Enrico, complimenti per esserti cimentato in questa impresa e per aver condiviso un post così interessante

  8. 9 marzo 2012 alle 00:14

    Complimentoni per l’articolo.

  9. 27 ottobre 2012 alle 17:44

    ciao Enrico
    ti confermo che seguendo queste linee guida sono riuscita ad aumentare notevolmente il mio Page Speed: facendo riferimento a GTMetrix (dati confermati anche da Pingdom) , il balzo in avanti l’ho fatto attivando keep-alive.
    Segnalo però, per chi come me acquista servizi di hosting low-cost, per piccoli siti, che non sempre il servizio di hosting condiviso rende attivabile questa funzione.
    Nel mio caso: su http://www.vhosting-it.com ho acquistato 5 domini con spazio hosting condiviso nell’arco di 6 mesi: 2 di questi domini sono finiti su un server che consente l’attivazione di keep-alive mentre gli altri tre sono finiti su un server più vecchio e meno performante dove non è attivabile keep-alive: i primi due sono schizzati da pagespeed grade D ad A con l’attivazione della funzione keep-alive mentre gli altri 3 resteranno con un pagespeed grade D. Morale: anche per siti piccoli e con poco traffico, se si vuole migliorare il proprio posizionamento gli hosting low cost sono un rischio quando non garantiscono queste prestazioni.

    • 27 ottobre 2012 alle 21:26

      Grazie Lorenza, eccellente contributo! :)
      Personalmente uso un server mio, quindi me lo gestisco come credo, ma ritengo che a buon prezzo ci siano soluzioni shared di buon livello.
      In ogni caso si può sempre chiedere prima dell’acquisto se queste direttive di apache sono attivabili o meno.

  10. 16 dicembre 2012 alle 02:29

    Ciao Enrico,
    complimenti per l’ottimo articolo!Sto provando ad ottimizzare il sito da un bel po’ ma purtroppo non riesco a risolvere un problema.
    Si tratta del codice javascript dovuto ai pulsanti social.I suggerimenti di pagespeed consigliano di inserirli in un solo file ma ancora non ho capito come fare e come richiamare il pulsante dovo aver inserito i codici in un solo file.Sapresti aiutarmi?
    Grazie in anticipo :)

    • 16 dicembre 2012 alle 12:40

      Ciao Xzed, puoi inserire tutto il codice in un unico file php e quindi includerlo nel footer del tuo tema tramite il comando:
      < ?php include('http://www.sito.com/file.php'); ?>.
      Ad ogni modo puoi trovare parecchi tutorial per creare degli snippet da inserire nel file functions.php che ti permettano di gestire l’ambito social, farei comunque una ricerca sul tuo motore di ricerca preferito.

      • 16 dicembre 2012 alle 19:29

        Ho cercato per molto tempo su Internet ma non ho trovato nulla che potesse fare al caso mio.
        Ti faccio un esempio: per il pulsante mi piace ho posizionato questo codice nel punto in cui deve apparire nel file index.php:

        <fb:like href="” width=”170″ layout=”button_count” send=”false” font=””>

        Mentre quest’altro per Twitter:

        <a h ref="http://twitter.com/share&quot; class="twitter-share-button" data-url="” data-text=”” data-count=”horizontal” data-via=”Netclick_it” data-lang=”it”>Tweet

        Cosa dovrei inserire in un file che li contiene tutti e come li richiamo poi in quel punto?

        • 16 dicembre 2012 alle 19:58

          Prendi i due codici li piazzi in una pagina social.php e li richiami con una inclusione al file medesimo; per informazioni sull’inclusione cerca i seguenti termini su Google “include wordpress”, potresti usare anche get_template_part se non ricordo male. Prova a leggerti le istruzioni di quel comando sul Codex di wordpress: http://codex.wordpress.org/Function_Reference/get_template_part.

  11. 17 dicembre 2012 alle 02:52

    Grande!!Ora non mi dà più quell’errore e mi segnala un peso della pagina minore!Grazie mille Enrico!!!

  12. 28 ottobre 2013 alle 15:19

    poi nella verifica del plugin mi esce ….

    New Relic is not running correctly. The plugin has detected the following issues:

    PHP module is not enabled.
    PHP agent is not enabled.
    API Key is invalid.
    Account ID is not configured.
    Application ID is not configured. Enter/Select application name.
    License key could not be detected.

    c’è qualcosa che nn va?

    • 28 ottobre 2013 alle 21:53

      Qui non capisco, New Relic è un tool per valutare le performance, ma cosa c’entra con Total Cache?
      Per di più è pure a pagamento, ma non ho capito forse io la domanda?

Scrivi il tuo commento