WordPress es un CMS lento

Publicado en Optimización web( WPO ) hace 3 años y 5 meses. Leído 5807 veces.

imagen destacada

Más de una vez me he encontrado envuelto en el debate: ¿ es WordPress lento ?. Bueno, no es tanto debate cuando la única respuesta por parte de aquellos apegados a WordPress es que hay sitios con muchas visitas que lo tienen y su rendimiento es óptimo. Estos mismos parece que se olvidan que hasta el algoritmo de ordenación de burbuja se comporta bien para muestras excesivamente grandes si se "ejecuta" en un equipo potente. Sin embargo, eso no quiere decir que sea un algoritmo eficiente necesariamente( de hecho, no lo es ) si atendemos a su complejidad computacional. A WordPress le pasa lo mismo. A igualdad cantidad de información, requerirá un hosting mucho más potente que otros CMS. No sólo eso, sino como veremos, ya de por si es un CMS lento tenga o no tenga mucha información.

Esto no quiere decir que WordPress sea malo. Nada más lejos de la realidad. Igual que en un coche, la velocidad no lo es todo. En el mundo de los CMS pasa lo mismo. De hecho, gran parte de mis proyectos webs son con él. Sin embargo, cada proyecto es un mundo y, por tanto, hay que saber escoger las mejores herramientas adecuadamente con la cabeza y no con el apego.

Como soy una persona técnica, mis argumentos estarán basados en aspectos técnicos. Sobre todo cuando entiendo que WordPress es lento debido a su diseño. Invito a todos aquellos que no estén de acuerdo que me pongan un comentario con sus razonamientos.

Todo en una tabla.

Cuando estamos realizando un esquema de base de datos para un proyecto web, surge la duda si ir por lo práctico o por lo eficiente. En el caso de WordPress tiraron por lo práctico y agruparon tanto los posts, como custom posts, como recursos y versiones en una misma tabla: wp_posts. Esta acción tiene la ventaja de simplificar el código y las búsquedas ( aunque esto sea otra cosa de la que cojea WordPress como ya veremos en otra entrada ), pero como contraparte reduce drásticamente la eficiencia de WordPress. Algunos ejemplos para que se entienda:

  • Si tenemos 500 posts y cada uno tiene cuatro revisiones diferentes(la actual y tres más), es como si tuviéramos tratando con 2.000 posts.

  • Si tenemos 500 productos con Woocommerce y cada uno tiene una imagen destacada y cuatro como galería de ese producto, es como si nuestro CMS tuviera que trabajar con 3.000 productos.

  • Si tenemos un sitio web pequeño con 35 páginas y en él tenemos unos 35 elementos de menús,ya sea, con enlaces externos o internos. Nuestro gestor de contenidos trabajaría como si tuviéramos 70 páginas. Ya que cada elemento de menú cuenta como si fuera una entrada o una página en nuestro CMS. En este ejemplo eso no es mucho, pero lo pongo para que se vea otro de los factores que influye.

  • Si tienes 500 productos y cuatro idiomas, tu WordPress es como si trabajara 2.000 productos.

  • Ahora vamos a un ejemplo real a modo de resumen: Si tienes un sitio web con 500 productos y por cada uno de ellos también tienes una imagen destacada, cuatro imágenes de galería de producto y un pdf con información técnica de cada producto. Además, ese sitio también tiene blog con 200 entradas cada cual con sus correspondientes imágenes destacadas. Además, si has hecho el web con soporte a tres idiomas y estableciendo para que sólo haya dos revisiones por post. WordPress cada vez que lanza una consulta contra tu base de datos, ha de buscar entre más de 5.500 elementos. Desprecio otros como elementos de menú, páginas y custom posts. Consejos:

  • Limita el número de revisiones a dos o desactiva las revisiones completamente:

//Limita las revisiones a dos:
define( 'WP_POST_REVISIONS', 2 );
//Desactiva totalmente las revisiones:
//define( 'WP_POST_REVISIONS', false );
  • Borra todas las revisiones de vez en cuando. Puedes hacerlo lanzando la siguiente consulta sql:
DELETE a,b,c FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'
  • Se austero con las imágenes en tu sitio web. Tampoco añadas a tu CMS imágenes que no vayas a utilizar.

  • Evita tener multitud de menús si no son imprescindible. Elimina entradas de menús que no vayas a usar.

  • Si no te queda otra, porque así lo insiste tu cliente, que usar WordPress para proyectos medianos o grandes, trata de crear tablas auxiliares y así aligerar en lo posible la carga de wp_posts

