Non so quanti di voi sono iscritti alla Newsletter di Drupal.org, io lo sono ed a volte ci sono informazioni veramente interessanti.
Questa ad esempio è un articolo -scritto da Blair Wadman - che ho trovato molto interessante, espone una serie di semplici e veloci accorgimenti per rendere Drupal più veloce: http://befused.com/drupal/performance-improve
Ciao krima,
dovrebbero essere in tanti a doverti ringraziare; lo faccio io per tutti.
Forse non tutti sanno che da un pò di tempo le prestazioni sono un fattore di ranking.
Sull' articolo:
- Boost mi ha sempre creato problemi, quindi preferisco non usarlo
- Statistics non sapevo che incidesse molto e lo ritenevo utile soprattutto in caso di attacchi hacker e spam in quanto a volte ti dava qualche info in più rispetto a GA ed al log del server; ho provato comunque a disabilitarlo per vedere la differenza.
- Interessanti Fast 404 ed Entity Cache che proverò al più presto
- ad Advanced CSS/JS Aggregation preferisco Labjs che, nel mio caso, funziona meglio.
Il vero problema di D7, secondo me, sta nel fatto che alcuni JS non possono essere spostati in bottom, un problema che, da ciò che ho letto, si sta cercando di risolvere con D8.
Andando OT: utilizzando Piwik al posto di GA, perdo circa 500 m/s; se in futuro vedo che l' uso di cookie di terze parti non darà problemi al Garante, rimetterò GA (anche se è opinione diffusa anche adesso che se anonimizzato va bene, ma a me manca la dichiarazione di Google, che non farà mai, che non incrocerà i dati aggregati con altri software).
Ho provato Advanced CSS/JS Aggregation e mi sembra funzioni bene. Non conosco invece Labjs, proverò anche quello.
Con Fast 404 la vlocità per "pagina non trovata" è nettamente aumentata. Entity Cache invece devo ancora provarlo.
Continuando l'OT, ho controllato ler impostazioni di Firefox e non ho il do not track attivo, quindi potrebbe essere un problema di piwik che non lo traccia e basta. Comunque il tuo sito, da anonimo, lo vedo molto veloce e reattivo. Hai provato con il modulo se ci mette di meno a caricare le pagine?
Un paio di mesi fa avevo scritto una pagina sullo stesso argomento, se a qualcuno interessa: http://ilmiodrupal7.altervista.org/guida/approfondimenti/performance
Come Giovanninews anch'io ho rilevato alcuni problemi con l'uso di Boost. Per l'implementazione dei social, ho optato per Responsive Share Buttons e siccome non inserisce i classici bottoni ma solo dei link velocizza di parecchio il caricamento della pagina.
Vanni
http://ilmiodrupal7.altervista.org/
@Vanni,
concordo con Responsive Share Buttons, perchè, oltre a velocizzare, non genera cookie ed è quindi in linea con le nuove direttive sulla privacy. Per il modulo indicato, va usato la versione effettiva applicando le patch di Malcomio (inserite nella versione di sviluppo); non va usata la versione di sviluppo per problemi inerenti allo sprite css che Malcomio non è riuscito a risolvere e su cui ho aperto un bug su D.O.
@krima,
devo ancora valutare Fast 404 ed Entity Cache, ma, andando OT, rilevo sempre più problemi relativi all' utilizzo di Piwik, che colpiscono diversi settori, prestazionali, gestionali e SEO:
1) Avevo già usato il modulo e l' avevo scartato in quanto penalizzava ulteriormente le prestazioni.
2) Le prestazioni: Piwik, oltre a generare un ritardo della pagina di oltre 500 m/s, genera picchi sull' uso della cpu fino al 90% e grossi aumenti sulle operazioni di I/O (quando si accede alle statistiche).
3) Le dimensioni del database raddoppiano per un sito di medie dimensioni, generando quindi più incombenze sia per la fase di backup che per eventuali ripristini.
4) Il rischio di avere duplicati interni lato SEO è molto forte: pur bloccando l' accesso da robots alla directory piwik, per Google è necessario non avere Risorse bloccate (nella Search Console), quindi piwik.js va sbloccato, come pure piwik.php che produce un link per i cookie ad ogni nodo del sito.
In sintesi, Piwik va eliminato perchè, pur se va bene per le statistiche, produce grossi danni lato SEO (è sempre la mia opinione).
L' unica soluzione è sempre il ritorno a GA, seguendo lo sviluppo della sandbox di @filippo.ledda.
@giovanninews probabilmente io non ho grossi problemi perché lo uso su siti in vps con database rigorosamente separato, inoltre ho disattivato i cookie (basta aggiungere _paq.push(["disableCookies"]); prima di _paq.push(["trackPageView"]);).
Comunque dal lato SEO ti garantisco non ci sono problemi. Su di un sito dove è in uso dal 2013 c'è stato un aumento del 450% di visitatori nei primi due anni e quest’anno il trend va verso un'altro 50% in più. Gli altri, tutti relativamente nuovi, vanno molto bene anche se non con risultati come nel primo caso che ho descritto.
Tornando in tema, anch'io ho avuto problemi con Boost su Drupal 6 e quindi sul 7 non l'avevo mai usato fino ad ieri. Per l'installazione e configurazione ho usato questa guida: https://vacilando.org/article/drupal-performance-mantra-crawl-boost-expire
Devo dire che a momento sembra funzioni molto bene, sul sito dove l'ho testato c'erano problemi con la prima pagina. Essendo piuttosto pesante ci metteva 3-4 secondi a caricarsi, ora ci mette da 1.30 a circa 2.60 secondi e devo dire che non è male. Lo voglio testare ancora un po' e poi decido se vale la pena tenerlo o meno.
Ho provato anche Labjs e funziona bene - sembra meglio di Advanced CSS/JS Aggregation - solo che vorrei anche agregare un po' di CSS e questo modulo non lo fa.
Infine ho trovato anche questo modulo che pare aiuti con le immagini che vengono caricate via CSS: https://www.drupal.org/project/css_emimage
@Vanni, ho letto il tuo articolo e visto anche lì qualcosa che non conoscevo (File Cache) proverò ache questo :-)
In merito a Labjs, lo uso aggregando css e js da Drupal (Aggregate and Compress CSS file e Aggregate JavaScript files) e quindi abilitando il modulo.
Inoltre, con Labjs, bisogna escludere, dalla configurazione del modulo, almeno le seguenti pagine:
node/add/*
node/*/edit
admin/*
user/*
comment/*
Per GA mi era sfuggito un tuo commento in un altro post:
https://www.drupal.org/node/1648286#comment-6145800
@Vanni: non vedo tante differenze a disabilitare Database Logging e abilitare Syslog
Sì anch'io ma ne crea diversi. Magari disabilitatno il caricamento dei css di sistema e sopstandli nel tema risolvo.
Per quantyo riguarda i Js se vuoi spostarli a piè pagina, puoi farlo da html.tpl.php spostando
<?php print $scripts; ?>Sì, mi ero dimenticato di una chicca di @Mavimo di cui si sono perse le tracce e forse non ha più voglia di contribuire alla community:
è possibile raggruppare css e js nel template.php con le funzioni hook_css_alter e hook_js_alter nel modo seguente:
/*** Implements hook_css_alter().
*/
function MIOTHEMA_css_alter(&$css) {
foreach ($css as &$style) {
$style['weight'] += $style['group'];
$style['group'] = CSS_DEFAULT;
$style['every_page'] = TRUE;
}
}
/**
* Implements hook_js_alter().
*/
function MIOTHEMA_js_alter(&$javascript) {
foreach ($javascript as $key => &$script) {
$script['weight'] += $script['group'];
$script['group'] = JS_DEFAULT;
$script['every_page'] = TRUE;
if ($script['type'] === 'file') {
$filename_min = preg_replace('/.js$/i', '.min.js', $script['data']);
if (file_exists($filename_min)) {
$script['data'] = $filename_min;
}
}
}
}
Comunque, con D7, alcuni js non possono essere spostati in bottom perchè Drupal 7 non andrebbe; il problema lo stanno cercando di sistemare con D8.
Almeno io non ci sono riuscito.
Personalmente io preferisco usare db log, però siccome questo modulo scrive i log nel database, se il sito riporta numerosi errori/informazioni che devono essere registrate, potrebbe esserci un rallentamento di risposta dal db per il caricamento delle pagine.
Vanni
http://ilmiodrupal7.altervista.org/
Questo funziona veramente molto bene, grazie :-)
Per i Js, nei test che ho fatto, su un sito funzionava tutto correttamente mentre su un altro ci sono stati problemi con uno slideshow con una parte di funzioni nel tema. Quindi effettivamente in alcuni casi ci possono essere problemi.