Optimización

Cómo mejorar la presencia online en negocios del sector turístico.

1 comentario

¿Tu competencia está antes que tú en las listas de Tripadvisor, Booking, etc? ¿No consigues interacción con tus seguidores en Redes Sociales? ¿Tu web necesita mejoras? ¿Te gustaría salir en la primera página de resultados de los principales motores de búsqueda? Estamos seguros de que la respuesta a alguna de estas preguntas es “SÍ”.

El verano ha comenzado, los turistas ya están planificando sus vacaciones y los hoteles y restaurantes se preparan para la temporada alta en la que además, se tendrán que esforzar más que nunca para destacar sobre la competencia.

Inmersos en la era de las nuevas tecnologías y la comunicación social, el consumidor pasivo se ha convertido en cosa del pasado. Ahora son mucho más exigentes y quieren encontrar exactamente lo que buscan. Para ello utilizan su mejor baza: Internet. Las redes sociales se han convertido en un instrumento básico que afecta en la decisión de compra de cualquier cliente. ¿Qué cómo es el perfil del nuevo consumidor? El Prosumidor: os resumimos en pocos puntos:

  • Bien informado.
  • Buscan comentarios de otros usuarios y se dejan guiar por ellos.
  • Inconformista, siempre compara todas las opciones y no se queda con la primera oferta que llega a sus manos.
  • Inmediatez, quieren respuestas y soluciones rápidas ya que no están para perder el tiempo.
  • Reivindicativo, conoce sus derechos y no dejará que nadie le tome el pelo.
  • Infiel, no tendrá problemas para cambiar de marca si así lo cree necesario. Por tanto hoy en día es imprescindible mimar al cliente y cuidar hasta el más mínimo detalle.

Como veis, Internet, las redes sociales y los dispositivos inteligentes se han convertido en las principales herramientas de los nuevos consumidores, que están / estamos conectados continuamente.

Los comentarios de otros clientes son una poderosa herramienta para el sector turístico.

 

Un reciente estudio realizado por Phocuswright  en representación de TripAvisor afirma que casi el 50% de los viajeros o comensales no hacen una reserva sin antes leer las opiniones de otros clientes.

En cuanto al contenido de los comentarios, un 71% de los usuarios busca en la crítica la mención a las condiciones del hotel o restaurante y el 40% busca una experiencia reciente. Está claro, los comentarios en redes sociales o redes especializadas como TripAvisor se han convertido en una herramienta fundamental a la hora de buscar el lugar ideal donde dormir o el restaurante perfecto para comer.
Lo propio que se debe hacer en estos casos, es dejar en manos de profesionales del sector del Marketing online todo lo relacionado con vuestra reputación en la red. Pero mientras tanto, os dejamos algunos consejos para mejorar vuestra posición actual en TripAdvisor:

  • Subir fotos de calidad y bien categorizadas.
  • Responder siempre a las críticas.
  • Animar a los huéspedes o comensales a que dejen sus comentarios.
  • Mantener un perfil actualizado y cuidado hasta el más mínimo detalle.

No es broma, los turistas vienen pisando fuerte y hay que estar a la altura. Nosotros podemos ayudaros a mejorar vuestra presencia online y así destacar sobre la competencia.

Tu reputación online en negocios de hostelería y restauración puede mejorar, y lo sabes

Estaremos donde no estás, y mejoraremos donde sí estás.

¿Estás o no estás?

Paula GiaoCómo mejorar la presencia online en negocios del sector turístico.
leer más

Tendencias WPO. Optimizar la velocidad de carga web

Sin comentarios

Preliminar: “Web Performance Optimization” (WPO), es un término relativamente nuevo que ha cobrado más fuerza a raíz de que Google anunciase la importancia que adquiere la velocidad de carga de una web en los resultados de búsqueda y con el que luchamos todos los días los que nos dedicamos al marketing en buscadores a la hora de desarrollar estrategias SEO, de optimización web y de marketing online.

Por ello, en resumen, el WPO se encarga de analizar y proponer cambios para optimizar la velocidad de carga de una web con un objetivo principal: conseguir reducir el tiempo en el que los usuarios pueden visualizar una web completamente, mejorando su experiencia de usuario, lo que se traduce en beneficio para todos.

Más peso no significa más espera