Tu WordPress tiene alzheimer

WordPress busca la flexibilidad a cualquier precio, aunque sea a costa de velocidad. Quizás, porque en los principios sólo iba a ser un sistema de blogs y para ese caso tanta flexibilidad no podría causar tanto daño. Sin embargo, empezamos a usarlo como CMS y ahí empezaron los problemas de rendimiento ocasionados por la flexibilidad.

Déjame decirte una mala noticia: tu gestor de contenidos tiene alzheimer. Se le olvida todo de una petición a otra. Tendrás que repetirle en cada una de ellas los customs posts, los sidebars, o los menús que vas a usar. No te queda otra porque a él se le olvida. Es por ello, que si quieres añadir una entrada al menú del panel, por ejemplo, se lo tendrás que decir cada vez que se vaya a mostrar. Sí, da una enorme flexibilidad pero obliga a PHP y al CMS a procesar lo mismo una vez y otra vez, dando lugar a una perdida de eficiencia. Lo mismo le pasa a los plugins y es por ello que muchos plugins pueden ralentizar sobremanera tu sitio web. No por el sistema de plugins en sí ( que es magnifico como está pensado y programado ), sino por la obligación de los plugins de decir lo mismo una y otra vez y, por tanto, la necesidad de WordPress de recorrerlos completamente en cada petición.

Un CMS enfocado al rendimiento lo hubiera hecho de otra manera. Por ejemplo, haciendo que durante la activación del tema éste dijera que sidebars, custom posts o cualquier otro elemento necesita. WordPress lo registraría y se ajustaría adecuadamente de manera interna. Y lo mismo para los plugins. Pero, como digo anteriormente, un proceder así restaría mucha flexibilidad al CMS, algo que no les interesa.

Consejos:

  • Limita el número de plugins

  • Escoge temas minimalistas o que sólo tengan lo que necesites

  • Te recomendarán que uses un plugin de caché, yo no. Úsalo sólo en el caso que tu sitio web vaya extremadamente lento y siempre con pinzas. Hablaré de ello en otra entrada( edit: ya está disponible: No uses plugins de caché con WordPress ) , aunque básicamente es porque cortarás todo el funcionamiento interno de WordPress basado en hooks. Es decir, forzarás a trabajar a WordPress de una manera, que como hemos visto, no es la que han decidido para él.

Todo siempre a tu disposición

WordPress, como casi todo el mundo sabe, empezó como un sistema de blogs que se basaba en otro sistema anterior. No estaba pensado para proyectos grandes es por eso que su diseño tendió a lo simple. No clases, sólo funciones. Como cualquier aspecto de diseño, eso no tiene que ser algo necesariamente malo ( sino que se lo digan a los que usan escritorios realizados con GTK ), a no ser que busques la flexibilidad. Entonces, es cuando empiezan los dolores de cabeza.

Si vienes del mundo PHP, seguramente te sorprendas que con WordPress no has tenido ni que hacer requires, ni includes ni usar namespace. Es algo sencillo de entender, el motivo es que WordPress siempre carga todo su arsenal de librerías. Sí, siempre, las uses o no. Si lo sumamos a que tiene alzheimer, uff. Líneas de código que se tienen que leer si o si en cada petición. Un pasote. Pero, claro, piensa que es por la flexibilidad. Puedes usar una función del core sin tener que hacer un include a un fichero que puede que el día de mañana tenga otro nombre o esté en otro path.

A partir de PHP 5.6 hay soporte completo de namespace de funciones. Quizás esa sea una solución para WordPress. Pero en ese caso tendrán que tomar la difícil decisión de crear incompatibilidad hacia atrás. No sé lo que harán.

Nada puedes hacer para mejorar esto, ya que es parte del diseño de WordPress. Tan sólo te queda hacer tu parte, es decir, que tu código no siga esa línea. Si te decides a hacerlo, aquí mis consejos:

  • Crea funciones anónimas para los "actions" y que no sean más que un include a ficheros externos dónde tengas tu código. Así, si esa acción no llega nunca a lanzarse tampoco PHP tendrá que parsear todo el código. Ejemplo:
