Articolo scritto da Andrea Cardinali.

Molti di voi come me si saranno posti almeno una volta questa domanda. Sul web ci sono diverse opinioni più o meno autorevoli a riguardo, quelle più in voga sono le seguenti:

/%category%/%postname%/   o in alternativa : /%postname%/

Affidandomi a questi consigli mi sono ritrovato con un sito lentissimo e inutilizzabile.

Se  anche i vostri permalink hanno questa struttura, non preoccupatevi perché vi spiegherò come potrete risolvere il problema.

Prima di tutto spiegherò perché questa struttura è la meno performante.

Alcune informazioni fanno riferimento a versioni di WordPress precedenti alla 3.3. Consiglio di controllare la sezione Aggiornamenti

1.      Come funziona WordPress

WordPress come qualsiasi CMS ha bisogno di “capire” quale pagina o post restituire in base all’url richiesta; questa processo richiede un certo numero di ricerche all’interno del database e a seconda della sua dimensione questo processo può richiedere più o meno tempo.

WordPress ha una serie di regole (RewriteRules) memorizzate al suo interno che vengono confrontate ad ogni richiesta con l’url richiesto. E’ importante quindi che siano poche e il più efficienti possibile.  Leggendo il codice sorgente si vede che le regole utilizzate  sono le seguenti (notare l’ordine):

