Recientemente escribí sobre la migración que realice de W3 Total Cache a WP Super Cache. En el cual explique algunos problemas que tuve con W3 Total Cache.

Sin embargo, la solución de WP Super Cache + Autoptimize no me tenia del todo contento. Las cosas se podían mejorar. En especial, el rendimiento de ambos plugins. Ya que no era de mi completo agrado.

Es ahí que escuche de Swift Performance Lite y decidí probarlo.

Instalando y probando Swift Performance

Tras instalar Swift Performance Lite, una de las cosas que debemos de hacer primero es el ejecutar su Wizard de instalación.

La gran ventaja es que prácticamente todo esta automatizado. El plugin detecta correctamente muchas de las opciones del entorno. Además de que mostrará cualquier problema que tenga el servidor.

Con lo cual sabemos que debemos cambiar o instalar para mejorar el desempeño en general.

En el Wizard de Instalación podemos incluso elegir muchas de las opciones más importantes. Como la forma en la cual controlaremos cuando se expira el cache. O si queremos incluso purgar el cache de Cloudflare, si usamos esa solución.

Además incluye un minificador de código Javascript y CSS. Que si bien ya no es tan extremadamente necesario, siempre es bueno tener esas opciones.

Con la configuración detectada por Swift Performance Lite, se tiene una base sólida sobre la cual trabajar.

Dependiendo de las condiciones de tu servidor, el desempeño se puede sentir incluso mejor que con W3 Total Cache o WP Super Cache.

Personalmente, he encontrado que el desempeño puede ser mejor que con los plugins antes mencionados.

Afinando Swift Performance Lite

Sin embargo, en algunos casos, se necesita de realizar algunos cambios a la configuración. En especial si usamos software adicional o si observamos comportamientos erráticos.

En mi caso, me gusta combinar Javascript y CSS externo. Con lo cual están disponibles aunque el medio original tenga problemas.

Para activarlo, debemos de ir a Settings » Optimization » Scripts y asegurarnos de la opción de Exclude 3rd Party Scripts este desactivada.

Ahí mismo, debemos de indicarle a Swift Performance que recursos queremos omitir a la hora de combinar scripts. En mi caso, declaro los siguientes:

Como se puede ver, es relativamente sencillo el decirle que recursos no se han de combinar. Esto es realmente útil si encontramos problemas o si el cache crece demasiado rápido.

Otra de las opciones que ofrece Swift Performance es la posibilidad de usar el Lazyload de imágenes. Esta característica se encuentra bajo Settings » Media » Images.

Ahí podemos decidir si queremos usar esta opción y que condiciones causarán que se cargue la imagen completa.

Páginas 404, Archivos y Autores: ¿Agregarlas al Cache?

Otra de las opciones que permite Swift Performance Lite es la posibilidad de almacenar en el cache las páginas de error HTTP 404 (no encontrado), las páginas de los archivos o de los perfiles.

Si bien el guardar en cache estás páginas suena tentador, es algo que se debe de analizar profundamente.

Personalmente decidí no permitir que se agreguen estas páginas al cache, ya que pueden interferir con las re-direcciones o registros de apache.

Sin embargo, puedes encontrar esta opción en Settings » Caching » General.

Igualmente Swift Performance nos permite decidir si queremos guardar en el cache ciertas páginas como son end-points del REST API, Feeds, etc.

En Settings » Caching » Exceptions encontrarás estas opciones.

Si consideras que te será útil, puedes desactivar los casilleros. Pero personalmente he encontrado que pueden generar que el tamaño del cache crezca mucho.

Dependerá de cada caso si se ha de activar o no.

Otras opciones de Swift Performance Lite

Además de encargarse del cache, Swift Performance también nos permite realizar otras tareas. Como lo es el realizar un mantenimiento a nuestra Base de Datos de WordPress.

Si bien el tipo de herramientas que ofrece son básicas, como es Reindexar u Optimizar la Base de Datos, Eliminar Transients, Revisiones, Comentarios o Usuarios; estas son generalmente las que más se usarán para obtener una pequeña mejora en el desempeño. Especialmente notorio si la Base de Datos es grande.

