jump to navigation

Genialata per velocizzare Wordpress

In Avanzate, per Guru!, Guide, Produttività il 17/10/08 @ 9:35 trackback

Da quando sono migrato via dalla piattaforma WP-MU di wordpress.com, mi sono reso conto che il volume di traffico di pollycoke è assurdamente elevato per un semplice blog personale che risiede su un vserver (anche se ciò mi fa naturalmente piacere!).

Tuttora il mio diarietto è un continuo banco prove per sperimentare ottimizzazioni per wordpress. Ho imparato quasi a provare piacere nel tirare fuori il meglio da questo grandioso software che – con tutti i suoi difetti – resta la migliore piattaforma di blogging in circolazione. Beh, oggi vi espongo alcune di queste tecniche.

Ho abbandonato l’abitudine di rendere pubblici i numeri di pollycoke, perché ahimè attiravano un po’ troppe attenzioni negative nei miei confronti, ma vi faccio un esempio. Quando l’anno scorso F. di Infinytech mi ha gentilmente aiutato a configurare LAMP1, ad un certo punto è arrivato a dire qualcosa come: «Ma qui sembra di essere sotto attacco DDoS!» riferendosi allo sforzo richiesto per servire tutte le pagine richieste :D

Sì, lo so, ci vorrebbe un dedicato, ma non ho alcuna intenzione di… non mi sembra giusto rimetterci di tasca per pollycoke :)

La prassi

Man mano che passa il tempo il volume di traffico continua ad aumentare, così come gli utenti iscritti a pollycoke (siamo ormai circa 1.400!), chi mi segue via RSS (con picchi di oltre 4.000), i visitatori unici giornalieri… insomma c’è un bel lavoro da fare per tenere tutto a bada. A tal proposito, senza andare a scomodare la configurazione LAMP, consiglio vivamente di seguire le classiche indicazioni che ben conosce la maggior parte degli utenti medio-avanzati di Wordpress:

Consiglio vivamente SuperCache, personalmente non sono un grande esempio da seguire riguardo ai plugin che uso (troppi) e non ho nemmeno trovato la voglia di comprimere CSS e Javascript (ho giusto elimimato gli spazi bianchi dal CSS) ma tutti quelli qui sopra sono suggerimenti abbastanza comuni e senza dubbio consigliati. Qualche tempo fa però (saranno ormai mesi) ho avuto l’illuminazione.

L’illuminazione

Torno al primo punto della lista di qui sopra: “usare un tema leggero”. Intendo che abbia meno chiamate PHP possibile, meno intrecci di Javascript, meno

, meno css… meno codice da eseguire insomma. Il tema che uso per pollycoke, Regulus, oltre ad essere molto gradevole è molto ben congegnato ed è di una semplicità estrema: da una parte questo significa che ogni funzionalità aggiuntiva deve essere implementata via plugin o modificando direttamente il codice, dall’altra parte è ovvio che non c’è in tutto pollycoke una singola riga di php che non sia lì perché così ho deciso io ;)

Portando questo discorso un tantino oltre, qualche tempo fa mi sono messo a caccia di possibili ottimizzazioni direttamente tra i file e ho visto che ci sono tante ma taaante istruzioni che possono essere eliminate! Ho cercato conforto in rete e ho scoperto di non aver inventato niente di mai sentito, anche se non è proprio una tecnica comune: a quanto pare ci sono già diversi blogger che usano questa tecnica con profitto. Esiste perfino un timido plugin che si propone di attivare la cache per questo tipo di chiamate nei widget della sidebar… beh ma che senso ha installare un plugin per alleggerire? Si fa manualmente ;)

Header, Index, Single, Comments, Footer, Page… eccetera

Ok. Basta con la poesia e andiamo ai fatti. Guardate questo stralcio di codice, proviene dall’originale header.php di Regulus:



    <strong><?php bloginfo('name'); ?><?php wp_title(); ?></strong>
    " />