add_action('admin_init', function() {
    include(__DIR__."/zonas/panel/init.php");
});
add_action('admin_menu', function() {
    include(__DIR__."/zonas/panel/menu.php");
});
  • Para widgets, shortcodes y filtros, usa clases con namespace. Además, que estás clases se instancien mediante autocarga.
//Recomendable usar mejor: spl_autoload_register() 
function __autoload($classname) {
    $file = str_replace('', DIRECTORY_SEPARATOR, $classname);

    include_once(TRASWEB.$file.'.php');
}
add_shortcode( 'block', array('traswebshortcodesBlock', 'load') );
//...mis otros shortcodes, filtros y widgets, ....

Como resumen, hemos visto que WordPress tiene como principios de diseño a la simplicidad y flexibilidad, pero de una forma que le resta eficiencia. Hay que pensar que ninguna herramienta de desarrollo es buena para todo. Si alguien te lo presenta así es porque te está engañando o te vende una navaja suiza que no sirve para nada. WordPress cojea en su velocidad, pero para sitios webs escaparates es algo que no hay que darle mayor importancia. Para sitios en los que el negocio es la web se debería de plantear otras alternativas. Lo mismo para sitios con bastante tráfico. Si aún así queremos WordPress por su facilidad de uso y flexibilidad hemos de saber que habremos de compensarlo con un buen alojamiento, mucho cuidado con la selección de plugins y un tema de calidad y ajustado a nuestras necesidades.

4 comentarios

¡Muy útil la información que comentas, gracias!

Y de hecho estoy bastante de acuerdo con todo lo que planteas. Sin embargo ( y hablo con cierta ignorancia) si estuviéramos hablando de pequeñas funciones, ¿hasta que punto podría interesar lanzar un include en vez de mantenerlo integrado en un archivo? Lo digo porque en estos casos, ¿no sería contraproducente demasiada fragmentación?

¡Gracias!

Escrito por Gonzalo el 04-12-2014 a las 11:00

Hola Gonzalo, en primer lugar, gracias por pararte a escribir y debatir.

Si son pequeñas funciones, el rendimiento que le puedes sacar con los includes es despreciable. En ese caso, si lo hicieras, sería por tener una buena organización de tu código y no por el rendimiento en sí.

Un saludo

Gracias Manuel por tan pronta respuesta. Perdona si te insisto un poco más de la cuenta pero mis conocimientos a estos niveles más profundos me dejan fuera y verdaderamente por curiosidad me gustaría saber si no existe penalización al tener que cargar más archivos de la cuenta. Quiero decir, ¿realmente no sufriría más carga un servidor al tener que leer más archivos? Lo digo, porque me gusta ser bastante ordenado y procuro mantener las funciones separadas pero a veces me “corto” en desglosarlo en exceso por desconocimiento y miedo a que pueda resultar contraproducente fragmentar demasiado el código. ¡Gracias de nuevo por tu tiempo! Un saludo

Escrito por Gonzalo el 04-12-2014 a las 13:00

Gracias a ti por escribir.

Piensa que PHP está preparado para incluir miles de archivos por segundo. Para que te hagas una idea: WordPress, cada vez que se lanza una petición, incluye unos 4000 archivos. Si tu usas 10,20 o 50 no tendrá efecto apreciable. Fíjate, si entras en la siguiente página, verás que hacen el cálculo de cuanto le llevaría a PHP incluir un millón de ficheros. El resultado fue de: 0.27652382850647 sec. Así que fíjate si tú o yo incluimos 20 o 50 archivos. Por otra parte, date cuenta que lo estás usando con actions. Con lo que lo que el tiempo de carga por include lo recupera con “creces” al no tener que parsear PHP todo el código que tengas.

Así que si eres de distribuir archivos, como yo, no tengas reparo y hazlo. Si el proyecto crece ya lo tendrás todo organizado y óptimo.

Un saludo

Muchas gracias Manuel!

Tomo nota y así lo haré a partir de ahora. Te seguiré de cerca ;)

P.D Se echa en falta poder suscribirte a los comentarios para recibir una notificación con la respuesta :P

Escrito por Gonzalo el 05-12-2014 a las 11:54

Gracias, Gonzalo.

En cuanto a tu sugerencia de notificaciones de email, sí, es algo que pensé. Pero la gente es reacia a poner su email en los comentarios. Seguramente lo ponga pero de manera opcional. Gracias por comentarlo.

