• Bienvenido a XenForo Hispano. Somos una comunidad independiente sin vínculos comerciales ni legales con XenForo Ltd. Ofrecemos asistencia en español para su software y traducciones exclusivas de complementos oficiales y de terceros.

XF 2.3 Optimización de imágenes, redimensionamiento de imágenes mejorado, ¡y mucho más!

https://ginernet.com/cdn/imagenes/banners/720x90-es.gif
Esperamos que estés disfrutando de la serie "¿Has visto...?" de XenForo 2.3 hasta ahora. Aún nos queda bastante por mostraros mientras trabajamos para dar los últimos retoques antes de lanzar XenForo 2.3 en este mismo foro.

Esta semana vamos a hablar de varias mejoras que hemos hecho que se centran principalmente en torno a las imágenes.

Echa un vistazo al índice de abajo para saltar a un post específico:

Para ver este contenido necesitaremos su consentimiento para instalar cookies de terceros.
Para obtener información más detallada, consulte nuestra página de cookies.


Esto es todo por esta semana, ¡continuamos la semana que viene! La semana que viene nos centraremos en una única nueva característica, es una barbaridad y estamos deseando emocionarlos aún más al apasionante mundo de XenForo 2.3 🌎🪝

screenshot-2023-10-11-at-00-59-50-png.292279
 
Última edición por un moderador:

Optimización de imágenes compatible con WebP​

Podríamos haber hablado de ello en nuestra entrada sobre el rendimiento de los parachoques, pero aún no estaba listo para mostrarlo. (He empezado a trabajar en ello esta semana y todavía no domino el arte de viajar en el tiempo).

Inicialmente, el alcance de nuestro soporte WebP en XenForo 2.3 era simplemente permitir a los usuarios subir archivos WebP y que se mostraran correctamente en línea. Esto habría sido un cambio positivo por sí mismo, ya que el formato se vuelve más frecuente en la web, pero no hace mucho por sí solo para resolver el problema del uso del disco que, por supuesto, también tiene un efecto positivo en el rendimiento.

Pero esto no es suficiente.

1697030523950.png


Si desea optimizar automáticamente todas las imágenes que suba en el futuro, sólo tiene que activar esta opción.

Al cargarlas, todos los tipos de imagen admitidos actualmente (excepto los GIF) se guardarán en formato WebP.
Nota al margen: Como ocurre ahora, las miniaturas, los banners de perfil y los avatares (y cualquier otra cosa que tenga un nombre de archivo establecido mediante programación) se servirán con una extensión .jpg, independientemente del formato de archivo subyacente.
Si tiene tipos de contenido personalizados que ya utilizan el sistema de archivos adjuntos, como hacemos con la Galería multimedia y el Gestor de recursos, las imágenes cargadas en ellos también se optimizarán automáticamente.

De hecho, si su complemento gestiona las subidas mediante el método predeterminado, es decir, la clase XF\Http\Upload, todas las nuevas subidas de imágenes se optimizarán automáticamente. Esto se extiende a casi todos los sistemas que tenemos, incluido el sistema de carga de activos del administrador.

Como desarrollador, si usted desea optar por este comportamiento por cualquier razón, puede hacerlo con el siguiente one-liner:

PHP:
$upload->setImageOptimize(false);

Esto se refiere a futuras subidas, pero muchos de vosotros os preguntaréis cómo optimizar los archivos existentes. Así que te alegrará saber que puedes reconstruir automáticamente todos tus archivos adjuntos, avatares y banners de perfil existentes.

1697030676892.png


Estas son las típicas reconstrucciones que puede iniciar desde su panel de control de administración en la página "Reconstruir cachés".

Dado que se trata de un proceso bastante largo e intensivo, si prefieres ejecutarlo sin el riesgo de que el navegador deje de funcionar y sin supervisión, también puedes utilizar uno de los comandos integrados:

Código:
xf-rebuild:attachment-optimization
xf-rebuild:avatar-optimization
xf-rebuild:profile-banner-optimization

Como desarrollador, añadir soporte para tus propios tipos de contenido es trivial extendiendo la clase AbstractImageOptimizationJob.

Ya hemos ejecutado esto en una copia de desarrollo del foro de la Comunidad XenForo. Al hacerlo, el tamaño de archivo indicado en la tabla xf_attachment_data antes de la conversión era de unos 40 GB. Tras la conversión, el tamaño del archivo es de unos 19 GB.

Se trata de un ahorro significativo y también tendrá un impacto positivo en el rendimiento.

Las noticias "no tan buenas"​


