Coche rápido

AMP, WPO y las malas costumbres

01/06/2017

Comentaba Fernando Puente en una conversación de Twitter con Pablo López que el “WPO es el nuevo SEO”. Para los que os lieis un poco con las siglas esto viene a significar que la web performance optimization (optimización del rendimiento web) es ahora la nueva search engine optimization (optimización para motores de búsqueda). Y por todo lo que se está hablando últimamente de lo primero parece que no le falta razón.

Otra de las tecnologías que está de moda estas fechas es AMP de Google, a la que ya critiqué en su momento en el post sobre la charla de la web abierta avisando, eso sí, de que me parece que el punto de partida es el correcto. Pero dejar en manos de las decisiones de Google (y de su cache) todas nuestras páginas web no me parece que sea algo que a largo plazo nos vaya a funcionar.

¿Por qué se habla tanto de WPO, de AMP, de PageSpeed y demás términos? Porque en la mayoría de proyectos se nos ha ido y se nos está yendo de las manos todo lo que metemos en los desarrollos web. Y estamos intentando optimizar al máximo lo que tenemos, esa caja negra que es nuestro proyecto web -que tiene que ser tal cual-, sin pensar que tal vez lo que tengamos que hacer es, primero, abrir la caja negra y empezar a deshacernos de las cosas que realmente restan más que suman.

¿Podemos minimizar (o minificar) todos los scripts? Sí. ¿Y las hojas de estilo, hasta el HTML? Claro. ¿Podemos contratar un servidor más potente o utilizar un mejor CDN? ¿Y un plugin de cache? Por supuesto. ¿Y utilizar HTTP/2 y sacar partido al multithreading? Que sí, que sí.

Pero tal vez lo primero que hay que hacer es ver si realmente hacen falta esos cuatro scripts de tracking de estadísticas para saber hasta qué aire están respirando nuestros visitantes. O esos banners infames que nos persiguen por todo el scroll de la navegación. O si de verdad necesitamos un framework para maquetar mil elementos diferentes cuando nuestra página tiene dos fotos y seis párrafos.

AMP surge para eliminar en las versiones móvil todo esto que no hace otra cosa más que volver la carga lenta y la navegación incómoda. El punto de partida. Provocado por los desarrolladores y el ecosistema al que estamos dando forma. WPO surge para optimizar el resultado final. Al que no deberíamos llegar si lo tuviéramos en mente desde el primer momento.

Por eso creo que aunque estas recetas son útiles, es más importante avisar que tal vez no hagan falta tantos ingredientes. Y que aunque “siempre” se ha hecho así, es el momento de pararse y tomar decisiones sobre lo que estamos haciendo y lo que nuestros visitantes/clientes/usuarios necesitan.

4 pensamientos sobre “AMP, WPO y las malas costumbres

  1. Un post muy interesante Juan, con el que estoy muy de acuerdo.

    Soy firme defensor de subirse al carro de las nuevas tecnologías que llegan para mejorar lo existente, repito, si llegan para mejorar lo existente.

    Es decir, PHP7, HTTP/2, SSL, SSD… todo esto creo que hay que incorporarlo y es beneficioso para ti y para el usuario que te visita.

    Pero parece que en este sector nos falta un poco educar al cliente final. Hay mucha pluginitis, al cliente le gusta disponer de todas las opciones aunque no llegues a utilizarlas pero “por si acaso”. Y les sigue gustando mucho que un texto aparezca haciendo un “flush”, y se carguen las imágenes haciendo un “flaps”, y que el logotipo haga un “blurp” y cuando hagas scroll haga un “boing”…

    Más recargado y pomposo no siempre significa que sea lo mejor. Cada vez tengo más claro que menos es más, y que deberíamos aplicar más filosofía KISS y no complicar las cosas.

    Claro que esto es sólo mi opinión y no se puede generalizar. Pero cada vez cobra más importancia la estrategia, tener claro qué necesitas y donde quieres llegar.

    1. Me encanta lo de los “flush” y los “flaps”, sobre todo porque imagino que está todo dentro de un fantástico slider! Está claro que hay casos y casos, y que no es lo mismo la web de una agencia de marketing/publicidad creativa que la de un dentista… pero muchas veces los devs pecamos de que todo sea clavo para nuestro martillo.

    2. A veces Pablo dudo de si es realmente un problema de educar al cliente o al desarrollador. De aprender a decir NO.

      Muchos desarrolladores tienen como máxima que si el cliente pide tal o cual pues se le da y punto, con lo que al final el desarrollador queda relegado a una simple marioneta sin criterio técnico que simplemente instala lo que el cliente pide. Es al fin y al cabo una extensión de las manos del cliente.

  2. Creo que hay que llegar a un término medio entre lo utilidad y lo ponemos. Personalmente creo que mientras más simple, mejor suele funcionar. Está claro que en muchas ocasiones es necesario añadir funcionalidades y diseños pero los mínimo necesario siempre. Es como los plugin los realmente necesarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)

Información sobre protección de datos

  • Responsable: Juan Hernando Garca
  • Fin del tratamiento: Controlar el spam, gestión de comentarios
  • Legitimación: Tu consentimiento
  • Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  • Derechos: Acceso, rectificación, portabilidad, olvido.
  • Contacto: juan@ciudadanob.com.
  • Información adicional: Más información en nuestra política de privacidad.