Hasta pronto, Gonzalo y Felices fiestas.

Muy buen artículo, me apunto algunas cosas :) añadiría que también cuenta la velocidad y los recursos que se dispone en el servidor donde esté alojada la web y es un factor importante a la hora de cargar la web, sobretodo si hay muchas visitas simultaneas.

Un saludo.

Gracias por participar, Alfonso.

En este artículo me quería centrar sólo en WordPress como CMS pero influyen muchas más cosas, como las que comentas. Esas son igual o más importantes que el propio CMS.

Un saludo y felices fiestas

Hola Manuel,

Gracias por el artículo …

Estaré pendiente de tu artículo sobre los plugins que añaden un sistema de caché a WordPress, me interesa el tema …

En proyectos grandes siempre he acabado usando un plugin de caché, en esos casos utilizarlo ha sido más beneficioso que no hacerlo. Por ejemplo, cuando el servidor no es muy potente ha sido una de las formas de proteger el portal ante los picos de visitas. Como bien dices, es mucho el código a procesar en cada visita, y cuando éstas son muchas simultáneas el procesador sufre, la memoria se agotada …

Saludos! Pablo

Escrito por Pablo el 08-12-2014 a las 13:27

Hola Pablo, gracias por pararte a leer el artículo y escribir un comentario.

Sí, tienes razón En proyectos grandes tienes que usar algo para atenuar la carga tremenda que debe de soportar WordPress. En esos casos o usas un plugin de caché( sabiendo que puede traer problemas, por ejemplo a la hora de hacer backups ) o gastas un pastón en hosting ( como están las cosas con la crisis no siempre es posible ).

En fin, te comento que, según mi planificación, esta semana publicaría un post sobre seguridad para WordPress, la siguiente sobre patrones para desarrolladores, la semana siguiente sería sobre Less para maquetadores y ya a la siguiente le tocaría el turno otra vez al rendimiento de WordPress. Así que te tocará esperar al menos un mes y medio para saber como mejorar el rendimiento de WordPress sin plugins externos. Pero, te aseguro, Pablo, que la espera será dulce jejeje.

Gracias nuevamente, Pablo. Un saludo y felices fiestas.

Estupendo Manuel, estaré pendiente de tus artículos … Saludos y Felices Fiestas también para ti!!

Escrito por Pablo el 08-12-2014 a las 22:09

Hola, he intentado poner en las lineas del wp.config la limitacion del numero de revisiones, pero entonces no me deja entrar en la administracion. Me dice que las cookies se ha descativado y no me deja

Si entro en la administracion antes de añadir esa linea, y modifico entonces el wp-config, a la que cambio de pantalla o intento abrir un post o cualquier cosa, se qued atodo en blanco

Alguna idea ?? Muchas gracias

Escrito por carlos el 17-12-2014 a las 09:41

Buenos días, Carlos,

Seguramente sea fallo sintáctico al escribir el código. Lo mejor sería que lo copiaras y pegaras: define( ‘WP_POST_REVISIONS’, 2 );

Si a pesar de eso sigue sin funcionar, puede que sea que algún plugin necesite las revisiones para funcionar. Aunque esto suele ser algo poco habitual( de hecho, no conozco ningún plugin que sea así ).

Habría que tener acceso a la web y al código para saber exactamente porque no funciona.

Un saludo y felices fiestas, Carlos Manuel Canga

Un apunte, Gonzalo, sobre los includes: si haces un include o un require de un mismo fichero desde dos ficheros php distintos, procura que la ruta sea la misma en los dos casos. Todas las instalaciones de PHP — por lo menos las de producción — vienen con caché de bytecode así que si incluyes una vez (o diez, o cien) el mismo fichero, el coste es constante y prácticamente cero (con el apc.stat a “on” aún se chequea si ha cambiado la fecha de la última modificación pero no se va a disco a leer el fichero en cualquier caso)

El tema es que la caché identifica los ficheros por la ruta. Diferentes rutas se tratan como diferentes ficheros AÚN si son dos rutas relativas al mismo físicamente. WordPress tiene esto en cuenta, si te fijas (en el core, al menos)

Escrito por Paco el 04-01-2015 a las 21:03

Gracias por el aporte, Paco. Es muy bueno, no tenía ni idea de que eso pasara así.

Un saludo