WebP ya es compatible con los principales navegadores. Cualquiera que utilice un navegador actualizado no experimentará ningún problema con la visualización de imágenes. Sin embargo, algunos dispositivos Apple y navegadores anteriores a septiembre de 2020 no soportan WebP.

En concreto, si utilizas iOS 14 o superior, no hay ningún problema. Safari 14 y superior también es genial, pero debes estar ejecutando al menos macOS 11 Big Sur para que las imágenes WebP se muestren.

En navegadores anteriores, estos usuarios simplemente no verán las imágenes WebP en absoluto. Aparecerán como imágenes rotas.

A medida que pasa el tiempo, este problema va disminuyendo a medida que la gente actualiza su software y hardware. Pero es algo que debe tener en cuenta antes de convertir todas las imágenes a WebP.
 

Redimensionamiento de imágenes mejorado​

En la era de las cámaras que caben en nuestros bolsillos y que producen fotos con un número cada vez mayor de megapíxeles, estoy seguro de que te habrás encontrado en alguna situación en la que XenForo se queja de que una foto es demasiado grande. Ya sea debido a los límites de tamaño de los archivos o a una restricción que imponemos al tamaño de las imágenes que permitimos redimensionar a tu servidor.

En este último caso, el límite por defecto es que las imágenes no contengan más de 20 millones de píxeles. Y, aunque se puede aumentar estableciendo un valor personalizado en src/config.php, ese límite se estableció hace más de una década e incluso el alojamiento compartido más barato no va a explotar como la casa de @Kier golpeada por un rayo, sólo para manejar el cambio de tamaño de una imagen grande.

Sin embargo, hemos aumentado ese límite en XF 2.3 por defecto de la siguiente manera:

PHP:
$config['maxImageResizePixelCount'] = 48000000;

Si necesita un límite menor (o mayor), puede hacerlo añadiendo lo anterior a su archivo src/config.php y ajustando el valor en consecuencia.

Una vez aclarado este pequeño punto, déjame explicarte por qué importa mucho menos.

A partir de XenForo 2.3, el "administrador de archivos adjuntos" que impulsa el sistema de carga de archivos para cosas como recursos, galería multimedia y otros archivos adjuntos, ahora es capaz de cambiar el tamaño de las imágenes antes de que lleguen a su servidor.

Si tienes configuradas unas dimensiones máximas de anchura/altura, XF las redimensionará por ti en el lado del servidor, pero con 2.3 primero intentaremos redimensionarlas en el lado del cliente.

Tengo una fotografía de muestra de 14.026 x 14.026 píxeles de ancho (¡casi 200 megapíxeles!). En XF 2.2, si quisiera subirla, probablemente recibiría un error indicando que el archivo es demasiado grande para subirlo. Podría ajustar el valor de configuración antes mencionado, pero obviamente sus usuarios no pueden hacer eso. En XF 2.3, el archivo se redimensiona completamente en el lado del cliente usando APIs JavaScript antes de ser subido al servidor.

Dado que al cambiar el tamaño de una imagen se destruye cualquier metadato incrustado, como los datos EXIF, también hemos introducido una nueva biblioteca de terceros que puede capturar opcionalmente los datos EXIF antes de cambiar el tamaño. Esto es crucial para que la Galería multimedia de XenForo pueda seguir mostrando los datos EXIF en la galería, incluso para una imagen que ha sido redimensionada.

Se acabaron los molestos errores para los usuarios y, gracias a la potencia de la mayoría de los dispositivos modernos, también es bastante rápido y, en general, se tarda menos tiempo en cargar porque el archivo que se transfiere al servidor es más pequeño.
 

Utiliza cualquier emoji para emoticonos y reacciones​

Esta nueva función es un poco más miscelánea que otras, aunque tiene que ver con imágenes, supongo...

Creo que la mayoría de ustedes se perdieron la pista en el primer post 2.3 HYS de @Kier:


Puedes ser perdonado, si te lo perdiste, por pensar que Kier simplemente había cargado emojis al estilo Apple para sus imágenes de reacción, pero este no es realmente el caso.

A partir de XF 2.3, ahora puedes añadir emoticonos y reacciones personalizados simplemente definiendo qué emoji te gustaría utilizar.

Puedes buscar el emoji que quieres usar empezando a escribir un código corto emoji, o incluso simplemente usando el teclado emoji de tu dispositivo para introducir el emoji deseado directamente:

1697031950435.png