Una opción, relacionada al mantenimiento, que es realmente bienvenida y que nos ahorra el tener que depender de otra herramienta adicional.

Finalmente, otra de las opciones adicionales en Swift Performante Lite, es la del Plugin Organizer.

Con esta, nosotros podemos indicar en que circunstancias se deben de desactivar ciertos plugins. Ya sea si se visita una página en especifico, si el usuario actual tiene un determinado nivel, si se está ejecutando en contexto AJAX, etc.

Esta opción, si es configurada correctamente, puede ayudar a mejorar el rendimiento del sitio web en ciertos escenarios. En especial es útil si se quieren optimizar los recursos en un entorno limitado o con alta demanda.

Problemas con Swift Performance Lite

Por desgracia, no todo es miel sobre hojuelas. Algo que en verdad ha de esperarse cuando se prueba un plugin nuevo.

Sin embargo estos problemas pueden ser solucionados relativamente fácil, ya que solo hace falta aplicar pequeños parches de código. He visto buen potencial en este plugin que he decidido seguir adelante con este a pesar de esos pequeños detalles.

Esto son algunos de los problemas que he encontrado y como puedes solucionarlos:

1. Swift Performance guarda en cache páginas de error

Si tienes soluciones de seguridad para WordPress como Wordfence, es muy posible que en algunos escenarios te encuentres con problemas si usas Swift Performance Lite.

Además de Wordfence, yo también cuento con soluciones de seguridad adicionales creadas a medida.

En ambos casos, observe que los errores 503 de Wordfence y los 403 de mi solución eran guardados en el cache de Swift Performance Lite.

Peor aún, las páginas de error generadas y guardadas en el cache le eran mostradas a los visitantes como si fuera la correcta.

En casos como este, normalmente buscarías los códigos de error en el Log de Apache. Pero estos no aparecian por ningún lado. Resulto que estaban en el registro con códigos HTTP 200.

Eventualmente encontré el origen del problema en Swift Performance y tras revisar su código también la forma de solucionar ese tipo de problemas:

En este ejemplo, usamos el filtro swift_performance_is_cacheable junto con la función http_response_code para obtener el estado actual de la petición y saber si se debe de permitir que se almacene en el cache.

En este caso, use una lista predeterminada de códigos de error típicos, pero se puede comparar solamente contra el código HTTP 200:

Sin embargo, en este caso en especifico, se requerirá realizar pruebas para saber si genera los resultados deseados.

2. Swift Performance agrega páginas inesperadas al warmup

Otro mal hábito de Swift Performance Lite es el hecho de que agrega a su tabla de warmup recursos como el robots.txt e incluso end-points del REST API, sitemaps, entre otros.

Además, cuando algún bot intenta acceder a un recurso vulnerable, también se agrega esa página a la tabla de warmup de Swift. Esto si se regresó un error diferente al de no encontrado.

Si queremos evitar que Swift haga esto, podemos definir que clase de urls se deben de excluir desde el back-end de WordPress.

Pero también lo podemos hacer usando un poco de código:

En este caso, se usó de nueva cuenta el filtro swift_performance_is_cacheable para filtrar si Swift Performance deberá de guardar la página en el cache.

Entonces se compara la variable $_SERVER['REQUEST_URI'] contra un array pre-definido.

La ventaja de este método es que la lista no puede ser modificada desde el plugin, con lo cual prevenimos que la lista sea eliminada si se restauran los valores por defecto de Swift Performance.

Otra alternativa a esta solución es el usar la propiedad $wp->request que ofrece WordPress. Sin embargo, esto solo funcionará en el front-end.

Una limitación que puede ser problemática, en especial si queremos filtrar resultados que incluyan páginas del back-end.

Finalmente, también puedes obtener el valor original usando  filter_input(INPUT_SERVER, 'REQUEST_URI'). En especial si sospechas que otro plugin manipula esta variable global.

3. No se eliminan algunos de los archivos del Cache de Swift Performance Lite

Otro de los problemas de Swift Performance, e incluso de W3 Total Cache, es que una vez que ha expirado un elemento del cache, este no siempre se elimina.

Estos archivos pueden permanecer guardados ahí por tiempo indefinido.

Si tenemos muchos visitantes o múltiples páginas, esto puede hacer que el cache crezca muy rápido a un tamaño excesivo.

