Aplicaciones Web Progresivas y WordPress

0
919

Habiendo participado en la creación de aplicaciones web progresivas desde antes incluso de llamarse aplicaciones web progresivas, creemos que todos deberían usar JavaScript para crear experiencias de usuario increíbles en la web. Este ha sido nuestro mantra en los últimos años y nos atenemos a él :).

Sin embargo, el uso de los Sistemas de gestión de contenido (y en particular de WordPress) como backend / API ha resultado ser un desafío. Esto se debe principalmente al conflicto entre las tecnologías (cliente frente a backend) y el gran ecosistema de complementos / temas que rodean a WordPress. El valor de WordPress no es solo su potente núcleo, sino todos los widgets que puede instalar y mejorar la funcionalidad de su sitio de WordPress. La mayoría de estos son plug & play. Al mismo tiempo, todavía tengo que ver un PWA plug & play con una puntuación del 100% en Lighthouse . Donde quiera que veas historias de éxito (por ejemplo, la aplicación de Twitter ), también implican un montón de trabajo personalizado.

¿Entonces, dónde nos deja eso? No pretendemos tener todas las respuestas o una bala mágica y de plata que puede remodelar su sitio web de WordPress en un 100% PWA. Sin embargo, creemos que al analizar más detalladamente la tecnología detrás de WordPress, PWA y AMP, podemos aportar ideas sobre cómo cerrar la brecha entre ellos. A continuación, encontrará una lista de 5 puntos clave que creemos que deben abordarse para que avancemos en la dirección correcta.

1. Representación del lado del servidor frente a la representación del lado del cliente

Los temas y complementos de WordPress utilizan la representación del lado del servidor. Si no está familiarizado con las diferencias entre el servidor y el servidor, puede leerlo aquí . En resumen, los temas / complementos de WordPress necesitan un servidor para ejecutar el código y producir una salida (código HTML y CSS).

En contraste, el estándar PWA  no impone un uso particular de la tecnología para implementar dicha aplicación. La mayoría de los PWA se basan en bibliotecas / marcos de JavaScript y, por lo tanto, son aplicaciones de página única (SPA). También es posible crear aplicaciones de múltiples páginas como PWA, sin embargo, la arquitectura está muy personalizada. Aquí puede encontrar una presentación de Google I / O 2018, que describe la arquitectura de dicho PWA implementado utilizando un servidor NodeJS / Express.js y trabajadores de servicio . Esto puede ser incluso más intimidante en comparación con los SPA y aún requiere escribir código JavaScript, al menos para el trabajador del servicio.

Entonces, ¿qué sucede cuando combinamos la representación del lado del servidor de WordPress con un SPA? Bueno, no tenemos que elegir entre generar el código HTML y CSS en el servidor (representación del lado del servidor) o dejar que el navegador procese ese código (representación del lado del cliente). En WordPress Mobile Pack, usamos un tema especial de WordPress que se carga solo en los navegadores móviles. Elimina cualquier código de WordPress además del mínimo necesario para cargar los activos de PWA (JavaScript y CSS incluidos). Luego, es responsabilidad del navegador obtener el contenido (publicaciones, páginas, categorías, etc.) de la API REST de WordPress.

2. Limitaciones de la API REST

Creemos firmemente que la inclusión de la API REST en el núcleo ha abierto la puerta para crear aplicaciones sorprendentes sobre WordPress. Sin embargo, tal como está hoy, la funcionalidad de la API REST es limitada en comparación con todas las otras cosas que puede hacer desde el área de administración de WordPress. Solo piense, por ejemplo, en personalizar el menú para su sitio de WordPress. Puede ir a Apariencias> Menús y hacer eso, su tema sensible se adaptará fácilmente a los cambios.

Sin embargo, no hay un punto final que pueda ayudar a exportar esas configuraciones a una PWA. La funcionalidad de la API REST se limita a recuperar publicaciones, páginas, categorías, etc. y algunas configuraciones básicas . Por lo tanto, una tarea trivial que está disponible para todos los temas sensibles es incómoda para un PWA. Una solución consiste en ampliar las funciones de la API REST y crear nuevos puntos finales (hay algo de trabajo que se realiza en esa dirección aquí ). Esto no cambia el hecho de que tendremos que saltar a través de algunos aros para integrar nuestros PWA con las características básicas de WordPress.