Notarás que las opciones siguen ahí para subir una imagen personalizada o incluso usar un sprite, pero las reacciones por defecto (incluyendo la reacción de pulgar hacia arriba previamente personalizada) ahora se basan en emoji.

Esto significa que las reacciones y los emoticonos que utilicen emoji también se ajustarán a la opción emojiStyle, que normalmente afecta al contenido de la publicación. La gran pista en la publicación de @Kier en HYS es que tiene activado el emoji nativo del dispositivo, por lo que se muestran en el estilo de Apple. Por defecto, todavía utilizamos JoyPixels, pero es bueno saber que hay una opción de estilos disponibles.

1697032044367.png


1697032095712.png

Nota al margen: ¿Sigue la gente usando Twemoji? ¿Cómo lo llamamos ahora? ¿Xemoji? ¿Xmoji? ¿Muskmoji? ¿💩moji?

1697032194150.png


Los emoticonos funcionan exactamente igual. Por supuesto, para algunos, esto es menos útil, ya que proporcionamos el selector de emoji y apoyamos los emojis de todos modos al componer el contenido.

Pero si prefieres desactivar el selector de emoji en el selector del editor, y sólo quieres mostrar emoticonos, al menos ahora puedes asignar ciertos emojis que sí quieres ofrecer a emoticonos, mostrando así un subconjunto más pequeño de los emoji disponibles para su uso.
 

Variantes de tamaño para el cargador de activos del administrador​

Esta función es más bien una herramienta de desarrollo, pero está relacionada con las imágenes, así que encaja aquí. Esta característica fue escrita principalmente para ser utilizada en el nuevo estilo, antes de que se decidiera retrasarlo hasta la versión 3.0.

Puede que estés familiarizado con el sistema de carga de activos que añadimos en XenForo 2.2 y que te permite subir ciertas imágenes directamente en el panel de control de administración sin necesidad de utilizar tu programa (S)FTP.

Puedes usar esto ya en XenForo para subir imágenes de reacción, imágenes smilie y propiedades de estilo para cosas como logos.

A partir de XenForo 2.3, esta característica puede ser utilizada por los desarrolladores para crear automáticamente diversas variantes de tamaño para un activo subido.

El primer paso es utilizar el AssetVariantTrait en su Entidad, que tiene un método requerido para implementar:

PHP:
public function getAssetVariantSizeMap(): array 
{ 
   return [ 
      'image_url' => [ 
         's' => 128, 
         'm' => [512, 456] 
      ] 
  ];
}

Esto debería devolver un array ordenado por el nombre del campo que contiene la URL del activo cargado. La matriz interna se ordena por el código de tamaño para representar el tamaño de la variante. Si el valor del código de tamaño es un número entero, la variante se redimensionará a un cuadrado. Si se proporciona una matriz, el primer elemento de la matriz es la anchura y el segundo elemento de la matriz es la altura.

En el ejemplo anterior se crearán los siguientes archivos:

  • data/assets/your_asset_name/your_file.png - el archivo original cargado a tamaño completo
  • data/assets/your_asset_name/your_file - s.png - el activo redimensionado a un cuadrado de 128 píxeles
  • data/assets/your_asset_name/your_file - m.png - el activo redimensionado y recortado a 512 x 456 píxeles
También hemos introducido una nueva función Templater llamada asset_display que se puede utilizar así:

HTML:
<img src="{{ base_url(asset_display($entity, 'image_url', 's')) }}" />
 

Tamaño de las imágenes incrustadas​

En algo que podría haber sido mencionado en nuestro HYS de Aumentar el rendimiento si alguien (yo) no se hubiera olvidado de ello, también traemos noticias esta semana de mejoras que deberían reducir el Desplazamiento de diseño acumulativo (CLS) para las imágenes enlazadas en caliente dentro del contenido.

Actualmente, si incrustas una imagen desde una URL, no tenemos conocimiento previo de las dimensiones o relación de aspecto de esa imagen. Por lo que sabe el navegador, la imagen tiene 0 x 0 píxeles y, cuando empieza a cargarse, no hay espacio reservado para ella en la pantalla, por lo que el diseño de la página se desplaza a medida que se carga.

Esto tiene un efecto negativo no sólo en las métricas de rendimiento, sino también en la experiencia general del usuario, ya que las cosas empiezan a saltar por la pantalla.

Ahora haremos un seguimiento de estos tamaños en el campo embed_metadata del contenido y, hasta cierto punto, podemos reconstruir esa información cuando se ejecute la reconstrucción "Post embed metadata" contra el contenido existente (si el proxy de imagen ha almacenado las dimensiones).
 
Volver
Arriba