Pequeña optimización para WordPress
Publicado el Martes 11 de Septiembre del 2007 @ 13:11 por Armonth.
- 17
- 2
Comentar
WordPress incluye de serie en las ramas 2.3 y 2.2.x (quizá también en la 2.1.x pero no me suena) un pequeño fichero de 17KB llamado wp-includes/deprecated.php que como su propio nombre indica incorpora funciones y variables que ya no serán usadas y son sustituidas por nuevas.
Un ejemplo de lo que ofrece son variables globales como $tableX donde X el nombre de una tabla y es que ahora se llaman mediante $wpdb->X o funciones como get_postdata() que es sustituida por get_post(). Y así unas cuántas más.
El caso es que en PHP cada vez que se incluye un fichero — se haga algo o no con él — hay un pequeño incremento de memoria usada proporcional a la cantidad de código. Incluso si nos ponemos a hilar fino, el simple hecho de leer un fichero ya supone un acceso de lectura a disco.
Llevo un tiempo haciendo pruebas para ver que cosas se pueden quitar de WordPress sin “joder la marrana” y aunque podemos llegar a tener un script mucho más ligero a saber que nuevos problemas podemos generar (sin “errores aparentes” he bajado un WordPress 2.3beta2 de 6900KB de memoria consumida a 5600KB pero claro, hay que quitar cosas que para otras personas sí son útiles). Ésta es una de ellas y podemos quitarla sin problemas casi en el 100% de los casos.
Salvo que se utilice una plantilla muy antigua que haga uso de alguna de esas funciones (lo cual ya de por sí no es recomendable) podemos quitarlo simplemente comentando su llamada, en el fichero wp-settings.php cambiamos:
require (ABSPATH . WPINC . '/deprecated.php');
Por:
#require (ABSPATH . WPINC . '/deprecated.php');
El cambio es pequeño y no impactará notablemente en el rendimiento pero ahí queda la idea de que con un poco de maña podemos ir quitando funcionalidades innecesarias.
Otra que he quitado sin mayores consecuencias ha sido cron.php (mismo sistema, dos líneas por arriba de la de deprecated.php) pero a saber cuántos plugins o funcionalidades dependen del mismo (seguramente, y sólo para empezar, las entradas programadas a futuro).
Como curiosidad, si a alguno se le ocurre quitar el default-filters.php aparte de conseguir uno de los WordPress más inseguros de la historia podrá ver en el APD unas 1500 “llamadas” menos ^_^U.
17 Comentarios (feed)
-
Gura nos comenta:
Deverías decir en el 99.999 de los casos, ya que el 100% no existe :D
-
chuano nos comenta:
El Wordpress necesitaría una revisión importante en cuanto a consumo de recursos, es una mula vieja…
Yo creo que tras las version 2.3 que añade algunas funcionalidades demandadas (especialmente el sistema de tags) debería pararse el desarrollo en cuanto a nuevas funcionalidades, y dedicarse a limpiar, minimizar y optimizar el código. Que se consuman casi 7Mb de memoria es algo increible y seguro que se podría reducir muchísimo.
Además, según lo poco que he visto, los plugins e includes se meten en todas las páginas, podría plantearse hacer includes más selectivos, solo donde hagan falta. Si estoy muy equivocado decidlo :)
-
Armonth nos comenta:
Gura dime la diferencia entre “casi el 100%” y “el 99.999″ }:P
Chuano eso lo llevo pensando yo tiempo, quizá una solución seria considerar tres comportamientos para los plugins, al menos como primera medida correctora:
- Backend: sólo se carga el plugin en el backend (Dashboard), viene ideal para cosas como el Google Sitemaps.
- Frontend: lo mismo pero sólo fuera del Dashboard.
- Mixed: comportamiento “actual”.
-
chuano nos comenta:
Sí, realmente es una burrada en mi opinión que plugins que solo se utilizan en el panel de administración se carguen en la parte “publica”.
Además hay partes del código de wordpress que _seguro_ se pueden optimizar muchisimo. Acabo de comprobar que el sistema de blogroll utiliza nada más y nada menos que 119kb de memoria…
Yo lo tengo escrito a pata y voy a comentar las líneas referentes, ando justito de ram.
-
adrian nos comenta:
Sip, yo estuve este fin de semana pasado “recortando” varias cosas y por el momento parece que sin “daños colaterales”… :P
-
alex nos comenta:
Una ventaja de los que tenemos blogs pequeños es que no tenemos que preocuparnos tanto por esos temas de rendimiento :-D
-
aNieto2k nos comenta:
Creo que aqui tenemos que tener en cuenta muchas cosas, lo que más hace un blog es mostrar el index, por ese motivo parece lógico pensar que atajando por aqui podríamos conseguir bajar el consumo.
El problema, es que lo que realmente hace trabajar al server, es todo lo que se hace cuando se escribe un post o un comentario (pingback(trackback). Por este motivo, estas soluciones, enfocadas a mostrar por pantalla únicamente reducirán el consumo de memoria pocos KB.
Hector, tambien es raro que la version limpia de Wordpress 2.3beta2 consuma casi el doble que aNieto2k con la versión 2.2 y una buena ristra de plugins cargados… habrá que indagar más sobre el tema.
-
chuano nos comenta:
Exacto, hay que reducir en todo lo posible el consumo, tanto de cpu como de memoria, en las impresiones de páginas, que es lo que carga el servidor por cantidad.
¿La mitad de memoria aNieto2k? ¿Cómo lo haces? Mi WP 2.2.3 conmsume casi 6500kb, y aunque tengo algunos plugins, no son demasiados.
-
adrian nos comenta:
Yo me he cargado, entre otros, todos los scripts de importación (no se cargaban pero nunca los voy a utilizar), clases como “snoopy” (que servía para leer mediante pop3 para publicar entradas vía correo) y algunas otras “inútiles”. Algún día tendré que ponerme más a fondo y entrar en el código para borrar muchas otras cosas.
Para reducir el consumo obviamente utilizo wp-cache y no permito el registro de usuarios para asegurarme de que la web se sirva prácticamente como un html (en wp-cache se genera una “copia” para cada usuario registrado).
Aún así el usar multitud de plugins me lleva a estar en torno a los 8MB en cuanto a memoria consumida se refiere. Y según los logs de Dreamhost, 3-4000 segundos de media con picos de 9000.
En fin, un verdadero mastodonte que hay que poner a dieta.
-
Manz nos comenta:
Desconozco como se mueve el Wordpress en estos temas, pero sería bueno revisar sobre todo el uso de variables globales. Casi siempre en PHP se pueden obviar, o utilizar en funciones el paso por parámetro. Esto, junto a lo que comenta Armonth y chuano de los includes “selectivos” es una buena forma de reducir la memoria.
Yo he seguido programando y he conseguido que mi CMS (no Wordpress) sólo consuma 180kb en la página principal y 300kb en artículos concretos aplicando esas técnicas.
-
Sergio nos comenta:
sabes armonth he encontrado que la ultima wp va mucho mas rapido, en tiempo de carga y tambien en el dashboard, creo que me hizo bien actualizarme, pero a que costo!!!!
si vi el mismo archivo, el deprecated, me llamo la atencion….
saludos!!!
-
adrian nos comenta:
Puede que a alguien le interese. Reducí en 2MB la carga desactivando por un lado el plugin Simple Tagging (que tampoco utilizaba mucho, más o menos 400KB), Google Sitemaps (lo activaré cada cierto tiempo para reconstruir el sitemap, 500KB) y Dean´s Permalink noséqué (100KB).
Además, desactivé la traducción de Wordpress con lo cual no se carga el gettext.php ni el streams.php, además del archivo MO correspondiente al español. En el template no debería notarse, únicamente en las fechas las cuales se pueden traducir directamente en wp-l10n.php. El menú, lógicamente, aparecerá en inglés. Esto me redujo prácticamente 1MB.
En total, de 8 a 6MB, no está mal :)
PD: estoy intentando eliminar la gestión de enlaces, la cual no utilizo. A ver si esto vale para algo.
-
Pablo nos comenta:
Ya el otro día en el blog de aNieto2K dejaba un comentario acerca de las cosas que me parecían que debían ser optimizadas. Mencionaba el dema de los “filtros por defecto”, que se aplican a través del sistema de plugins de WordPress y no me sorprende que se hagan 1.500 llamadas je…
En fin, creo que muchas de esas cosas deberían incorporarse en el núcleo de WordPress, al menos los filtros más importantes y que tienen que ver con la seguridad.
-
Armonth nos comenta:
Adrian más o menos lo mismo que ya comenté yo en una entrada de hace poco sobre memoria, plugins y wordpress (en mi caso, UTW 700KB, Google Sitemaps 500KB y sí: te quitas 1.2MB más con el cron, gettext, deprecated, blogroll, etcétera).
Lo malo es el peligro de “provocar” algún fallo en una de las “borradas” conseguí algo inesperado: la página tardaba 0.121seg en generarse (lo normal: 0.300s) y 3mb menos pero hacía ¡92 queries! Por lo visto pasó de 22 queries por defecto a 10 y algo se jodió creando bucles a la hora de hacer peticiones al MySQL :|.
-
Shora nos comenta:
Qué pena, he probado la optimización. Pero con el plugin de image-manager, me da un error bastante hermosote :/
-
Pablo nos comenta:
A mi me da error con popStats =/
-
g30rg3_x nos comenta:
Bueno metiéndome un poco en el tema…
Primero no pueden comparar un script/cms hecha en casa encontra de WordPress se me hace injusto para los dos bandos, ya que su script considera el ambiente/ámbito en el que esta ejecutado a diferencia de WordPress que tiene que considerar muchísimas variables, muchísimos ambientes y los entornos mas hostiles; en fin resolver muchísimos problemas con la compatibilidad de WordPress.
Talvez uno salga diciendo que no es un pretexto, si no es un pretexto para que WordPress no corra limpio y suave pero si es un tema a tener en cuenta antes de hablar, si bien algunas cosas todavía se pueden mejorar (yo apunto -hasta lo que he podido analizar- un 30% del total del código se podría mejorar) eso se tendría que tomar con calma y no hacerlo a la ligera.IMHO una buena forma de optimizar WordPress seria hacer que WordPress se puede separar para crear plataformas especializadas/personalizadas para cada tipo de usuario (al estilo como lo hace la mootools javascript framework) separando una la base o el núcleo de los “addons” o extras, así el usuario final (o usuario especializado) podría decidir que paquetes cargar en base a sus necesidades o tomar el paquete completo para los usuarios mas nuevos; claro suena linda/hermosa la idea pero para llevar acabo esto se necesitara mucho trabajo y tiempo (aparte de que se le cambiara un poco el giro) antes de poder ver esto.
Saludos