El diseño responsive no siempre es lo mejor


Últimamente todo el mundo apuesta por el diseño responsive y tiene sentido. Con un único diseño que se adapta a los diferentes tamaños de pantalla estoy dando a mi usuario la mejor experiencia en mi web. Pero no siempre es la mejor alternativa si tenemos en cuenta las diferentes condiciones que rodean a la navegación desde diferentes dispositivos. Un smartphone puede acceder a Internet a través de WIFI o a través de la red móvil, mucho más lenta. Lo mismo pasa con las tablets aunque en este caso el porcentaje de accesos a través de WIFI es mucho mayor que a través de la red móvil. Esta sutil diferencia puede suponer que la experiencia de un usuario sea completamente diferente en función de cómo esté accediendo a Internet.

Veamos dos ejemplos diferentes:

  • etece.es
    • diseño responsive: no
    • versión web móvil: si
    • peso de la home de escritorio: 477,5 KB
    • peso de la home móvil: 140,2 KB
  • otogami.com (espero que los camaradas del metal no les importe que la coja como ejemplo)
    • diseño responsive: si
    • versión web móvil: no porque ya tienen el diseño responsive
    • peso de la home en tamaño escritorio: 478,5 KB
    • peso de la home en tamaño móvil: 473,5 KB

Como podéis ver, aunque lo esté viendo en un tamaño mucho más pequeño, el diseño responsive necesita cargar la mayoría de los elementos que existen en una versión web de escritorio y por tanto el peso de la home es prácticamente el mismo.

Si tenemos en cuenta que una conexión 3G media en España está en torno a los 1,5Mbps (fuente adslzone.net) , esto supone unos 192 KB por segundo. Es deir, la home de etece en un móvil por 3G se cargará en menos de un segundo mientras que la de otogami tardará 2,5 segundos. A lo mejor esa diferencia de tiempo no supone un cambio en la experiencia de usuario en algunos casos, aunque en algunos otros puede ser la diferencia entre que el usuario se quede en mi web y acabe convirtiendo o que el usuario abandone.

Además de las razones que tienen que ver con experiencia de usuario, hay otras razones técnicas por las cuales el diseño responsive no siempre es la mejor opción. Si consideramos que un hilo de Apache está ocupado durante todo el tiempo que dura la descarga de lo que esté subiendo, con diseño responsive estaré consumiendo 2,5 veces más tiempo que con una versión móvil específica. Eso supone recursos de mi servidor o lo que es lo mismo, podré soportar más usuarios concurrentes desde dispositivos móviles con el mismo hardware si uso una versión móvil específica frente a un diseño responsive.

Durante todo el post estoy diciendo que el diseño responsive no es siempre la mejor opción lo que quiere decir que hay veces que si que lo es. Cuando el peso de una página es bastante bajo, no merece la pena hacer una versión web y es mucho mejor tener un diseño responsive. Soy especialmente fan de los diseños responsive en webs de contenidos muy sencillas tipo wordpress y similar.

Me encantaría que este post abriera un debate y espero no quedarme solo defendiendo las versiones web móviles específicas.