E adesso guardate che bello il mio (che sensazione strana, è un po’ come la celebrazione del rito della minzione in compagnia -.- ), con il codice di header.php ripulito per pollycoke:


    <strong>pollycoke :)</strong> <?php wp_title(); ?>
    charset=UTF-8" />
    
    
    
    
    
     <- eliminato

Beh, una decina di chiamate PHP eliminate solo in questo stralcio. Interessante, no? Ho in sostanza rimosso ogni funzione che non fosse strettamente indispensabile, come appunto la dichiarazione del tipo di documento e il charset, la versione di WP, l’indirizzo del CSS e di tutto ciò che in pollycoke non cambierà mai, o quasi. In header.php c’è davvero molto da vandalizzare, ma se guardate con occhio inquisitore noterete che gli altri file non scherzano!

Ma perché fermarsi? Sidebar, Categorie, Tags, Archivi…

Se siete i tipi giusti, avrete uno strano prurito alle mani già adesso mentre leggete: una volta fatto questo lavoro sulle singole pagine, perché fermarsi e non puntare il dito sulle simpatiche liste di link che tipicamente popolano le nostre barre laterali? Categorie, Archivi, Argomenti trattati… Vi appariranno all’improvviso come dei mostri mangia-risorse… ed effettivamente lo sono: ogni widget di pollycoke arrivava a fare parecchie decine di chiamate!

Non tutti i widget possono essere resi statici, ovviamente. I commenti più recenti ad esempio devono appunto essere i più recenti… quindi restano così come sono. Ma siamo sicuri che ci sia proprio bisogno che la lista delle Categorie venga ricreata ogni volta che una pagina viene generata? No, affatto! Categorie e Archivi cambiano molto raramente ed è davvero inutile fargli fare complesse query MySQL e convertire il PHP in HTML.

Io ho reso statica perfino la lista degli argomenti trattati, mi sono ripromesso di aggiornarla una volta al mese, in concomitanza con l’aggiornamento della lista degli Archivi ;)

Procediamo!

Avvertenza: potete potenzialmente mettere fuori uso un intero sito con un solo copia/incolla sbagliato. Se distruggete l’unico mezzo che vi è rimasto per comunicare con il resto del mondo, non venite a cercare me :D

Ok, vandalizzare il proprio blog per eliminare tipo un migliaio di funzioni per pagina in un colpo solo è un’operazione semplicissima, anche se vale la semplice regola del “solo se sapete cosa state facendo”. Basta un editor, un client FTP, un browser e un atteggiamento stronzo e pignolo, che sono sicuro non vi manca. In particolare a me piace usare gFTP, perché mi permette di modificare e salvare i file in remoto in maniera veloce.

Aprite con l’editor il file solitamente più spendaccione, tipo header.php, e navigate con il browser fino ad una qualsiasi pagina del vostro blog. A questo punto visualizzate il codice HTML della pagina che avete nel browser (in Firefox: click sx -> Visualizza sorgente pagina) e confrontate i due documenti… Potete tranquillamente eliminare tutti quei “bloginfo” o simili e sostituirli con i dati che trovate nel codice HTML, già convertito. Procedete allo stesso modo per gli altri file.php che costituiscono il vostro tema.

Stessa cosa, o quasi, per i widget della sidebar. In questo caso però dovrete procedere in tempi diversi:

  • A plugin/widget attivato, copiate da qualche parte l’HTML che vi interessa
  • Disattivate il widget incriminato (es: Categorie)
  • Create un nuovo widget Testo e incollateci dentro l’HTML appuntato prima
  • Ripetere. Sorridere :)

Assicuratevi di aver sempre un backup di tutto ciò che modificate e infine salvate/caricate il tutto. Vedrete miglioramenti tangibili nel caricamento delle pagine e nella generale snellezza delle poche funzioni rimaste attive nel vostro blog.

Ehi, mi dovete una birra!

— Note all'articolo:

  1. Beh, “aiutato”… in realtà ha fatto tutto lui: io mi limitavo a fargli battute cretine via IM, e sospetto che lui ridesse solo per educazione [↩]

— Pagine forse correlate:

Etichette: , , , , , ,

Commenti »

1. NickM - 17/10/08 @ 9:44

Visto che mi sono divertito a leggere dell’atteggiamento $tr. e pignolo…

“Atteggiamento” è maschile, togli quell’apostrofo.

Ciao!

2. due - 17/10/08 @ 9:58

io invece di ftp uso direttamente gedit dopo aver aggiunto tra le risorse di gnome il server ftp interessato,modifico al volo tutto e salvo direttamente dall’editor

3. sevencapitalsins - 17/10/08 @ 10:38

NickM #1 , hai mai pensato che anche “apostrofo” fosse maschile?

Hai sbagliato tu.

Ciao!

4. HVP - 17/10/08 @ 10:41

è serio il primo commento?

5. zidagar - 17/10/08 @ 10:46

Tecnica sicuramente interressante, che anche io la uso ogni tanto su qualche pagina in php…solo che ho imparato a non farne abuso, più che altro per la portabilità del codice che in questo modo svanisce in buona parte.

Dipende tutto da ciò che si vuole fare. Ogni scelta ha un suo costo :D

6. BoySka - 17/10/08 @ 10:49

Ma questa cosa non la fa gia’ WP Super Cache?? Altrimenti a che serve?

7. federico - 17/10/08 @ 10:53

@sevencapitalsins
ripassati l’italiano.
-con un articolo determinativo l’apostrofo si mette: “l’apostrofo”,”l’amico”,…
-con uno indeterminativo (per sostantivi maschili) no: ” un amico” “un apostrofo” “un atteggiamento”

@felipe
“Ho abbandonato l’abitudine di rendere pubblici i numeri di pollycoke”.
…perché poi invece lo fai? (e in grassetto anche).

8. NickM - 17/10/08 @ 10:59

@sevencapitalsins #3

Sì, lo penso tutti i giorni… Grazie dell’attenzione. Il mio comunque era un commento ironico a Felipe…

Se hai tempo, però, vai a ripassare gli aggettivi dimostrativi, ti lascio il link:

http://it.wikipedia.org/wiki/Aggettivo_dimostrativo

…..

9. felipe - 17/10/08 @ 11:05

@NickM:
Haha, hai ragione ora correggo. Complimenti, sei ufficialmente uno str.. :D
:*

@zidagar:
Beh certo, ovviamente in questo caso non mi interessa per niente la portabilità :)

@BoySka:
Anche WP-Super-Cache trae vantaggio da questa ottimizzazione, perché ogni volta che una pagina “scade” deve comunque rigenerarla, ed eliminando istruzioni superflue si riduce il suo carico.

@federico:
Ho perso l’abitudine di farlo regolarmente, come un tempo, non certo il diritto di scrivere in grassetto quel cavolo che mi passa per la testa :D

10. NickM - 17/10/08 @ 11:07

@HVP
- è serio in funzione di migliorare la qualità degli articoli, cosa a cui Felipe tiene certamente e lo dimostra nel modo in cui scrive.
- è scherzoso per il tono…

Per me basta, non vorrei che si rovinasse l’articolo andando fuori tema.

:-)

11. cognatodituacugina - 17/10/08 @ 11:18

owned. (XD)

12. disconnesso - 17/10/08 @ 11:50

WP-Super-Cache è un plugin favoloso, purtroppo però non posso usarlo col mio servizio di hosting che è settato col PHP Safe Mode su On.

13. Mr Kuzio - 17/10/08 @ 12:01

Si, è vero: sei un genio! XD

14. Bigshot - 17/10/08 @ 12:39

if( is_single() ) { if( function_exists( related_posts ) ) { echo ‘
‘; echo ‘

— Pagine forse correlate:
‘; related_posts(); echo ‘
‘; } }

SEI sicuro di aver fatto tutto per bene :P ihihih

15. felipe - 17/10/08 @ 12:51

@Bigshot:
Sto facendo altri giochetti :P

16. Ottaviano - 17/10/08 @ 14:33