3. Constructores de páginas y widgets

¿Quién no ama a un creador de páginas fácil de usar? Estos complementos prometen hacer nuestras vidas más fáciles y solo con arrastrar y soltar podemos hacer que nuestro sitio web se vea como queremos. No es de extrañar que su popularidad esté aumentando.

La mayoría de estos complementos se basan en la representación del lado del servidor. También insertan código JavaScript y CSS adicional y dependen en gran medida del contexto de la página para representar correctamente un diseño. Bueno, agregar un código JavaScript (como un widget) dentro de otro código JavaScript (PWA) es una receta para el desastre. El código JavaScript incorporado no se ejecutará porque no se carga directamente en el navegador.

Sin mencionar que la API REST ni siquiera exporta parte del código abreviado utilizado por los creadores de páginas, lo cual es normal porque ese código abreviado no tiene sentido fuera del contexto de un tema sensible.

4. Servicio de apoyo a los trabajadores.

Los trabajadores de servicios son una parte importante de la implementación de un PWA. Ayudan a proporcionar todas esas cosas de lujo, como el almacenamiento en caché / modo fuera de línea, agregar a la pantalla de inicio y las notificaciones de inserción web.

Una advertencia? Deben residir en el dominio raíz de su sitio web, incluso si su instalación de WordPress existe en sudominio.com/blog, el trabajador del servicio debe estar alojado directamente en sudominio.com. Y son archivos de JavaScript. Podría pensar “cuál es el problema, solo copiaré el archivo del trabajador de servicio a mi carpeta de temas”. Bueno, como ya mencioné, WordPress usa la representación del lado del servidor, lo que hace posible cargar contenido desde una carpeta de temas incluso cuando en el navegador está accediendo a la página de inicio. Sin embargo, los archivos JavaScript son diferentes: su ruta no cambia cuando se cargan desde el navegador. Y, por muy buenas razones (¡piense en seguridad!), Un tema o complemento no tiene acceso para escribir archivos en la carpeta raíz de su instalación de WordPress.

¿Así que lo que podemos hacer? Bueno, podemos copiar manualmente el archivo del trabajador de servicios mediante FTP. Pero espero que WordPress encuentre una mejor solución en el futuro. No quiero quedarme atascado para siempre copiando a mi trabajador del servicio cada vez que se actualiza el código de WordPress.

5. Falta de transparencia sobre cómo funciona el SEO para los SPA.

La falta de transparencia cuando se trata de la optimización de motores de búsqueda es una de las razones principales de la lenta adopción de los SPA. A pesar de que Google anunció que sus bots pueden rastrear el código JavaScript hace unos años, esto no cambia el hecho de que muchas personas aún miran su Consola de búsqueda de Google Webmasters y ven todo tipo de problemas allí.

El año pasado surgieron algunos detalles, principalmente el hecho de que Googlebot usa Chrome 41 para renderizar . Además, en Google I / O de este año, podríamos echar un vistazo a cómo funciona la Búsqueda de Google y por qué los SPA no son tan eficientes como los sitios web HTML / CSS básicos cuando se trata de SEO . Hubo una idea muy importante que fue compartida:

“La representación de los sitios web activados por JavaScript en la Búsqueda de Google se aplaza hasta que Googlebot tenga recursos disponibles para procesar el contenido”.

La solución recomendada es hacer la representación del lado del servidor solo para los robots, que si me preguntas, suena como una molestia porque terminamos manteniendo dos versiones diferentes del mismo contenido. Espero que haya una solución mejor, porque esta no suena nada bien.

Conclusión

Lo bueno de todo esto es que Google definitivamente está haciendo pasos para cerrar la brecha entre sus tecnologías y WordPress. Hubo otra presentación interesante en Google I / O que definitivamente debería ver: ” Haga que su sitio de WordPress sea progresivo “. El enfoque es muy interesante: usar AMP y el editor Gutenberg para crear sitios web de WordPress. Parece que el complemento WP AMP está recibiendo mucho amor recientemente y hay algunos casos de uso muy interesantes que se pueden construir sobre él.

A pesar de que no hay una solución mágica para resolver los problemas que mencioné en este artículo, espero que veamos muchos PWA más geniales construidos sobre WordPress, aprovechando la popularidad y la versatilidad de los CMS.

Dejar un Comentario

Por favor ingrese su comentario
Por favor entre su nombre aquí