Te presento a RapidoPress

Publicado en RapidoPress, el fork de WordPress hace 2 años y 11 meses. Leído 2729 veces.

imagen destacada

Como vimos en su día, WordPress es un CMS lento y yo, lo reconozco, estoy obsesionado por hacer las páginas webs cada día más rápidas. Tenía que hacer algo con WordPress. Así que ni corto ni perezoso, me he puesto a quitar de WordPress cosas que no necesitaba o utilizaba de este, como son:

  • Todo código relacionado con los multisites
  • El links manager
  • Contextual help tabs
  • Soporte de emojis y smilies
  • Código deprecated de WordPess No sólo eso, me he puesto a eliminar widgets internos de WordPress:
  • Widget dashboard WordPress news
  • Widget dashboard Rss
  • Widget calendario ( ¿ alguien lo usa ? )
  • Widget rss
  • Widget meta
  • Widget Links
  • Widget Archivo También he eliminado los dos plugins WordPress( Hello Dolly y Askimet ) que vienen por defecto. El primero porque no sirve de nada y el segundo porque se puede instalar posteriormente al que lo quiera usar.

Finalmente, me he puesto a limpiar WordPress de algunas librerías javascript que ya no se usan o que son de soporte a navegadores antiguos( sobre todo IE ). Estas son:

  • jquery-migrate
  • Prototype Framework
  • Scriptaculous Root
  • Scriptaculous Builder
  • Scriptaculous Drag & Drop
  • Scriptaculous Effects
  • Scriptaculous Slider
  • Scriptaculous Sound
  • Scriptaculous Controls
  • SWFObject
  • SWFUpload
  • SWFUpload Degarade
  • SWFUpload Queue
  • SWFUpload Handlers

Por último, le tenía que poner un nombre al Wordpress resultante de mi fork. Me he decidido a llamarlo: RapidoPress. En RapidoPress, las mejoras de velocidad se notan bastante, aunque aún no todo lo que yo quisiera. Así que puede que saque una nueva versión quitando más cosas que no uso con mis clientes( ¿ Post formarts ?, ¿ Roles ? ) y tratar que la diferencia de velocidad con WordPress sea más pronunciada. La idea es mantener la misma esencia de WordPress pero sin cosas superfluas.

Sin más, aquí os dejo la versión 0.1 de RapidoPress. Importante: Ya está disponible la versión 0.4.

Por último, comentar que desde el principio del blog, y más aún desde hace unas semanas por el post que desaconsejaba usar los plugins de Caché en WordPress, estoy sufriendo un acoso y derribo por parte de fanboys de WordPress. Algunos, directamente atacando a mi persona. Mi decisión al respecto es que no les seguiré más el juego y dejaré de responder por redes sociales a este tipo de personas.

4 comentarios

Hola Manuel, interesante tu artículo. Si instalo la versión de rapido, los pasos a seguir son como una versión normal de WordPress, saludos y felicidades por el trabajo.

Escrito por Pep el 30-05-2015 a las 07:45

Hola, Pep,

RapidoPress es exactamente como WordPress( por lo menos, por ahora ) pero sin todo ese código que casi nadie usa. Así que la instalación se realiza de igual forma. También es compatible con el 99% de plugins y temas de WordPress.

Gracias, Pep Un saludo

Muy buenas Manuel,

¡Gracias por el aporte!

¿Has hecho algunas pruebas de carga para ver cuanto mejora respecto a WordPress?

Por otro lado, me surge una pregunta técnica que te paso a comentar:

Supongamos que hay algunas funciones/widgets de WordPress que si bien queremos deshabilitar, tampoco la queremos borrar (por si algún cliente la necesitara). Si en el Core de WordPress extraemos dichas funciones y la pasamos a otro archivo llamándolo con un include pero supervisado con un if para ver si corresponde meterlo o no. ¿Seria un buen método para evitar que cargue dicho contenido salvo que el usuario decida incluirlo? ¿O se te ocurre alguna manera mejor?

¡Gracias de nuevo! Un saludo

Escrito por Gonzalo el 30-05-2015 a las 10:41

Hola, Gonzalo