Cuando hablamos de rendimiento web, o WPO, nos gusta usar la frase: “el peso no tiene porqué incrementar la espera”. Para ser claros, esto no es porque el peso de una web no importe, porque sí que importa, sino más bien porque habitualmente podemos hacer llegar una representación usable del contenido de una página web muy rápidamente, incluso si esa página es bastante pesada (muchos elementos, imágenes, widgets, publicidad, etc…).

En la raíz de esta distinción hay una medición de rendimiento que la comunidad web ha empezado a discutir y priorizar recientemente, conocida como rendimiento percibido. “perceived performance”

Anteriormente, gran parte de la atención puesta en el rendimiento web se centraba en la optimización de recursos como imágenes, tipografías, etc… lo que no ayuda a una carga más rápida. Pero hoy tenemos otras técnicas que podemos usar además de la optimización de archivos, y que se puede afirmar que tienen un mayor impacto en cuán rápido nuestros usuarios pueden ver y usar el contenido que les hacemos llegar.

Medición del rendimiento general y rendimiento percibido

Parte del motivo por el que en el pasado no nos hayamos centrado en el rendimiento percibido se ha debido a la falta de buenas herramientas para analizar los eventos que tienen lugar mientras nuestras páginas se cargan. Hoy en día, existen algunas soluciones:

Entre otras pocas, http://www.webpagetest.org se sitúa en la cabeza de la lista de herramientas que consideramos irreemplazables para obtener hoy un perfil fiable de rendimiento. Brevemente, la interfaz web de WebPageTest te permite poner a prueba un website en una gran variedad de combinaciones de navegador / dispositivo / localización, y recibir un montón de información detallada de cómo se cargó la página y sobre todo de qué se puede hacer para mejorarla.

He aquí una ojeada a la tabla resumen que se ve cuando aplicamos WebPageTest a una página;

Tabla webpagetest

Esta tabla resumen nos ofrece algunos datos útiles, como:

  • Tiempo global de carga: el tiempo que lleva  cargar todos los recursos de la página.
  • Peso en conjunto: peso combinado del HTML y de todos los archivos que se referencian (CSS, JavaScript, imágenes, tipografías, etc.)

Hay incluso una nueva columna que nos dice cuánto tarda en cargar la página en varias partes del mundo.

Las mediciones mencionadas representan áreas en las que nos hemos centrado tradicionalmente a la hora de revisar el rendimiento a alto nivel. Son áreas que podemos mejorar notablemente optimizando el tamaño de nuestros archivos (imágenes, tipografías, JavaScript, CSS) y minimizando el número de websites de terceros referenciadas para anuncios, widgets de redes sociales u otros.

Sin embargo, también hay valores en la tabla resumen que nos cuentan algo más acerca de cómo de rápida carga una página, y cuán pronto puede empezar a usarse. Afortunadamente, una página web normalmente puede empezar a usarse mucho antes de haberse terminado de cargar, así que, de nuevo, el peso no tiene porqué influir en la espera.

Para medir el rendimiento percibido en WebPageTest, solemos identificar estos valores:

  • Time to first byte (Tiempo hasta el primer byte): el tiempo que le lleva a la página devolver el primer byte de su contenido de respuesta
  • Start render (Comienzo de la visualización): el tiempo en que una página comienza a ser perceptible visualmente en la pantalla

También es útil el timeline view (vista cronológica) de WebPageTest, que nos permite ver cómo la página se visibiliza progresivamente a lo largo de fotogramas clave (keyframes).

La vista cronológica es particularmente útil porque da más significado a las etapas iniciales del proceso de visualización.

Mejora del rendimiento percibido

Al ver el tiempo hasta el primer byte obtenemos algunas pistas sobre el tiempo que le lleva al servidor procesar una petición desde una localización y a una velocidad de conexión dadas, y quizás sobre cuánta latencia de red está pesando sobre el tiempo de viaje de ida y vuelta al servidor, el actual cuello de botella del rendimiento de nuestra página web.