Non ho capito dove stia la genialata o_O mi sembrano tecniche di base queste O_o

17. Anonimo - 17/10/08 @ 14:45

tutte tecniche giuste ma io se fossi in te comprimerei i js (e già che ci sei anche i css) oltre che a togliere gli spazi…
prova inserendo nel .htaccess (sotto la sbrodolata di wpsupercache) queste righe

SetOutputFilter DEFLATE

anche perchè di js ne hai tanti, e grossi

18. SetOutputFilter DEFLATE - 17/10/08 @ 14:47

ops
non poswso inviare il codice…
ti linko questa pagina:

19. SetOutputFilter DEFLATE - 17/10/08 @ 14:50

http://solutoire.com/2008/02/18/top-3-website-speed-up-tips/

a metà pagina, in corrispondenza di # Gzip compression

(ho fatto un po’ di casino con sti commenti…)

@Ottaviano
vero, tecniche di base… che molti non conoscono/usano

20. mauro - 17/10/08 @ 15:04

@pollycoke:
quanti visitatori unici fai al giorno? in che % da google?

21. Ottaviano - 17/10/08 @ 19:11

@19

«Che molti non conoscono/usano»? e chi sono questi «molti»? se non erro questo dovrebbe essere un blog di smanettoni, ma a quanto pare…

22. Matteo - 17/10/08 @ 19:58

Hai fatto un po’ di profiling? C’e’ un incremento delle prestazioni?

23. Framp - 17/10/08 @ 20:25

beh, se vuoi una cosa leggera
prenditi un venerdì sera e scriviti un mini cms
vedrai dopo come ottimizzi

24. Luca - 17/10/08 @ 21:24

Ti consiglio di aggiungere all’elenco anche il plugin PHP_Speedy, un ottimo compressore di PHP.

http://aciddrop.com/php-speedy/

25. Flavio - 17/10/08 @ 22:55

Felipe, togliere un po’ di “chiamate” PHP è assolutamente inutile. TI consiglio invece installare XCache e di usare l’object cache di WP per scrivere su XCache. Così avrai opcode PHP e dati di WP cachati in memoria. Se ti servono più dettagli scrivimi.

26. Emanuele - 18/10/08 @ 12:15

Secondo me è eccessivo. Perdi portabilità del codice e Wp-super-cache genera le pagine solo una volta, inoltre la durata della validità puoi aumentarla per le pagine che non cambiano spesso.
Ciao,
Emanuele

27. Riccardo Iaconelli - 18/10/08 @ 14:12

“In particolare a me piace usare gFTP, perché mi permette di modificare e salvare i file in remoto in maniera veloce.”

son sicuro che lo conosci, ma… kwrite ftp://... non funziona?!?! (o semplicemente navigando l’ftp da dentro dolphin)

28. felipe - 18/10/08 @ 14:57

@Anonymous #17 aka SetOutputFilter DEFLATE:
Per inviare codice su pollycoke mettilo nel tag code (ovviamente togliendo gli spazi):

< code >
esempio di codice
< /code >

Per i js… la cosa è un po’ complicata, cmq ho messo in pratica il tuo consiglio, anche se già usavo la compressione gz di wpsupercache :)

@mauro:
Depende, più o meno quanti sono i lettori via RSS, a volte più a volte meno ;)

@Ottaviano:
Sento un’aura di negatività “tutto intorno a te” (cit)

@Matteo:
No, nessun profiling, ma la differenza di avverte

@Luca:
PHP Speedy: provato e cestinato ;)

@Flavio:
“Assolutamente inutile”… sicuro di quel che dici? Eliminare query MySQL (perché in genere si tratta di quello) e altro codice non mi sembra proprio inutile. Se ti va di evidenziare qualcosa su XCache faresti un favore a tutti, non solo a me in privato :)

@Emanuele:
Non mi serve che il codice sia portabile.

29. tosky - 18/10/08 @ 15:28

felipe, in relazione a quanto detto da Emanuele: più che per la portabilità, non potresti avere qualche problema quando aggiorni wordpress? Se ci sono modifiche dove inserito dati statici invece del codice, ti ritrovi a controllarle una per una (possibilmente con diff).