Sí, hace un minuto acabo de cambiar el WordPress de esta web por RapidoPress. Antes, el tiempo de respuesta de la web era de 1s a 1.1s de media( para la parte de WordPress). Ahora, el tiempo de respuesta ha bajado a 650ms a 700ms. Es decir, ha bajado más de 30%. Aunque donde más se nota es en la zona de panel( ya que es donde he quitado más código asociado ). Sin embargo, de esto no he hecho medida ( despiste, mío ). Aunque la mejoría es bastante apreciable.

Sobre tu pregunta técnica: Ahora mismo en WordPress se puede desactivar todo lo que yo he borrado. Pero, en la mayoría de los casos no te libra de que PHP tenga que analizar ese código y ejecutarlo. Además, de tener que analizar y ejecutar el código que hayas puesto para deshabilitarlo. Suena gracioso, pero es así. A mi eso no me hacía mucha gracia. ¿ Qué he hecho ?, borrarlo del core. Sin embargo, si para alguien son necesarias, gran parte de lo que he borrado se puede añadir nuevamente mediante plugins o mu-plugins.

Por ejemplo, si hago una nueva versión me gustaría borrar las “Tools” de WordPress que sirven para importar datos desde un sitio externo. ¿ Qué alguien las necesita ?, que se baje el plugin hecho por WordPress para ello: https://wordpress.org/plugins/wordpress-importer/ y https://profiles.wordpress.org/wordpressdotorg/#content-plugins

O incluso, si alguien necesita cosas que he borrado( como el soporte multisite que había código por todo el core ). Siempre se puede instalar la versión original WordPress.

El caso es que WordPress añade cosas que la mayoría de las veces no las necesitas o si las necesitas luego sueles instalar un plugin externo porque lo hace mejor. Entonces ¿ para que tenerlo en el core ?. No sólo eso, hay cosas que nadie usa pero que están en el core de WordPress porque les da pereza quitar. Por ejemplo, una de las cosas que he quitado es el links manager ( https://codex.wordpress.org/Links_Manager ) que nadie usaba, porque casi nadie sabía que estaba ahí, pero era código que se cargaba cada vez que lanzabas una petición desde el navegador para ver una página web con WordPress.

También hay mucho código( ya he quitado gran parte en RapidoPress ) por compatibilidad para versiones anteriores. En ese caso, como comenté antes, si lo necesitas usas WordPress sino usa RapidoPress.

Mi idea al hacer RapidoPress es que fuera lo más minimalista posible y el que quiera añadir funcionalidades, como tu bien decías, que lo haga mediante plugins o muplugins.

Espero haya resuelto tus dudas, sino es así, no te cortes y pregunta.

Gracias a ti por tu interés.

Un saludo

EDITO:Gtmetrix de 14 de Abril antes de RapidoPress. Gtmetrix de hace un minuto usando RapidoPress. Diferencia de más de medio segundo. Parece poco, pero es bastante para un sitio tan optimizado como este.

Excelente articulo Manuel, como siempre ayudando a mejorar a los demas, ¿Existe alguna manera de pasa un WordPress normal online a Rapidopress si que este se elimine?

Escrito por Francisco el 30-05-2015 a las 12:43

Fran, yo lo he hecho y sin problema. Te digo los pasos que hacer:

-1. Comprobar que en local todo va bien y que es compatible con los plugins que utilizas. En principio no debería de haber problema a no ser que alguno use código obsoleto o deprecated. En ese caso no funcionará porque he quitado toda compatibilidad hacia atrás de WordPress. -2. Descomprimir el zip de RapidoPress, que te creará una carpeta llamada, lógicamente, “rapidopress” -3. Sube la carpeta rapidopress al servidor remoto sin borrar la actual( que supondremos que se llama ‘public_html’ ) -4. Copiamos la carpeta wp-content y los archivos wp-config.php y .htaccess a la carpeta rapidopress -5. Renombramos public_html como ‘antigua’ y rapidopress como ‘public_html’ -6. Y a disfrutar RapidoPress.

Si acaso antes de renombrar el directorio, comprueba los permisos.

¡Gracias por la rapidez!

Pues si que gana bastante en la carga.

Respecto a mi pregunta, entiendo que el objetivo final de rapidoPress es minimizar al máximo y por eso no te han surgido dudas al eliminar estas funcionalidades (que por otro lado me parece perfecto).

Pero quizás de cara a seguir optimizando, digamos que eliminamos las taxonomias en un futuro, o simplemente estamos en otro proyecto de similar características, pero para no limitar tanto el CMS por si alguien realmente lo necesita le ponemos una página de configuración donde entre otras cosas tendrá esta opción de activar/desactivar las taxonomías.

Para ello, hemos eliminado todo código del core referente a estas y a cambio hemos añadido un condicional para que cargue unos archivos externos que hemos creado con este contenido, entiendo que no será lo mismo ya que tendrá que detenerse a analizar el código de los archivos independientemente esté activo o no, pero al no tener que ejecutarlo la optimización también sería considerable, ¿no?

No digo de usar esta solución para todas las funciones, pero creo que así se podría ganar aún más para ciertas funciones que en función del proyecto, si son necesarias.

Por lo demás me parece perfecto :) Para terminar, ¿has cambiado (o bloqueado) la fuente para comprobar las actualizaciones de rapidoPress y no machacar el core?