En este caso, el cache llego a ser de casi 2GB. Lo cual claramente muestra un problema por que solo se tienen 79 páginas en la tabla de warmup.

¿De donde ha salido todo los demás?

Una solución rápida es simplemente limpiar el cache manualmente a intervalos regulares. Pero puede ser tedioso después de un tiempo o si se tienen múltiples sitios web que administrar.

Una solución más práctica es el definir un Cron Job de WordPress y que este haga el trabajo por nosotros:

En este caso, se están usando las propias clases de Swift Performance para saber el tamaño actual del cache, calcular cual debería de ser su tamaño y eventualmente limpiarlo si es necesario.

Adicionalmente, también se puede limpiar el cache una vez al día. En ese caso, se define un cron job el cual solamente haría lo siguiente:

Hay que tener en mente que, debido a que es un trabajo cron de WordPress, es posible que no siempre se ejecute. Esto en especial en sitios web con poco tráfico.

Para esos casos, es posible el crear un script especial y agregarlo a los trabajos cron del servidor. Pero ello está un poco más allá del alcance de esta entrada.

4. Multiples Hosts en el cache de Swift Performance Lite

Cuando se cuenta con una instalación de multisitios, es de esperarse que un plugin como Swift genere una carpeta por cada dominio que sirve contenido desde una instalación en especifico de WordPress.

Sin embargo, a veces esto también sucede con las instalaciones regulares, bajo ciertas condiciones.

Por ejemplo, si cuentas con una instalación de WordPress en un VPS y Apache ha definido a ese servidor virtual como el principal… entonces es posible que te encuentres con una sorpresa.

Swift Performance crea una carpeta en su directorio de cache por cada dominio que accede a la instalación en donde esta presente. Pero cada una de esas carpetas solo se puede acceder desde el dominio que la creo.

Así, si cuentas con una instalación que se puede acceder desde www.ejemplo.com, ejemplo.com y una IP como 123.456.789.012, entonces terminarás con 3 carpetas.

Pero para limpiar el cache generado para 123.456.789.012, deberás de ingresar directamente en esa dirección. No puedes limpiar ese cache desde www.ejemplo.com. Pero tampoco la de ejemplo.com.

Sin embargo, puedes mostrarle a Swift cuales son los hosts y carpetas que puede ver haciendo uso del filtro swift_performance_enabled_hosts:

En este caso, nosotros obtuvimos todas las carpetas en root del cache de Swift Performance y los regresamos como si fueran nombres de dominio.

De esta forma, el cache generado para otros dominios se puede ver, administrar y purgar desde el back-end.

Hay que tener en cuenta, por supuesto, que en el caso de las instalaciones multisitio; esta solución puede generar problemas. Por lo cual pudiera necesitar validaciones adicionales.

5. Problemas cuando se corre WP-CLI con Swift Performance

Una de las herramientas más importantes para administrar WordPress, desde la línea de comandos, es la de WP-CLI.

Con ella podemos hacer una infinidad de tareas para administrar las instalaciones  el software. Sin embargo, Swift Performance parece emitir ciertas advertencias cuando es ejecutado en este tipo de entorno.

Por ejemplo, emite un error cuando intenta usar el indice HTTP_HOST. El cual no se define en contexto de línea de comandos.

Por lo cual, para evitar algunos problemas, o que la salida de la consola pierda formato; siempre es bueno desactivarlo con el siguiente parámetro:

wp plugin list --skip-plugins=swift-performance-lite

Solo con el agregar la opción --skip-plugins, se puede corregir el pequeño problema. Ya que si no se ejecuta Swift Performance Lite en el entorno CLI, entonces este no tratará de optimizar esas salidas.

Conclusiones sobre Swift Performance Lite

Si bien, como cualquier plugin nuevo, todavía tiene mucho que mejorar; Swift Performance me ha dejado sorprendido en muchas áreas.

Por ejemplo, este es uno de los resultados que he obtenido usando este plugin como solución de cache:

Para nada despreciable. Incluso ya por debajo de un segundo de carga. Algo que invariablemente buscaba lograr, pero me era algo elusivo con otras soluciones.