Gran aporte. Sencillo pero intenso porque ayuda a comprender los fallos de memoria con multilenguajes, revisiones que ralentizan y el funcionamiento raro con sistemas de cache.

Escrito por Raul el 05-01-2015 a las 20:12

Gracias, Raul, tus palabras motivan para seguir escribiendo. :)

Hola Manuel! Tienes mucha razón en cuanto a la estructura de la BBDD… pero… cómo hacerlo mejor? Cuando haces un proyecto a medida, siempre dudas de cuándo resolver algo con más campos en la tabla o si crear subtablas. Las subtablas al estilo id_info / nombrecampo / valor generan muchas queries con joins consumidoras de recursos… es cierto… pero no se me ocurre solución flexible que no peque de lo mismo…

Respecto a los CPT, sidebars, etc. Lo que es criminal para el rendimiento es instalar algún plugin que lo “configure fácilmente” a costa de tenerlo todo en la tabla wp_options. Ir añadiendo decenas de plugins para detalles concretos, etc. Si tu creas un theme (o plugin) i en su PHP principal declaras menús, CPT, sidebars, widgets a medida, etc la cosa no es tan grave… creo…

WP trae un sistema de transients (tengo en tareas pendientes explorarlos) que podrían estar bien para almacenar los menús, la carga de taxonomías, etc.

Un saludo!

Escrito por Carles Reverter el 01-05-2015 a las 08:15