Gracias! Estaré atento a las actualizaciones de rapidoPress ;)

Escrito por Gonzalo el 30-05-2015 a las 12:54

Exactamente, Gonzalo, ese sería un buen camino a seguir. Sin embargo, por ahora quiero mantener la compatibilidad con WordPress. Llegado un momento habrá que decidir si se da el salto a ser un CMS diferente. En ese caso, como digo, sería como bien comentas: Una página, o bien desde la instalación, dónde tu puedas especificar que es lo que se carga o no.

Para la nueva versión, si la hago ( si veo que tiene buena acogida ), creo que haría los siguientes cambios: – Tratar que en la zona de administración se cargue sólo el css y el js esencial. Ahora se cargan también mucho css y js de plugins mal hechos. Lo que hace que usar el panel WordPress sea algo insufrible. – Eliminar los css rtl ( no creo que ninguno de mis clientes, ni nadie que pruebe RapidoPress, los vaya a usar ) – Eliminar pressthis – Eliminar cadena de gettext que ya no se usan porque he eliminado su código asociado. – Eliminar xmlrpc – Eliminar las tools ( ya que existen plugins de WordPress que hacen lo mismo ) – Eliminar los post formats

Un saludo – P.D: Sí, Gonzalo, está quitado para que no se pueda actualizar WordPress . ;)

Hola Manuel! No sé si comentar esto aquí o en el hilo de CMS lento. Bueno, al lío:

Normalmente estoy en contra de hacer forks de algo que tiene updates frecuentes, porque… realmente estarás disponible para hacer revisión de cada update e integrar los cambios (sobretodo si van relacionados con seguridad o estabilidad) o simplemente si algún plugin a alguien deja de serle compatible?

Siguiendo el espíritu de WP, debería poderse “desactivar” todo esto vía el functions.pho de tu theme o vía un plug-in. Obviamente el peso al hacer el upload del WordPress en sí no vas a poder solucionarlo, ahí estarán las obsoletas librerías de Scriptaculous, etc.

…si algo no puede desactivarse mediante un filter o un remove action, entiendo que a esa sección de código WP le falta un filter/action… (desconozco si los chicos del WP trac hacen mucho caso o no)…

Bien, en todo caso, te pongo un ejemplo de como desactivar los emojis (acojonante que hayan añadido esa librería por defecto y no como opción), para ilustrar lo que quiero decir:

remove_action( ‘wp_head’, ‘print_emoji_detection_script’, 7 ); remove_action( ‘admin_print_scripts’, ‘print_emoji_detection_script’ ); remove_action( ‘wp_print_styles’, ‘print_emoji_styles’ ); remove_action( ‘admin_print_styles’, ‘print_emoji_styles’ );

en fin, hacer un fork implica muchísimo trabajo (mantenimiento, soporte, etc) y, ya puestos, creo que vale la pena si se añaden funcionalidades extra que requieran una modificación importante del core… ahí va mi humilde sugerencia:

Al hilo del problema comentado en tu interesante post del CMS lento, le he estado dando vueltas a que todo cuelgue de una tabla wp_posts. Creo que un paso de gigante hacia un auténtico CMS sería que cuando se define un CPT se pudiera especificar que este estuviera en otra tabla, una tabla dedicada.

Esto presenta no pocos problemas, obviamente… WP asume que un POST de cualquier tipo puede ser manejado sólo por su ID, puesto que están todos en la misma tabla… por ejemplo, la relación entre terms y posts no especifica el custom post type, puesto que no hace falta… y de forma muy sencilla te permite que una taxonomía sea compartida entre varios post…

… y ya puestos, WP creo que debiera ser multiidioma y tener herramientas de caché nativas…

Escrito por Carles Reverter el 01-06-2015 a las 08:14

Hola, Carles. Tus comentarios son siempre bienvenidos da igual dónde los pongas jejeje.

Eso que dices de los filters/actions lo pongo en un comentario más arriba del tuyo. Como poder se puede desactivar, pero eso no evita que el código php se tenga que leer y ejecutar( tanto el de WordPress como el tuyo a desactivarlo ). En el caso de los emojis/smiles la ventaja que tienes es que te ahorras la descarga de los archivos javascripts/css pero, como digo, hay otros código PHP como son el parseo de los contenidos, cuando los guarda, en busca de emoji que se seguirán ejecutando. Porque te tengo que decir algo importante: mientras que he estado navegando por las entrañas de WordPress he visto cosas que nunca creerías….:) por ejemplo, vete al archivo de cualquier WordPress: wp-admin/includes/template.php y mira el comentario de arriba. Eso resume mucho de lo que he visto.

Respecto al tema de las actualizaciones. La verdad es que la idea de RapidoPress era simplificar en plan “hobbie” para luego escribir las experiencia en el blog. SIn embargo, he visto que ha tenido mucha aceptación y me temo que tendré que seguir con él, en plan serio, con todo lo que eso conlleva. Por suerte, WordPress actualizan con pocos cambios y todos ellos son fácilmente identificables por su trac. No sólo eso, como estoy quitando mucho código, casi todo lo que actualizan está en esa parte, con lo que me ahorro de hacerlo. :)

Ahora mismo quiero tener la máxima compatibilidad posible con WordPress, por lo que la base de datos será lo último que toque( y no será por ganas ). Pero, yo le daría la vuelta a lo que dices. En vez de que los custom posts tenga su tabla dedicada, crear una diferente para imágenes, elementos de menús, … y toda esa mierda que se guarda en la tabla de wp_posts que no son posts. ¿ No crees ?.

Lo de multidioma darlo por hecho, un MVC( aunque no lo hayas dicho pero sé que tendrías ganas ) también, … pero estamos en las mismas, eso cortaría compatibilidad ( porque, por ejemplo, para el multidioma lo suyo es meter un campo más en la base de datos ).

Ahora mismo me voy a centrar en mejoras de optimización y de facilidad para el desarrollo, algunas que tengo en mente a ver que opinas: – Subir la compatibilidad a PHP 5.5 – Que además del functions.php se cargue el functions-admin.php si estamos en la zona de administración o el functions-theme.php si estamos en el tema. – Añadir lessCss para todos los archivos de CSS y que estos se cacheen. – Que se puedan crear templates de página mediante código ( inclusive en los plugins ). – Que en los actions se pueda especificar un archivo. Por ejemplo: add_action(‘admin_init’ DIR.’/eventos/admin_init.php’); -> esto incluiría el archivo /eventos/admin_init.php al suceder el eventos.

y cosas así. También cambios para saber que pasa cuando hay errores ( y olvidarnos del pantallazo blanco de la muerte ) Es decir, ahora toca cambios que no rompen con la compatibilidad con WordPress pero que hacen mucha falta. ¿ Qué te parecen ?

Muchas gracias por el artículo y por Rapido. Ha sido toda una lección sobre cómo optimizar WordPress. Realmente interesante, porque como bien comentas, muchas de las opciones que solemos desactivar siguen ejecutando código y perdiendo tiempo de forma innecesaria. Enhorabuena de nuevo por el artículo, es para releer. Saludos

Genial idea! enhorabuena!

No quitaría los Post Formats ya que permiten hacer blogs con mejores diseños sin crear Custom Post Types.