Claro, siempre ayuda mucho el contar con un servidor optimizado.

Vale la pena el tomarse el tiempo probar este plugin, el cual ofrece buenos beneficios por default. Aunque obtienes mucho más de este una vez sabes donde tienes que apuntalar.

¿Ustedes que opinan al respecto?

The post Swift Performance Lite: Acelera tu Sitio Web appeared first on Endless Manifesto.

Estas son mis razones.

Anteriormente había hablado de W3 Total Cache. De como me estaba ayudando mucho mejorando el sitio web.

Debo de admitir que este plugin era prácticamente mi favorito para realizar la tarea de caching. Algo importante si realmente quieres tener un sitio web rápido, además de que me ahorraba tiempo de procesador.

Sin embargo, recientemente comencé a notar problemas. Mismos que me hicieron mirar a WP Super Cache de nueva cuenta.

Errores en todas partes con W3 Total Cache

Una de las cosas que más me agradaban de este plugin de WordPress, es que podía configurarse de acuerdo a mis necesidades. El gran número de opciones abría grandes posibilidades de optimizaciones. De mejoras puntuales de acuerdo a mis necesidades.

Sin embargo, siempre hay cosas que salen mal. Y eso es en verdad cierto con software complejo.

El primer síntoma estuvo en las entradas programadas. Comencé a notar que estas arrojaban el error missed schedule con frecuencia. Molesto, pero nada más que eso… e incluso errores esporádicos que parecían no tener sentido.

Todas las soluciones en la web indicaban que debía de instalar algún plugin.

No. No lo iba a hacer. No tenia sentido que algo así sucediera, ya que el servidor no tenia razón de estar comportándose de forma errática.

Tras investigar un poco, resultó que el Object Cache estaba causando problemas en mi back-end. Tras desactivar esa característica, los problemas cesaron… al menos temporalmente.

Las cosas se complican todavía más

El segundo gran problema sucedió con admin-ajax.php. Comencé a notar un número inusual de errores 403 sin una explicación clara.

Me arrojaba el error a mi, a visitantes al azar, e incluso a los bots de google. Esto último imperdonable.

Debido a que las instalaciones que manejo contienen más o menos los mismos plugins… detectar al culpable seria relativamente sencillo. Tras un análisis, solo se limitaba a W3 Total Cache o a uno de seguridad.

Para agravar más la situación, el problema de missed schedule había regresado.

Fue entonces que la opción de WP Super Cache se volvió mucho más viable.

Ya tenia experiencia con él y sabia que podía hacer el trabajo sin contratiempos.

WP Super Cache entra al relevo

A diferencia de W3 Total Cache, WP Super Cache tiene opciones muy minimalistas. No eres capaz de configurar absolutamente todo. Aunque no falla en su trabajo: Mejora el rendimiento del sitio web. Sin complicaciones.

Pero para tener una solución completa con WP Super Cache, se requiere de un aplicativo que haga minificación. Ahí es en donde entra Autoptimize. Esto para comprimir las hojas de estilo y los scripts de javascript.

Esto lo debemos de hacer si queremos mejorar aún más el rendimiento y experiencia del usuario.

Aunque si contamos con un servidor rápido, la ganancia puede ser marginal. Pero menos consultas por visita siempre es bueno. En especial si sumamos muchas visitas al día.

El modo experto de WP Super Cache

Si bien cuenta con muchas menos opciones, hay algunas cosas que si se pueden hacer. En especial en lo que respecta a activar el uso de reglas en el .htaccess. Esto permite que se pueda saltar parcialmente la ejecución de PHP en algunos casos.

Mientras menos veces se tenga que invocar a PHP, mejor.

Activando el modo experto, y asegurándose de activar los casilleros deseados, da un rendimiento que hace que no extrañe W3 Total Cache. Aunque lo único que no hace WP Super Cache es el asignar las cabeceras cache de Apache para los recursos estáticos.

Pero agregar ese tipo de cosas es trivial. Igualmente se puede agregar rápidamente las reglas que trae W3 Por defecto, dependiendo de las configuraciones.

Conclusiones sobre el regreso a WP Super Cache