17 comentarios en “El diseño responsive no siempre es lo mejor

  1. Estoy de acuerdo con tu POST.
    yo agregaría un punto importante.

    La visualización de ofertas.
    En la versión de Escritorio puedes poner ofertas de una forma sin embargo en la versión móvil la oferta aunque sea la misma, tiene que ir formada y formulada de forma diferente ya que el usuario tiene muy poco espacio para apreciar la oferta… y en este poco espacio tenemos que indicarle con palabras y un imagen muy estructurada de que trata la oferta.

    Defiendo las dos versiones, Responsive, para páginas informativas, para paginas de negocio con ofertas o tiendas virtuales prefiero dos versiones, ESCRITORIO Y MOVIL.

    Mi humilde opinión.

  2. Muy de acuerdo, pero no solo me quedaría en el peso de la web, sino en el diseño y ux. Teniéndolas separadas puedes diseñar pensando solo en el usuario de smartphone o web, para darle la mejor experiencia y optimizar para mejorar la conversión en ambas versiones. Pero como dices depende de cada caso, en muchos casos un diseño responsive te ahorra tener dos versiones de la web, por lo que cada web tiene que tener un mantenimiento y cuando modificas en cierto modo doblas el trabajo.

    • Hola a todos.
      Lo cierto es que no suelo adentrarme en debates en los que no pueda ver a mi oponente tras el vidrio de una buena caña, pero me surge cierto egocentrismo que me gustaría saldar.

      Dentro de mi quizás extraño proceso de formación, he adquirido la habilidad de abstraerme de las posibilidades del medio, pensando únicamente en la mejor ejecución.
      Este posicionamiento me ha permitido exprimir las posibilidades de los soportes que he utilizado.

      Dicho esto, considero que no diseñar pensando en cada dispositivo independientemente de si es una propuesta responsive o se trata de versiones específicas; es limitarse.
      ¿Por qué no diseñar para versiones específicas y desarrollarlas en modo responsive?

      Entiendo la preocupación por los pesos y los tiempos de carga, pero lo cierto es que existen cientos de fórmulas para evitar estos problemas. Un ejemplo sencillo es la posibilidad de cambiar una imagen por otra con un par de líneas de css y algunos media queries o llamar a css distintos en función del dispositivo. He llegado a desarrollar vistas completamente distintas para cada dispositivo.

      Pido disculpas si alguien entiende esto como un ataque a las ideas aquí expuestas. Mi única pretensión es dudar, por algo soy artista diseñador y gallego.

      Un saludo.

      • Estoy de acuerdo con tu comentario.
        pero, igual estoy de acuerdo, que el responsivo no siempre se aplica para todos los proyectos.

        Desde mi punto de vista.
        A tus ordenes.!

  3. ¡Interesante post! El tema del peso creo que es, aparte de un punto importante en la experiencia, un problema de penalización seo no?

    En mi humilde experiencia, hacer un diseño responsive “bueno y eficiente para todos los dispositivos” es casi un arte, en el que, muchas veces llevar el control de lo que debemos y no debemos hacer (escalar los logos e imágenes, reducir las descripciones de producto, ofrecer zooms y alternativas para detalles de productos, incrementar los botones de acción o decrementarlos según el caso, tener en cuenta que no todos los usuarios maximizan sus ventanas, reducir la información irrelevante o tipo seo en los footers, controlar que los teléfonos sean “llamables”, etc) en muchos casos resulta mas complejo (coste-trabajo) que mantener dos versiones del interface. No todos podemos hacer lo que hace googlemaps.

    Desde el user-pov o ux, hay un par de motivos (1. Dar al usuario lo que espera, si cambiamos el diseño no es posible. 2.El usuario debe sentir que tiene el control, y el usuario no puede utilizar el formato habitual, se ve forzado al nuevo) que hacen dudar que un diseño “responsive” gane en una balanza.

    Creo, que con dos versiones ganamos mucho control sobre estas, diseñamos (ux – ui – estética) mas orientados a la funcionalidad, “trackeamos” mejor, y nos permite decidir que debemos conservar o no en cada versión. Y educamos al usuario en ambas.

    Creo que en muy contadas ocasiones necesitamos un diseño “responsive”, y la mayoría de casos, las implementaciones conllevan mas problemas que beneficios.

    Saludos!

  4. Daniel,
    interesante debate y buenas respuestas. En tu exposición te quedas con un punto muy considerable, que es la velocidad de acceso y el tiempo de respuesta. Pero el análisis es muy complejo. Para mi todo empieza con los recursos de los que dispones. Si tienes capacidad técnica, puede ser bueno tener dos versiones, escritorio y móvil. Pero para que vayan bien, necesitas más tiempo de gestión, más recursos. Si no los tienes, el responsive es una buena alternativa.
    Después, hay que tener en cuenta el tipo de web que tienes. Una web de contenidos, no es igual que un comercio electrónico o una web transaccional como puede ser etece. Seguramente las propuestas de trabajo en vuestra web se hacen a través de escritorio, pero postularse para una oferta se puede hacer bien desde el móvil.
    En el caso de Otogami, supongo que el cliente medio va a comprar por precio, por lo tanto es importante la versión móvil.
    En nuestro caso, que tenemos una armería, nuestro cliente suele ser reflexivo, los precios son caros y no es compra compulsiva. Nos gustaría mejorar nuestra conversión móvil, pero de momento no es una prioridad. Por eso, la versión responsive ahora nos sirve.

    • Hola Bernardo, gracias por comentar. Como apuntan en un comentario anterior, tener un diseño responsive no quiere decir que sea más barato, aunque depende de cada caso.
      Estoy de acuerdo contigo en que hay muchos casos en que es la mejor alternativa pero como dice el título, no siempre lo es. Y es que hay veces que la gente da por hecho que es la única y mejor opción sin entrar a valorar los detalles que mencionas.
      Por cierto, mucha suerte con CazaWorld

  5. Pingback: Diseño Responsive o Locurónsive | Bonillaware

  6. Buenas,

    desde mi humilde experiencia, yo voy a dar mi punto de vista de los diseños responsives, que es lo que preferí en vez de hacer versión móvil por separado.

    Obviamente, las dos opciones tienen sus partes buenas y malas

    Para la principal ventaja es que no hay que tener dos mundos separados. Es decir, tener una web móvil y otra para escritorio, sigue siendo tener 2 diseños (programados) para cada pagina, mientras que en responsive solo tienes uno (aunque más complejo al ser responsive).

    Sobre el tema de los tiempos de carga y la UX, estoy de acuerdo a medias. Nosotros lo hicimos muy mal (pq aunque se sabia que era responsive, no se diseño (gráficamente) ni para móvil ni para tablet y se a adaptado a posteriori… un error de base). Pero si se hace bien, puedes hacer un poco la pagina a tu antojo y cargar o descargar cosas dependiendo de versión (no me refiero solo a visualizar o no, sino cargarlas via Ajax, imagenes adaptadas, …)

    Por ultimo, otro tema que creo que el responsive tiene sus virtudes, es el tema de las tablets. Ya que la gente si diseñas una pagina especifica para móvil y otra para escritorio, que le enseñas al que tiene tablet?
    Los frameworks responsive te permiten hacer cosas diferentes para diferentes tamaños, y creo sinceramente que se puede hacer cosas realmente buenas para cada dispositivos.

    No digo que sea fácil, no digo que sea la mejor opción, y tiene sus cosas negativas. Pero creo que bien hecho puede hacer cosas muy interesantes.

    • Hola Patxi,
      gracias por comentar. Aunque no lo parezca, no defiendo lo no responsive. De hecho, si tienes equipo y capacidad de hacerlo bien (como comentas) es una opción cojonuda. El tema es que en algunos foros parece que es la única alternativa y ahí es donde disiento. Hay muchos factores que te pueden hacer decidirte por una opción u otra. Yo he mencionado sólo algunas. Aquí en los comentarios se han aportado otras y David Bonilla en su blog algunas otras. Lo bueno es que haya opciones y debate y sobre todo, que entendamos que cada uno toma la mejor decisión en función de las cartas que tiene.
      Un saludo

  7. Daniel, en este caso como en muchos otros, todo depende. Yo con este tema no soy de opiniones fijas. Todas las tecnologías, como sabemos , tienen sus pros y sus contras. Y es cuestión de listar cuales con tus prioridades y objetivos y , en función de ellos, elegir aquella que mejor se adapte a cubrir esos objetivos. No creo en definir una opción mejor sino en definir una opción que se adapta mejor a tus prioridades, necesidades y circunstancias y que ayuda mejor a conseguir tus objetivos de negocio, que es al final lo que da la pasta.

    EN lo que en su momento hacíamos aquí y tu conoces, optamos por el diseño responsive. La verdad es que la elección fue forzada por las circunstancias, el “equipo” de diseño ( que era una sola persona ) a tiempo parcial hacía que el hecho de mantener varios diseños independientes no fuera posible. Luego, también es cierto que se adaptaba bastante bien a la información que mostrábamos, que no era mucha. Así que en ese caso concreto para ese proyecto, era el ideal ¿ en otros proyectos ? pues seguramente hubiera habido más discusión

    No es por querer cambiarte el debate pero más que debatir sobre si el diseño responsive o específico es mejor o peor, sería mejor enfocarla hacia cuales son las ventajas de uno y de otro y en qué circunstancias proporciona más o menos ventajas, como algunas de las personas que han opinado lo han enfocado

  8. Hola, llego varios meses tardes, pero como nunca es tarde si la dicha es buena.
    La solución es versión exclusiva móvil + dyamic serving.
    ———————————————————————————–
    Publicación dinámica de diferentes HTML en la misma URL

    La publicación dinámica es una configuración en la que el servidor responde con varios códigos HTML (y CSS) en la misma URL según el user-agent que solicite la página. Dado que no es del todo evidente que con esta configuración el sitio modifique el HTML según los user-agents para móviles (el contenido móvil se encuentra “oculto”), se recomienda que el servidor indique al Googlebot para smartphones que también rastree la página y así detectar el contenido para móviles. Esta indicación se implementa mediante la cabecera Vary HTTP.

    La cabecera Vary HTTP

    La cabecera Vary HTTP tiene dos implicaciones importantes y útiles:

    Señala a los servidores de caché que se usan en ISP y en otros lugares que deben tener en consideración al user-agent a la hora de decidir si se proporciona la página desde la caché o no. Sin la cabecera Vary HTTP, una caché podría proporcionar por error a los usuarios móviles la caché de la página HTML de equipo de escritorio o viceversa.
    Ayuda al robot de Google a detectar más rápidamente el contenido optimizado para móviles, ya que una cabecera Vary HTTP es una de las señales que podemos utilizar para rastrear las URL que proporcionan contenido optimizado para móviles.
    La cabecera Vary HTTP forma parte de la respuesta del servidor a una solicitud, de la forma siguiente:

    GET /page-1 HTTP/1.1
    Host: http://www.example.com
    (…rest of HTTP request headers…)

    HTTP/1.1 200 OK
    Content-Type: text/html
    Vary: User-Agent
    Content-Length: 5710
    (… rest of HTTP response headers…)
    Esto significa que el contenido de la respuesta variará en función del user-agent que solicite la página. Si el servidor ya utiliza la cabecera Vary HTTP, puedes añadir “User-Agent” a la lista que ya se ha proporcionado.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s