30. felipe - 18/10/08 @ 16:22

@tosky:
Infatti questo capita, ma solo per le (pochissime) modifiche che apporto al codice di Wordpress strettamente. Quelle di cui parlavo in questo post riguardano esclusivamente il tema, che poi è in genere il collo di bottiglia. Quello lo si aggiorna difficilmente.

31. TonyH - 18/10/08 @ 18:49

il render della pagina HTML è a carico del client e non del server dunque comprimendo il css/js/html risparmi al massimo qualche byte di banda e per il resto un qualsiasi sistema di cache lato server per la generazione delle pagine risolve il problema delle eccessive chiamate al parser php e al database e sicuramente il tuo problema non deriva dall’uso di CPU per generare le pagine ma pittosto dalla banda che usi e da apache che riceve troppe chiamate http il resto è fuffa

32. felipe - 18/10/08 @ 20:20

@TonyH:
È vero sono fino ad un certo punto.

* Il caching aiuta molto, ma considera che ogni volta che una pagina viene commentata (o allo scadere del tempo impostato) il codice php deve essere nuovamente intepretato per generare l’html statico.

* Sai quante richieste di pagine riceve il povero apache2? Moltiplicale per quella trantina di javascript *fisse* per ogni pagine, più varie ed eventuali… avrai un bel lavoraccio.

Concordo con te che le ottimizzazioni esasperate lasciano il tempo che trovano, ma non è esattamente “fuffa” :)

33. TonyH - 19/10/08 @ 13:22

anche il javascript è a carico del client, sarebbe diverso se usi AJAX che ri-genera una richiesta al server

34. felipe - 20/10/08 @ 0:46

@TonyH:
Certo che uso AJAX, si vede anche da una veloce occhiata al sorgente di questa pagina. Il discorso però non è solo questo: la richiesta server in realtà sono molte, troppe richieste al server, e per quello non c’è molto da fare (e non si possono comprimere e concatenare 27 js di plugin differenti, perché succede l’apocalisse).

35. lollo78 - 21/05 @ 18:00

Leggendo le prime battute dei commenti, capisco perché hai scritto “un atteggiamento stronzo e pignolo, che sono sicuro non vi manca”.
Se tutti i tuoi 1400 utenti iscritti sono così… mio caro Pollycoke… so’ caxxi tua!
AHAHAHAH!!!
Gran bel blog, continua così!
Ciao

36. Kneellaeracle - 20/10/10 @ 5:04

There are many different purpose you might need to discover ways to leap large. You will be a higher institution sportsperson endeavouring to raise your efficiency around the golf ball ct or simply you might be someone who only just says they’ve already an amazingly compact up and down (don’t stress, you’re not by yourself). A large huge amount of options to carry out studying easy methods to pull off a superior top to bottom. Even if, often times there are key points that every individual likes to propose prior to them getting started off:

The main matter to recognize might be that there’s not a secret ( blank ) to running higher. Relatively, you have got to work in the right muscular tissue along the right time for if you carry out the following successfully, one can learn how to rise bigger only exclusively by yourself genuine skills.

Firstly, while studying how you can go better, you ought to focus on your calves. Nice activities encompass digits soars and additionally leg heightens. Later on whilst, you’ll choose to work your way as long as four hundred or even 700 of.

The suitable Activities

The next step in grasping methods to rise substantial is always to appreciate whatever a person’s work outs. Bouncing inside and outside themselves is a wonderful physical activity. Pouncing piece of string is an efficient solution promotions . would like to an item that doesn’t appearance ridiculous. But, merely pouncing top to bottom at a time is going to be simply as beneficial. You will also just want to develop your current thighs and legs as the best lean muscle exercise when traveling individuals top lost vertical jumps.

You should carry out that exercises the right way in order to avoid any kind of damage (discuss with some discipline if you need to guidance getting them decrease adequately [url=http://howtojumphigher101.com]How to jump higher[/url]