Si bien soy fanático de tener una herramienta con cientos de opciones, es una pena que encontré que ella causaba más problemas que beneficios. Problemas que no parecían tener soluciones fáciles, o que hacían que no valiera la pena la solución.

Por lo cual el contar con una alternativa más sencilla fue la mejor idea.

Hay algunas cosas que todavía tengo que apuntalar, en especial del lado del servidor. Como son las cabeceras… aunque Cloudflare se encarga por mi de eso.

Pero establecerlas manualmente siempre será mejor para proporcionar una experiencia más uniforme.

Esperemos que no suceda nada inusual esta vez.

The post Adiós W3 Total Cache, Hola WP Super Cache appeared first on Endless Manifesto.

Además, ofrece un importante número de opciones que se pueden configurar. Dependiendo de tus necesidades u objetivos. En mi caso, era el obtener un mejor rendimiento absoluto en varios frentes. Después de que los resultados en el PageSpeed Insights habían salido terriblemente mal.

Bueno, exagero un poco en ello. Pero al estar en un hospedaje compartido, es natural que ciertas cosas no corran de lo mejor. Yo espero poder migrar a un mejor ambiente en un momento cercano. Pero en lo que sucede, hay que trabajar con lo que se tiene.

Y un plugin de caché era la opción más natural para lograr los objetivos inmediatos.

¿Por que usar un plugin como W3 Total Cache?

La razón más sencilla es por que ya hay buenas alternativas que ya están correctamente escritas. De lo contrario, tendrías que reinventar la rueda. Dichos plugins ya toman en cuenta los problemas más comunes y los solucionan rápidamente.

Igualmente han tratado de seguir los lineamientos de Google, y otras plataformas similares, para realizar las mejoras. Esto buscando que los webmasters no tengan que estar instalando otras herramientas.

Por supuesto, esto no implica que sea la solución a todos los problemas. Hay casos en los cuales requerirás escribir tus propias soluciones, pero ese es un tema para otro día.

En mi caso, esta era la forma más viable de hacer las cosas.

Preámbulo a la optimización

Ten en cuenta que estas configuraciones funcionan en mi entorno de trabajo (Apache, PHP7, MariaDB). No necesariamente funcionaran en el tuyo. Hay muchas variables que están en juego, por lo cual al final lo que te funcione a ti pudiera ser diferente.

Ante de empezar, coloque el siguiente código en el footer de mi instalación. Con este, podría ver que tan mal estaba.

View the code on Gist.

Ya con ese código, pude ver resultados similares a este:

View the code on Gist.

Ouch, ¿De donde salían tantas consultas? ¿Como era posible que se consumiera tanto tiempo? Esos números indicaban que había un problema el cual tenia que ser solucionado.

Por supuesto, el primer lugar en donde tenia que mirar es en mi servidor e instalación. Eliminar los plugins innecesarios es algo que se tiene que hacer. Posterior, tuve que cambiar de PHP5 a PHP7. Esto debido a que PHP7 es mucho más rápido que PHP5, además de más seguro.

Por fortuna para mí, esto no generó problemas de compatibilidad. Pero es posible que tengas problemas si antes contabas con mensajes de «funciones obsoletas», ya que muchas de ellas fueron eventualmente eliminadas. Puedes solucionar ese tipo de problemas si no te importa ensuciarte un poco las manos con el código fuente.

Una vez limpiada mi instalación, ganando como 0.2 ms, solo quedaba optimizar lo que quedaba. Los plugins que quedaron eran los que consideré que eran de utilidad y necesarios.

Configuración de W3 Total Cache

Trataré de ser breve, ya que el compartir una configuración completa de W3 Total Cache puede ser extensivo. Aunque es bueno el tener una idea de todo lo que puedes lograr con dicho plugin. Aún para la versión gratuita.

Pero si haré incapie en aquellas características en las cuales logre observar una mejora.

Si vas a usar W3 Total Cache en una instalación multisite, lo primero que te recomiendo es activar el mismo para toda la red. Una vez que hayas configurado las opciones más comunes, como el Page Cache, Object Cache y Browser Cache; deberás encontrar la siguiente opción bajo Performance > General Settings y desmarcarla:

Esta es la opción que debe estar o mantenerse desmarcada