Hola, Carles!, qué alegría y privilegio tenerte por aquí. No todos los días recibe uno la visita del desarrollador del plugin knews ( https://wordpress.org/plugins/knews/ ). :)

Sobre lo que comentas de los ‘metas': como bien dices, si usas base de datos relacionales no hay otra manera de meter los “metas” como hace WordPress, aunque te animo a que pruebes base de datos no relaciones o noSQL. como MongoDB. Yo es lo que uso ahora para desarrollos a medida y te facilitan el desarrollo enormemente. Eso sí, ten en cuenta que yo no hablo de ese aspecto en el post. De hecho, en el post tampoco hablo de que WordPress sea malo por tener la base de datos como la tiene, todo depende para que lo vayas a usar. Por ejemplo, si tu proyecto es un blog, el esquema de la base de datos está genial tal como está.

Respecto a los CPT y demás, es más de lo mismo: depende la cantidad. Ejemplo claro lo tienes en los temas mastodónticos que te traen de serie tropecientos widgets, shortcodes, sidebars, … eso es código que WordPress tiene que leer y procesar en cada carga de página, es un pasote. En la actualidad, con las mejoras de rendimiento de servidores, discos duros SSD, … se ha reducido el tiempo de procesado, pero aún así es demasiado grande.

Sí, los transients podrías usarlos para cachear, pero es lo mismo que comento para los plugins de caché: terminas quitando flexibilidad a WordPress. Además, tú que tienes mucha más experiencia y conocimientos de WordPress que yo, habrás visto miles de casos que por usar un plugin de caché algo deja de funcionar correctamente. Deja de funcionar porque tiras( o lo hace un plugin o el propio tema) de un filter o un action que ha dejado de funcionar porque el sistema de caché se lo salta a la torera. Aún más, no me extrañaría que tú con knews no hayas pasado sudor y lágrimas con los plugins de caché. Son un dolor de cabeza, ¿ verdad ?.

Gracias por estar aquí, Carles. Hacía tiempo que no tenía noticias tuyas.

Un saludo!

Muy bueno el artículo, si me permites haremos mención en wordpressmagazine.es, esta mañana tuve un problema de lentitud dentro de la administración. Desactivé el plugin WP supercache y listo. Está claro que cuantos más plugins y funcionalidades añadamos a nuestro sitio, más complicado será el mantenimiento. Un saludo y gracias

Escrito por Nicolas el 13-08-2015 a las 16:21

Gracias, Nicolás. Por supuesto que no me importa que me hagáis mención, de hecho, os lo agradezco.

Sobre el problema de lentitud que has tenido, ten en cuenta que en tu caso puede que no haya sido el número de plugins sino el usar un plugin de caché. Te recomiendo leer un post que escribí de porqué no es bueno usar plugins de caché en WordPress. De cualquier manera, me alegro que lo hayas podido solucionar.

Un saludo.

Muy interesante todo. Una pregunta puntual: Se podría decir que es más eficiente programar un blog desde cero que utilizar wordpress? por supuesto que sería muuuucho más complicado hacerlo desde cero, pero me pregunto si valdría más la pena hacerlo desde cero por el tema de la eficiencia y por ende bajar el tiempo de carga, considerando también que voy a usar un servidor compartido.

Escrito por Rafael el 22-10-2015 a las 00:18

Otra cosa, debo suponer entonces que trasweb.net no esta usando ningún CMS

Escrito por Rafael el 22-10-2015 a las 00:23

Hola, Rafael,

A la pregunta sobre desarrollo a medida vs WordPress, la respondo en otro post sobre cuándo escoger hacer desarrollo a medida. Hoy día hacer desarrollo a medida es muy rápido ya que los lenguajes han evolucionado, las base de datos también, las herramientas que utilizamos los programadores son más completas, etc. Hay un mito sobre el desarrollo a medida que no es justo.

Esta web está usando un folk de WordPress llamado RapidoPress. Aunque en nada que tenga tiempo la voy a migrar a mi propio CMS.

Gracias por escribir, Rafael.

Acoj**ante!!!

Enhorabuena por el post...

Veo que ya tiene un par de años...esto sigue funcionando igual?

Escrito por Sergio el 10-12-2016 a las 00:01

Hola, Sergio, perdón por la tardanza en publicarte el comentario y en responder, pero estaba de viaje y acabo de llegar.

Decirte que nada ha cambiado, si acaso ha ido a peor al meterse más código en WordPress. Lo que si ha salido es la WP-API que es un intento de desacoplar frontend de backend y, por tanto, que WordPress tenga menos código que leer. A día de hoy, como no se ha realizado todavía el desacopamiento, como digo, es mucho más código y, por tanto, más lento

Reconociendo que tu artículo es técnicamente impecable, me sorprende el título y la afirmación completamente cerrada sobre elrendimiento de wordpress.

Verás... No soy desarrollador de php/mysql -> wp , (si de otra media docena de lenguajes y bbdd) y, a pesar de llevar décadas en desarrollo, jamás afirmaría que una plataforma abierta como WP es lenta, sobre todo porque corre sobre versiones de php y mysql fluctuantes, el servidor web va sobre diferentes sistemas operativos, y porque se complementa con plugins y themes de desarrolladores externos.

Me temo que es como afirmar que "determinada marca de coches es lenta", sin concretar el modelo, año, neumáticos, versión de motor, combustible, etc... es una afirmación, por decirlo abiertamente, 'rara'.

Para colmo hace ya tiempo que los caches del servidor resuelven, en el 90% de los casos, páginas estáticas, por lo que un desarrollo medianamente optimizado en wordpress debería tener la misma velocidad que cualquier otra url del mismo tamaño y complejidad (carga de html, css, js, etc...)

Así que, respeto tus más que comprobados conocimientos técnicos, pero no hay motivos para hablar de este CMS en concreto sobre velocidades más que sobre cualquier otro.

Me tomo la libertad de ser irónico y recomendar al que busca velocidad, ya que tu propones "contener" el uso de imágenes y demás dietas extremas, así como tus opiniones sobre mysql y las bbdd relacionales, que existen cms realizados integramente en javascript en el servidor, así como bbdd sobre corriendo en ficheros planos...

Es sólo una opinión, así que si quieres prolongar más esta afirmación, lo suyo sería que instalaras en el mismo hosting la misma web desarrollada con la misma plantilla y los mismos plugins y contenidos (sin ningún tipo de caché en servidor y cliente), y que realizaras las mediciones oportunas, porque en cualquier otro caso hablamos del sexo de los ángeles.

Escrito por Fmorenop el 15-12-2016 a las 08:39

Hola, me gusta tu comentario pero creo que lo estás partiendo de una base incorrecta. Te doy mi punto de vista, primero con un ejemplo y después con algo de más solida teoría.

Ejemplo: ¿ Una tortuga es rápida o lenta ? ¿ Y si la subimos a un caballo ?. ¿ Es ella la rápida o lo es el caballo ?. ¿ Y si la comparamos con la velocidad de un avión ?. ¿ Sería rápido o lento ?.

Como no hay forma absoluta de determinarlo, podríamos estudiar una tortuga por si sola y ver como de preparada está para la velocidad. El resultado sería que dada sus pequeñas patas y el peso de su caparazón, irremediablemente es un animal lento. Aunque a veces, bajo ciertas circunstancias( como ir en caballo o en avión ) la pueda hacer rápida.

Teoría:

Aunque ya escribí sobre es el fallo típico al medir la velocidad de una web , en tu caso, ya que eres del gremio, te daré mi punto de vista de manera técnica.

Cuando estudias algoritmia en una carrera( en mi caso, fue de las asignaturas que nunca pude presentarme al examen :( ), se estudia con ella la Teoría de la complejidad computacional que se basa( al menos yo lo di así ) en medir la eficiencia de un algoritmo, para así poder separar la eficiencia que es propia del algoritmo, de la eficiencia con la que se comporta dependiendo de las circunstancias o equipos en los que se ejecuta. Para ello, se descarta cualquier aspecto externo al algoritmo( máquinas sobretodos ) y se centran en su código( pasos ) y en el número de muestras.

En base a esos principios, comentados antes, en la asignatura se analizan los distintos algoritmo de ordenación y se estudian su complejidad( o eficiencia en relación al número de muestras ). Así, por ejemplo, se determina que un algoritmo de burbuja es lento, aunque se esté ejecutando en una máquina potente que haga que su comportamiento sea rápido.

WordPress es un CMS lento por diseño, aunque pueda comportarse rápido en equipos potentes. Porque, incluso en estos casos, si el visitante tiene una mala conectividad( porque puede ser que se esté conectando con el móvil, en un area de poca cobertura de datos ), se comportará lento.

Espero haberme explicado tan de mañana

Hola de nuevo. Me ha resultado dificil seguirte en la explicación acerca del sexo de los ángeles cuando has empezado a mencionar a Aristóteles.... no se si expreso mi perplejidad por tu respuesta.

¿Una tortuga es rápida o lenta?.... Una tortuja es una unidad, una máquina, y le afectarán factores como el cansancio, edad, fuerza del viento y pendiente... y si te pones filosófico, una tortuga parada se mueve a la velocidad de rotación de la tierra, pero no me interesan las elucubraciones mentales.

Wordpress es una pieza: No funciona porque si de manera autónoma, es un programa realizado sobre un lenguaje y una base de datos, así que si te limitas a decir que 'wordpress es lento', faltan bastantes explicaciones acerca del contexto como ¿comparado con qué otro cms?, ¿es lento en cuanto a que está mal optimizado?, ¿es lento de manejar en el escritorio o es que el código php de wordpress se ejecuta más lento que ele de joomla?...

No se, pero fíjate bien que lo que te explicaba en mi comentario es que 'Wordpress es un cms lento' es una afirmación bastante difusa salvo que, como te solicitaba, aportases una comparativa para saber a que te estás refiriendo porque, de otra manera, tu título se podría llamar Joomla es un CMS lento, Prestashop es un CMS bonito, Drupal es un CMS metafísico, Apache es un servidor web descafeinado, windows es un sistema operativo seguro, Nokia es un smartphone moderno, etc...

¿la teoría de la complejidad computacional?.... ¿en referencia a un programa php?... ¿en serio?

Me dejas "to loco" Yo he trabajado con

Escrito por Fmorenop el 15-12-2016 a las 12:40

Parece que se ha cortado el comentario, no sé si es un fallo técnico o que se mandó el formulario involuntariamente.

No te convencen mis razones técnicas para argumentar que WordPress es lento. No te convence tampoco que al estudiar en la carrera de informática te dicen que no te bases en máquinas para determinar si tu programa es eficiente o no. A pesar de todo ello, no me das ninguna razón objetiva para determinar que WordPress es rápido.

¿ Que en un supercomputador y en una red local tardaría 0.1 segundos en cargarse ?, vale. También tardaría 20 segundos en 286 y modem 56k. Por tanto, este modo de medir velocidad no es objetivo. ¿ A parte de esto tiene ARGUMENTOS TÉCNICOS que den peso a tus argumentos ?. Porque si nos basamos en impresiones, cada cual, como los culos, tiene el suyo.

No sé en qué habrás trabajado porque ha salido cortado, pero yo te puedo decir que me he metido en las entrañas de WordPress y he visto como está hecho y adaptado para que ser fuera más rápido( Enlace al código del fork ).

Ya he tenido la misma conversación que estoy teniendo contigo, con otros fanboys de WordPress, y ninguno me da razones técnicas. Lo único que me dan son impresiones. Desde ahí, poco debate puede haber

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.