El tiempo hasta el primer byte se puede reducir de varias maneras (ninguna de las cuales es fácil), tales como acortar el tiempo que le lleva al servidor procesar una petición, actualizar la configuración de nuestra SSL (https://istlsfastyet.com/), y ofrecer respuestas HTML estáticas cuando sea posible. Y puede que la más importante: distribuir nuestro código de forma global usando un CDN (“Content delivery network” red de entrega de contenidos) (como Cloudflare, AWS, Akamai, etc.) tendrá un gran impacto en el tiempo hasta el primer byte, porque la distancia física entre el usuario y el servidor tiene gran importancia. La vista en cascada (waterfall) de WebPageTest nos da información sobre cuánto tiempo se tarda en la búsqueda DNS y en la negociación de SSL, de forma que podemos ver cuánto del tiempo hasta el primer byte se gastó en cada fase del viaje de ida y vuelta.

En la vista de start render (comienzo de la visualización), el cuello de botella está normalmente en el lado del usuario, en la forma en que escribimos el HTML. Esto es porque las formas en que el HTML referencia los archivos externos de CSS y JavaScript hacen que el navegador detenga el proceso de visualización hasta que acaben de cargar y analizar esos archivos.

Una herramienta mejor para identificar los recursos que bloquean el proceso de visualización es Page Speed, de Google (https://developers.google.com/speed/pagespeed/insights/). Al igual que WebPageTest, le damos una URL, y PageSpeedInsights nos devuelve una puntuación de rendimiento de 1 a 100, y nos da pistas para mejorarlo. Ej: “Eliminar el CSS y el JavaScript que bloquean el proceso de visualización”, representando todos estos archivos un potencial punto problemático para visualizar la página a una velocidad adecuada.

Todo lo que podamos hacer para solicitar esos archivos de una forma no bloqueante ayudará al navegador a empezar antes a visualizar la página.

Mejora del Start Render (Comienzo de la visualización)

Una página sin referencias externas CSS o JavaScript puede empezar a visualizarse al instante, y lo mismo una que referencie el CSS y JavaScript de una forma no bloqueante. Desde un punto de vista técnico, esto significa solicitar los archivos de forma asíncrona, o… no solicitarlos externamente en absoluto.

En lo que respecta al JavaScript, es aquí donde empezamos a considerar cosas como trasladar nuestras referencias JavaScript al final del documento, añadiendo los atributos async y defer a nuestras etiquetas script, o usando un código de JavaScript en nuestro html para solicitarlos dinámicamente (lo cual es útil si queremos dar a valer una solicitud asíncrona basándonos en funciones del navegador)

En lo que respecta al CSS, es aquí donde empezamos a considerar cuestiones como incluir en el código la parte más importante, o la parte “crítica”, de nuestras reglas CSS en el head de la página, y a solicitar la hoja de estilo completa de nuestra web asíncronamente. Esto último es más difícil de lo que debería. Y esto es porque, desgraciadamente, no importa dónde coloques un link en el documento… a diferencia de JavaScript, una referencia a una hoja de estilo va a detener la visualización tan pronto como se cargue en la mayoría de los navegadores.

Una pequeña función JS en el head de la página es, por ahora, lo mejor que podemos hacer para cargar asíncronamente el CSS, pero esperamos que los estándares vayan a mejorar pronto con la adición de nuevos atributos al elemento link.

No olvidemos la tipografía…

Hay otra cosa en la que pensamos cuando se trata del comienzo de la visualización: la carga de tipografías personalizadas. Desgraciadamente, cuando las tipografías personalizadas entran en juego, nuestros ajustes de comienzo de visualización pueden quedarse en nada, y particularmente en navegadores como Safari en iOS. Y esto sucede porque la mayor parte de los navegadores ocultan el texto que usa tipografía personalizada hasta que ésta haya terminado de cargarse completamente, lo cual se traduce en que la visualización inicial de la página es prácticamente inútil, sin importar cuán rápido se muestre.

Para combatir este comportamiento (y hacer más felices a los usuarios), recomendamos usar una aproximación progresiva a la visualización tipográfica, de forma que el texto se visualice inmediatamente en una tipografía ya existente mientras la tipografía personalizada está de camino. Cuando hagamos esto es realmente útil dar estilo a la tipografía existente que vayamos a usar para que coincida lo máximo posible en tamaño y espaciamientos con la personalizada, de forma que se minimice el cambio.

Volvamos a peso vs. espera

Para ilustrar cuánto pueden ayudar estas optimizaciones del rendimiento percibido, hagamos una pequeña prueba:

  • Extraer y colocar la fuente CSS “crítica”. (critical path)
  • Cargar Hojas de Estilo completas asíncronamente (y cachearlas para nuevas visitas)
  • Cargar todo el JavaScript asíncronamente
  • Cargar la tipografía asíncronamente y aplicarla de forma progresiva
  • Estilizar la tipografía existente para coincidir con la personalizada

Y veamos el resultado: ¡podemos reducir a casi la mitad el tiempo de carga tanto en start render como en carga global de la página!

En el futuro…

Así que estas son las cosas que podemos hacer ahora mismo para mejorar el rendimiento percibido de cualquier navegador que acceda a nuestro sitio. Pero la optimización es la optimización… sería genial que no necesitásemos hacerla. Por suerte, están en marcha ciertos cambios en los estándares web que harán estas técnicas innecesarias para los navegadores del futuro.

Uno de ellos es la última versión de HTTP (versión 2), que los navegadores y los servidores están empezando a implementar. HTTP2 incluye ciertas funciones como ServerPush (https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/), que permitirá a un servidor responder a una solicitud de una página HTML no sólo con el contenido HTML de la página, sino también con los archivos que necesita para visualizar la página (como CSS, JavaScript, tipografías e imágenes). Esta mejora sorprendente significará que los navegadores puedan hacer un uso mucho mejor de ese viaje de ida y vuelta al servidor, y visualizar páginas muy rápido sin la necesidad de incluir código CSS y JavaScript en la fuente. Otras optimizaciones que hemos usado durante años, como los sprites o el sharding de dominios, y la concatenación de archivos no serán necesarios con HTTP2 debido a las mejoras notables en las solicitudes del flujo de datos. Un tema interesante.

Por supuesto, el cambio a HTTP2 no ocurrirá de la noche a la mañana, ya que tanto servidores como navegadores tienen que hablar el mismo protocolo. Y también, para algunos navegadores el cambio no llegará nunca. Por ejemplo, cualquiera que navegue con Internet Explorer anterior a 11, Android 2, BlackBerry, y otros, no podrá comunicarse con HTTP2 en los sitios. Eso significa que tendremos que mantener ambos protocolos vivos en nuestros sitios durante mucho tiempo, e idear estrategias para aprovechar las ventajas de las funciones del HTTP2 sin obstaculizar la experiencia en navegadores que no lo comprendan.

El tiempo dirá qué salida tendrán estos enfoques uno junto a otro.

Para saber más sobre qué nos traerá el HTTP2: (https://www.mnot.net/blog/2014/01/30/http2_expectations).

Vía: FilamentGroup

Jesús QuintanaTendencias WPO. Optimizar la velocidad de carga web
leer más

D3 JS – Manipulación eficiente de documentos basados en datos sobre W3C

Sin comentarios

D3.js (Data-Driven Documents) es una biblioteca JS para visualizar datos en formas gráficas dinámicas. Se trata de una herramienta para la visualización de datos bajo estandards W3C haciendo uso de HTML5, SVG, JavaScript y CSS3. A diferencia de muchas otras bibliotecas, D3 permite un gran control sobre el resultado visual final.

D3 permite enlazar datos al DOM y aplicar transformaciones. Por ejemplo para generar una tabla HTML a partir de una serie de números. O bien utilizar los mismos datos para crear un gráfico interactivo SVG con transiciones e interacción.

Más info: http://d3js.org/

ej:

Jesús QuintanaD3 JS – Manipulación eficiente de documentos basados en datos sobre W3C
leer más

Google SERP Tool – Previsualización de resultados de búsqueda en Google

1 comentario

Resultados de búsqueda en Google

Un resultado típico

Título: la primera línea de cualquier resultado de búsqueda es el título de la página web. Haz clic en el título para acceder a esa página web.
URL: la dirección web de la página web del resultado aparece de color verde.
Fragmento (Descripción): se trata de una descripción de la página web que aparece debajo de la URL y que puede incluir un extracto real del texto de la página. Los términos de búsqueda aparecerán en negrita para que te sea más fácil decidir si la página contiene lo que buscas.

Vista previa

Título de la página
www.maismedia.com
Esto es un ejemplo de descripción en los resultados de Google. Este contenido tiene un máximo de 156 caracteres.
Jesús QuintanaGoogle SERP Tool – Previsualización de resultados de búsqueda en Google
leer más

1 mes de posicionamiento web y asesoría gratis

2 comentarios

¿Quieres saber lo que podemos conseguir en un mes?

En MaisMedia hemos creado un sorteo de 1 mes de posicionamiento web y asesoría gratis para que veas todo lo que podemos hacer por tu proyecto.

Tanto si necesitas posicionamiento natural, sem, estrategias, o asesoría para la optimización de tu negocio online, te ayudaremos a mejorar, y verás grandes resultados. Te animamos a participar. Porque queremos trabajar contigo.

Jesús Quintana1 mes de posicionamiento web y asesoría gratis
leer más