1. /robots.txt (File robots.txt virtuale)
2. /feed/*
3. /comments/*
4. /search/* (url seo friendly per le ricerche)
5. /category/%category% (archivio delle categorie)
6. /tag/%tag% (archivio tag)
7. /author/%author% (archivio autori)
8. /%year%/%month%/%day% (ricerca per data)
9. /%X%/%Y%  (struttura personalizzata definita dall’utente)
10. /%pagename% (qualsiasi pagina)

WordPress inizia a confrontare l’url richiesta con le regole dall’alto verso al basso e si ferma quando trova una corrispondenza.  Se non esiste viene restituita una pagina 404.

Da questa gerarachia si nota come le regole sono (dall’alto verso il basso) sempre meno specifiche e lineari.

Vorrei farvi notare che dal punto 2 al 7 (feed, comments, category ecc) sono presenti suffissi necessari a velocizzare la ricerca, e rimuovendoli si  va ad aumentare la complessità della ricerca.  Attenzione quindi ad utilizzare plugin quali WP No Category Base  e similari (WP SEO ad esempio) che permettono l’eliminazione del prefisso /category/.

Attenzione! Il numero di regole si triplicherà  in base al numero di categorie presenti per cui se ad esempio avete nel vostro blog 20 categorie, vi verranno aggiunte 60 regole (oltre alle 70 di default).

Più avanti nel post troverete anche come contare il numero di regole in modo da potervi rendere conto voi stessi della situazione del vostro blog.

2.      Il problema

Cosa succede quindi quando andiamo ad impostare la struttura dei permalink a: /%category%/%postname% ?

Le regole diventano (riprendendo la gerarchia):

8. […]
9. /%category%/%postname%
10. /%pagename% (qualsiasi pagina)

Violiamo il principio secondo il quale la regola successiva deve essere più generica della precedente e in questo modo diventerebbe impossibile accedere ad una qualsiasi pagina, in quanto WordPress si fermerebbe alla regola 9.

WordPress accorgendosi di questa situazione , setta quindi una variabile “use_verbose_page_rules” a true (wp-include/rewrite.php:1910)

// Enable generic rules for pages if permalink structure doesn't begin with a wildcard.
if ( preg_match("/^[^%]*%(?:postname|category|tag|author)%/", $this->permalink_structure) )
$this->use_verbose_page_rules = true;
else
$this->use_verbose_page_rules = false;

e quindi rigenera tutte le regole in questo modo:

1. /robots.txt (File robots.txt virtuale)
2. /pagina1/
3. /pagina2/
4. […]
5. /paginaN/
6. [….tutte le pagine…]
7. /feed/*
8. /comments/*
9. /search/* (url seo friendly per le ricerche)
10. /category/%category% (archivio delle categorie)
11. /tag/%tag% (archivio tag)
12. /author/%author% (archivio autori)
13. /%year%/%month%/%day% (ricerca per data)
14. /%category%/%postname% (nostra struttura dei permalink)
15. /categoria/news-1
16. /categoria/news-1/feed
17. /categoria/news-1/comments
18. /categoria/news-1/page

[…]

2000. /categoriaN/news-N
2001. /categoriaN/news-N/feed
2002. /categoriaN/news-N/comments
2003. /categoriaN/news-N/page

Come avrete notato l’aumento delle regole dipende dal numero di categorie post e pagine presenti.

3.      Come quantificare la gravità del problema

Tutte queste regole, sono salvate all’interno del database, nella tabella wp_options in una campo chiamato rewrite_rules. Nel database troverete una stringa che corrisponde ad un array serializzato. Ad ogni elemento dell’array corrisponde una regola. E’ sufficiente che controlliate il numero dopo a:

Ora diciamo che non esiste un numero che va bene e un altro no, l’importante è riuscire a tenere il numero più basso possibile. Nel mio caso, sono passato da 20247 a 305. Non male no? J

4.      Altri sintomi

Il problema è subdolo perché non si manifesta in modo immediato. Il sito inizierà ad essere (inspiegabilmente) più lento e la lentezza sarà direttamente proporzionale al numero di post, pagine e allegati inseriti (tutti memorizzati nella tabella wp_posts). Se il vostro sito genera genera e non avete plugin di caching su disco vi accorgerete che la cpu del vostro server sarà perennemente occupata al 100% dal processo che esegue php e/o dal processo MySql. Questo perché WordPress ad ogni richiesta effettuerà il parsing tramite regular expression di tutte le regole presenti all’interno dell’array. Nel peggiore dei casi quindi l’individuazione di un articolo può richiedere N confronti, per url richiesto, per utente. N naturalmente è il numero di regole generate.  Anche potenziando il server, la situazione non migliorerà di molto, allontanerete solo momentaneamente e parzialmente il sovraccarico del server.

Un primo campanello di allarme può essere il tempo trascorso tra la pressione del tasto salva/aggiorna e il momento in cui effettivamente WordPress ha terminato il caricamento dei dati.

Questo perché WordPress ad ogni aggiornamento, ricrea tutte le regole e le salva nel database.

Se durante questa operazione o durante la visualizzazione della pagina d’impostazione dei permalink ricevete il messaggio di errore “MySql has gone away” è perché il server non è in grado di aggiornare i dati nel database in quanto si stanno inviando troppi dati (= le rewrite rules serializzate). Vedi anche la sezione Aggiornamenti più sotto.

5.      La soluzione

A questo punto possiamo analizzare i risultati delle prove che ho fatto su una nuova installazione di WordPress, con o senza plugin per rimuovere il prefisso /category/.

Partiamo con il dire che le soluzioni che iniziano con un numero sono le più performanti. Naturalmente se il numero in questione è %post_id% si ottiene la soluzione più performante in assoluto. Anche iniziando con l’anno le performance sono molto buone e simili a quelle di %post_id%.

 

Dal grafico si  nota quanto esposto. A un valore più basso corrispondono prestazioni migliori.

Quindi nell’ordine:

1. /%post_id%/
2. /%post_id%-%postname%/ oppure /%post_id%_%postname%/
3. /%year%/%monthnum%/%day%/%postname%/
   /%year%/%monthnum%/%postname%/
   /%year%/%monthnum%/%category%/%postname%/

4. /%post_id%/%postname%/
5. /%postname%/
6. /%category%/%postname%/

Le ultime due strutture (quelle consigliate da tutti),  5 e  6 sono le peggiori, in quanto aumentano il numero di regole con l’aumentare del numero di pagine. Per ogni nuova pagina vengono infatti aggiunte 11 regole.

Dai test effettuati è inoltre emerso che utilizzando un plugin che rimuove il prefisso /category/) vengono aggiunte 3 regole per ogni categoria. (in questi test ho utilizzato WP SEO)

Vi posso tranquillizzare dicendo che gestisco un sito in cui sono presenti circa 500 pagine, più di 4000 news, 63 categorie e un paio di plugin tra i quali WP SEO che aggiungono regole a quelle già presenti di default. Il sito presenta attualmente circa 300 regole (di cui 190 create dalle categorie) e naturalmente è molto veloce nel restituire le pagine mentre prima della correzione ai permalink le regole erano circa 20.400 e un url impiegava diversi secondi per essere riconosciuto.

Ho cambiato la struttura da /%category%/%postname%/ a /%year%/%monthnum%/%category%/%postname%/ in quanto avevo la necessità di mantenere la categoria negli url più per una questione di usabilità che di SEO.

Per passare in modo indolore ho realizzato un plugin semplicissimo che si occupa di effettuare il redirect dagli url vecchi a quell nuovi. La realizzazione si è resa necessaria in quanto l’unico plugin disponibile Dean’s Permalink Migration non funziona correttamente in quanto invece di effettuare dei redirect 301 restituisce status code 404 Pagina non trovata.

Il plugin è disponibile a questo indirizzo: http://www.andreacardinali.it/wordpress/cardy-redirect-plugin/ e a breve anche nel repository dei plugin WordPress

 

6. Aggiornamenti

Visto che questo articolo sta creando diverse discussioni interessanti anche su Twitter, abbiamo deciso inserire qui, le informazioni più interessanti (aggiorneremo questa parte di volta in volta):

• Io e Andrea consigliamo la struttura n°2 per i permalink ovvero: /%post_id%-%postname%/. I motivi sono molteplici giusto per citarne un paio:
  • è performante
  • è sufficentemente ottimizzata per i motori di ricerca
  • torna utile per Google News. Come spiegato in questo articolo per inserire il proprio sito in Google News è necessario avere delle url con una parte numerica univoca (ovvero l’ID). Utilizzando l’ID nell’url si evita di dover ricorrere all’utilizzo di un sitemap specifica. Per sopperire a questa esigenza Andrea Pernici ha realizzato un comodo plugin per WordPress che permette la creazione automatica della sitemap news. Il plugin è disponibile qui. Per la cronaca è possibile utilizzare anche la struttura: /%post_id%/%category%/%postname%/ che pur non essendo così performante come quella consigliata si comporta comunque egregiamente.
• Il rallentamento si manifesta in maniera sempre più evidente con l’aumentare delle pagine. In teoria quindi evitando di utilizzare le pagina si può aggirare il problema.
• Utilizzando W3 Total cache si noterà che il numero di query effettuato verso il db è impressionante (nell’ordine delle centinaia) quando un sito “standard” non dovrebbe effettuare più di 20/25 query.

Aggiornamento del 20.07.2011

Gleenk segnala che Andrew Nacin, uno degli sviluppatori di WordPress ha detto che forse il problema verrà risolto con la versione di WordPress 3.3, di cui ancora non è stata stabilita l’uscita. Al momento è prevista entro il 2011. Potete quindi scegliere se attendere una soluzione o sistemare subito i problemi cambiando struttura e utilizzando il plugin da me realizzato.

Aggiornamento del 04.08.2011

• Utilizzare una struttura permalink che termina con un’estensione, sia essa .html , .php (o qualsiasi altra vi venga in mente) non porta vantaggi dal punto di vista di posizionamento.
• Sul blog ufficiale degli sviluppatori di WordPress, esattamente a questo indirizzo: http://wpdevel.wordpress.com/2011/07/27/wordpress-3-3-proposed-scope/ si parla delle nuove features che saranno presenti nella versione di WordPress 3.3. Tra le tante verrà risolto finalmente il problema di prestazioni legato alla struttura dei permalink di cui si parla in questo articolo. Due programmatori si sono fatti carico della risoluzione del bug, quindi non resta che attendere 😀

Aggiornamento del 03.01.2012

Il 12 dicembre 2011 è uscito WordPress 3.3 con diverse novità tra cui la risoluzione del problema di performance. Per sapere cos’è cambiato, vi invito a leggere questo articolo su Giorgiotave.it