> Alta velocidad: realmente acelere los sitios web de WordPress [#5]

Esta pequeña serie trata sobre las cosas que realmente aceleran los sitios web de WordPress, moviéndolos al área de milisegundos de velocidad de carga. Se requiere mucho trabajo manual, como descubrimos en el último artículo. En esta parte, haremos los retoques que aún quedan. Ajustaremos las URL, pondremos a Jetpack a dieta, transformaremos el sitio web en páginas HTML estáticas a través del almacenamiento en caché y haremos que los videos se carguen al final.

Rendimiento: la estructura de enlaces permanentes adecuada

Los enlaces permanentes en WordPress se pueden cambiar a voluntad. WordPress nos permite crear cualquier estructura que se nos ocurra. La estructura natural de los enlaces permanentes de WordPress se denomina URL desordenadas, ya que no se puede reconocer una estructura clara. Un enlace justo después de una nueva instalación se vería así:

https://www.noupe.com/?p=123

Esta estructura no es realmente legible por humanos y máquinas y, por lo tanto, las personas comenzaron a usar enlaces permanentes legibles con palabras clave.

https://www.noupe.com/example-post/

Con WordPress, la creación de estos enlaces se puede hacer muy rápidamente y, por el momento, esta estructura sigue siendo la más popular. Sin embargo, son posibles muchos otros arreglos, como una fecha, la categoría o las etiquetas, por ejemplo. Sin embargo, esto no es inteligente, ya que los enlaces permanentes pueden agotar los recursos de su servidor de forma masiva. ¿Quién hubiera esperado eso? En general, se puede decir que los enlaces permanentes fuertemente alterados son malos para el rendimiento. Por supuesto, esto no aumenta el tiempo de carga en segundos, pero junto con otros comedores de rendimiento, es medible. Las direcciones de enlace con ID simples son significativamente más rápidas cuando hay muchas entradas en un blog o en ciertos momentos en los que el tráfico de visitantes es muy alto.

Google casi no presta atención a las URL «hablantes»

Los tiempos han cambiado, y al propio Google ya no parece importarle las URL parlantes. Es todo lo contrario, ya que el propio Google ha comenzado a utilizar ID simples en sus URL, en lugar de palabras clave. Esto se puede ver en YouTube y Google+, por ejemplo. Google pasa a prestar atención a la facilidad de uso, los tiempos de carga rápidos y el buen contenido. Los viejos trucos con la dirección parlante, optimizada con palabras clave, ya no funcionan. Por lo tanto, tiene sentido considerar el uso de URL cortas y rápidas, y también cambiar la estructura de los proyectos existentes.

Cambio de enlaces permanentes a ID simples

Recientemente, Google parece valorar las URL cortas más que otras. Esta es una observación personal mía desde que cambié mi estructura de enlaces permanentes de hablar a identificaciones simples en mi Publicación Democrática. Desde entonces, he estado recibiendo más tráfico a través de Google. Por lo tanto, recomiendo usar una estructura simple de enlaces permanentes con ID. Cambiar la estructura de los proyectos existentes tampoco es un problema, ya que WordPress se encarga de las redirecciones necesarias de la URL antigua a la nueva. Un ID de enlace se vería así:

http://andreas-hecht.com/466/

La siguiente captura de pantalla muestra la configuración adecuada:

Hacer que los videos se carguen al final

Hacer que los videos se carguen al final no hace que el sitio web sea significativamente más rápido con respecto al tiempo de carga puro. Pero el sitio web se construye significativamente más rápido. Al menos, el visitante tendrá la impresión de que su blog se carga rápidamente, ya que el área visible del sitio se muestra mucho más rápido. Para lograr eso, la carga del video simplemente se mueve al final. Cuando un video se integra directamente en el área visible, se mostrará un marco blanco durante un período breve, en el que se mostrará el video después de que se haya cargado por completo. Ahora, la carga del sitio web ya no se ve interrumpida por videos. El código es muy mínimo y consta de dos partes:

Los fragmentos de código para las funciones de su tema.php:

Parte 1: La Función PHP

Un clic abre Gist en GitHub

Parte 2: El código JavaScript

Un clic abre Gist en GitHub

La segunda parte del código solo se carga en la página del artículo. Aquellos que usan videos en las páginas o en la página de inicio también deben ajustar el fragmento a sus necesidades.

Almacenamiento en caché: cambio de un blog a páginas HTML estáticas

Incluso un almacenamiento en caché regular acelera bastante su sitio web. Sin embargo, el intérprete de PHP todavía se llama con cada visita a la página. Si desea un sitio web realmente rápido, debe cambiar el almacenamiento en caché de su sitio web a la creación de sitios web estáticos. Luego, se evita el intérprete de PHP y se llama inmediatamente a la página solicitada. Esto realmente marca la diferencia, pero tiene sus desventajas.

Ventaja:

Cada página se carga mucho más rápido; el sitio web se vuelve muy rápido.

Desventajas:

Ya no son posibles los artículos programados, ya que se evita el intérprete de PHP.

Solución:

Una alternativa decente sería abrir el archivo de WordPress wp-cron.php (ubicado en el índice principal de la entidad de WordPress), utilizando un cronjob del servidor (pregunte a hoster) o un proveedor de servicios como cronjob.de. -Cachify Wiki

Creación de páginas HTML estáticas con el complemento Cachify

El complemento gratuito de WordPress Cachify es el complemento de almacenamiento en caché más rápido para los sitios web de WordPress si se configura correctamente. Junto con una extensión .htaccess, crea una versión HTML comprimida con GZIP de cada una de las páginas de un blog.

Descarga de Cachify en WordPress.org

El archivo .htaccess se puede encontrar en el índice principal de WordPress. La extensión requerida para Cachify debe copiarse arriba de las reglas de WordPress. por favor haz un respaldo antes de editar el archivo.

Un clic abre Gist en GitHub

La configuración requerida del complemento Cachify

Una dieta para Jetpack

Jetpack es un excelente complemento, siempre que tenga cuidado con lo que activa. Uso el complemento de manera muy consciente y solo tengo algunos módulos habilitados. En mi Publicación Democrática, los siguientes módulos están activos:

Incorporaciones de código corto – para Youtube, Flickr y otros servicios
Estadísticas del sitio web – para una visión general rápida de los artículos más vistos en el tablero
Widgets de barra lateral adicionales – para la visualización de los artículos más populares (Top Post Widget)
Copias de seguridad – para las copias de seguridad de VaultPress

La mala reputación de Jetpack como devorador de rendimiento proviene del hecho de que el complemento carga una hoja de estilo o un JavaScript o ambos para cada una de sus posibles funciones. Desafortunadamente, no es posible decidir qué secuencias de comandos y estilos desea cargar y cuáles no, ya que es posible que ni siquiera los use. Por lo tanto, debe decidir manualmente lo que es necesario. Para mí, el complemento carga exactamente un JavaScript y no un solo archivo CSS. He copiado el CSS que es necesario para el widget de publicación superior del archivo CSS de Jetpack y lo he implementado en mi style.css. Posteriormente, se impidió que se cargara el Jetpack CSS.

Parte 1 de la optimización de Jetpack: control sobre los módulos

Los módulos Jetpack se pueden controlar fácilmente con el complemento y también se puede evitar que se activen automáticamente. Cada módulo que se desactivó ya no carga scripts. Una descripción general de la configuración:

Descargar Module Control para Jetpack

Parte 2 de la optimización de Jetpack: evitar que CSS se cargue cuando no se necesita

Jetpack carga toneladas de archivos CSS que no son necesarios en todos los casos. Mi sitio web no necesita uno solo, por eso los desactivé todos. El código para eso se escribió de manera que los elementos individuales se pueden eliminar cuando los necesite.

Un clic abre Gist en GitHub

El resultado final: un sitio web realmente rápido

La primera ejecución con las herramientas de Pingdom

La segunda ejecución con las herramientas de Pingdom

Con todas las configuraciones que hicimos, creamos un sitio web que se carga en cuestión de milisegundos. No obstante, no habríamos terminado en este punto, ya que es mucho más posible. Podría prescindir del widget de publicación superior o de las imágenes de gran formato para mis libros electrónicos. El complemento de: comentarios para los comentarios podría desactivarse, y podría usar los comentarios de WordPress con un almacenamiento en caché para los Gravatars. Además de eso, podría eliminar los bloques de anuncios de Google Adsense y Plista. Ciertamente sería posible un tiempo de carga de 300 milisegundos. Pero eso no es practicable, en mi opinión.

Acelere realmente los sitios web de WordPress: la serie

Noupe: Sin tonterías: lo que realmente acelera los sitios web de WordPress – [#1]
Noupe: Alta velocidad: realmente acelere los sitios web de WordPress – [#2]
Noupe: Alta velocidad: realmente acelere los sitios web de WordPress – [#3]
Noupé: Alta velocidad: realmente acelere los sitios web de WordPress – [#4]

Enlaces relacionados:

(dpe)

#Alta #velocidad #realmente #acelere #los #sitios #web #WordPress

Alta velocidad: realmente acelere los sitios web de WordPress [#5]