Una vez hecho hayas desmarcado «Use single network configuration file for all sites», podrás efectuar cambios «a medida» para cada sitio de tu red. Para ello, deberás de ir a «General Settings» dentro del Escritorio de cada sitio y buscar a la derecha el botón «Use Specific settings». Deberás de hacer clic sobre el mismo para poder editar las características a medida para ese segmento en cada sitio.

Por ejemplo, en mi caso, mi mayor problema fue con las opciones de Minify. Si bien estoy detrás de CloudFlare, el hacer uso de Minify era importante ya que las hojas de estilo CSS y JavaScript no se estaban combinando. Hacerlo eventualmente iba a ayudar mucho.

Pero aquí no había una solución que funcionase en todos los escenarios.

Peleándose con Minify en W3 Total Cache

La posibilidad de «minificar» las hojas de estilo CSS y JavaScript es algo muy importante. Pero, el problema de dicha utilidad es que muchas cosas pueden salir terriblemente mal.

Por ejemplo, compactar el HTML me es útil en este sitio web, pero no en otro. Esto debido a que puede romper el tema y sus características.

Algunas de las opciones activadas para minificar HTML

En el caso de Javascript, «defer» para compactar destruye las páginas hechas en Page Origin, mientras que la opción «async» destruye a Slider Revolution. ¿Que lio verdad? Dejarlos a todos con su gusto con una sola configuración es imposible. La tarea de optimizar se vuelve una de «prueba y error» en el mejor de los casos.

Las opciones de JavaScript pueden causar algunos problemas

En el caso de las hojas de estilo, el problema no es tan prominente. En la mayoría de los casos… las cosas simplemente funcionaron bien y se pudo optimizar sin mayor problema.

El único inconveniente de tener este tipo de configuraciones, es que deberás de «limpiar el cache» siempre que haya cambios. Eso puede ser un poco molesto cuando estás haciendo muchos cambios pequeños, pero se soluciona desactivando la opción de compactar o desactivando este plugin.

Activando Object Cache

Esta alternativa en W3 Total Cache es quizá la que mejor me ha resultado, después de la minificación.

Con los cambios antes mencionados y esta, logre tener entonces un tiempo re respuesta similar a este:

View the code on Gist.

Pasar de 101 consultas a 24 es muy bueno. Es decir que ahora se están realizando solo un cuarto de las consultas que se hacían antes. Eso le quite estrés al servidor de base de datos y se accede más rápido.

Para entenderlo mejor, el Object Cache almacena en disco las «consultas más comunes». Algo similar a lo que hace «Page Cache». Esto permite que ciertos valores sean accedidos de una forma mucho más rápida y ágil.

Mientras menos consultas sean realizadas, mejor. Eso siempre ayudará a que el sitio web sea más eficiente a la hora de tener mayor carga. Pero ten en cuenta que, al almacenar el cache en disco, es posible que esto genere muchos archivos adicionales. Eso hay que tenerlo en cuenta en especial si tienes el espacio o los inodes limitados.

Conclusión

Si la configuración de W3 Total Cache se hace bien, se pueden tener buenos resultados. En mi caso, pase de tener una respuesta promedio de +2 segundos a ~0.6 mili-segundos. Una mejora sustancial tomando en cuenta que todavía estoy algo limitado en este entorno.

También en este caso, es importante indicar que solo apuntale una parte del problema. El otro es del lado del servidor. Si se tiene acceso a un procesador más poderoso en el hosting, el tiempo de respuesta podrá verse mejorado.

Algunos incluso dirían que tener un VPS es casi una necesidad. Pero yo opino que todo depende de las propias necesidades y objetivos de cada persona. Un VPS es bueno para quien tiene el tiempo y recursos para administrar un servidor. Esa es una bestia completamente diferente. Y más si ponemos en la mezcla un servidor Varnish.

Encontrar el hosting adecuado resuelve una parte del problema. Con suficientes recursos se puede rentar un buen servidor, pero sin alguien que sepa como optimizar los programas que corren… pues, serán recursos desperdiciados.

Hay que tener un buen balance entre ambos, pero por ahora W3 Total Cache me ha sacado del apuro.

The post Mejorar WordPress con W3 Total Cache appeared first on Endless Manifesto.