En cuanto a roles, no se, puede ser, pero quizá dejar dos?

Alguna idea sobre el REST API ?

Escrito por Pancho el 01-06-2015 a las 22:54

Gracias, José Miguel y Pancho.

Pancho, ahora mismo todo lo que he dicho lo dejo en el aire. Ha tenido mucha repercusión Rapido y por lo mismo, ya no puedo hacer cambios a la ligera. Es decir, todo cambio ahora lo tengo que hacer bien pensado y razonado porque influye a muchas personas y posibles webs que lo tengan.

Saludos

Hola Manuel. Me parece todo muy bien todo lo que comentas… respecto al parseo de los emojis y tal, tienes razón… pero si no te gusta el código de WP, ni se te ocurra mirar el de Prestashop, con su modelo-birria-controlador… jajaja…

…de lo que has dicho, sólo matizaría el tema de la tabla wp_posts. Cuando haces un site a medida, puede ocurrir que un CPT en concreto tenga 10.000 registros. Es interesante que ese CPT esté segregado. Si hablamos de un blog al uso, es justamente el post estándar el que debiera estar segregado del resto, o dilo al revés: el resto fuera :). En cambio, en la mayoría de sites, que estén revueltos 10 elementos de menú entre 100 posts más no tiene problemas de rendimiento… bueno, es de traca que el menú no esté cacheado en WP, pero no arreglamos nada por segregarlo en la BBDD…

Respecto al LessCSS, he descubierto un programa llamado Koala. Compila en background el LESS y el SASS, comprime todo, incluso JS, y lo más importante, genera .map, así, de manera transparente, chrome te dice la línea del fichero LESS dónde está el gazapo… en resumen, no considero necesaria ya la compilación LESS en server…

Y ya puestos con las peticiones, customizar el backoffice estaría muy bien… personalmente, me gusta el modelo de Woocommerce, dónde creas una carpeta de templates dentro de tu theme y si estos ficheros existen, reemplazan los que trae por defecto… (con sus inconvenientes, que los tiene, ojo)…

Mucho ánimo con este proyecto, lo seguiré de cerca!

Escrito por Carles Reverter el 02-06-2015 a las 11:40

Hola, Carles, Lo primero mis disculpas por tardar tanto en publicar y responderte. Ayer la fecha de entrega de un proyecto y no he tenido tiempo.

Lo del tema de custom posts es cuestión de mirarlo, pero antes viene mejor el multiidioma,¿ no crees ?, aunque pienso que los cambios se irán dando.

Respecto a less, recuerda el nombre del fork( rápido ), una compilación de less en cliente es quizás más efectiva pero más lenta. Yo suelo usar un librería php llamada less.php, de hecho esta web está hecha con ella. No hay que compilar los archivos a mano. Es el propio código mío el que genera una vez un archivo compilado, y minimizado, y no lo vuelve a hacerlo hasta que se cambia el css original. Con lo que al final, las webs van mucho más rápida y encima con las ventajas que te da less.

Gracias por todo Carles y por tus sugerencias. Veremos como acaba esta aventura de rapido jejeje.

Un saludo

Hola! Es un gran proyecto, te felicito.

Me generó ciertas dudas tu opinión sobre los Plugin de Caché en WordPress asique leí el post al que linkeas. Me gustaría saber cuales son las alternativas que planteas? Y más específicamente aún: Qué alternativas planteas para quienes no tienen grandes conocimientos de optimización? Osea, para alguien que no es 100% técnico.

Gracias, saludos!

Hola, "Digiteando"

Gracias por el interés en el proyecto. Parece, por los últimos comentarios que voy recibiendo, que hoy tiene más aceptación que en su día. Eso me da a pensar que quizás convenga retomarlo. Sobre las alternativas a los plugins de caché, eso es un post que tengo pendiente de hacer. De hecho, iba a ser el siguiente en escribir. Así que si tienes paciencia en una semana estará disponible.

Un saludo.

Deja un comentario

Puedes usar Markdown para formatear tu comentario.

Este sitio utiliza cookies propias y de terceros para mejorar tu experiencia con el sitio web. Al continuar con la navegación consideramos que acepta su uso.