,

Posicionamiento Web | Resumen semanal 31 de Julio, 2012

SEO Barcelona - Bookmarks y Feeds: Resumen semanal Inbound Marketing SEO 2012

El posicionamiento web tiene muchas vertientes a tener en cuenta, ciertamente tantas y tan profundas que dan para poner apellido tras la palabra “SEO”: SEO técnico, SEO de contenido, link builders, SEOcial, etc; lo que está claro es que toda persona que se meta en el delicioso jacuzzi burbujeante del marketing online y especialmente los practicantes del SEO necesita estar muy encima de las noticias, tendencias y novedades.

Este es el resumen del 31 de Julio de 2012 de Ricard Menor SEO Freelance, como cuesta tiempo estar al día en todo lo que ocurre en Internet aprovecho a compartir mis bookmarks y feeds de interés, hoy hay 8 lecturas que te pueden resultar útiles:

 

twitter (feed #2)
Google Analytics desde tu móvil, descárgalo en https://t.co/NtfnWHDA
twitter (feed #2)
Sopa de aleta de Pingüino en Smarter Internal Linking – Whiteboard Friday | SEOmoz http://t.co/roSR6PKL vía @SEOmoz
twitter (feed #2)
#turismo Iberostar se queda con los hoteles de Thomas Cook en España http://t.co/D406IkRH vía @02B_com
twitter (feed #2)
¿Volveremos a ser receptores de verdad? http://t.co/PQy2mexU
generic (feed #3)
twitter (feed #2)
RT @TomAnthonySEO: @mattcutts Can you confirm whether hreflang linking a product page in various languages essentially acts as a canonic …
twitter (feed #2)
Mañana adiós a Bing Search API 2.0, toca migrar a Windows Azure Marketplac€, aquí un DOC con detalles http://t.co/DDbg5c4N
generic (feed #3)

 

El posicionamiento web bien hecho puede ayudar a reflotar muchas empresas y competir en el exterior

Ya sabes: Ricard Menor SEO freelance ES

,

SEO Freelance Barcelona | Resumen semanal 24 de Julio, 2012

SEO Barcelona - Bookmarks y Feeds: Resumen semanal Inbound Marketing SEO 2012

Una semana movida con papeleo y reuniones por Barcelona, algún proyecto que retrasa su inicio y otros que ven la luz después de un poco de lío…

Este es el resumen del 24 de Julio del 2012 de Ricard Menor SEO Freelance Barcelona, como cuesta tiempo estar al día en todo lo que ocurre en Internet aprovecho a compartir mis bookmarks y feeds de interés, hoy hay 4 lecturas que te pueden resultar útiles:

 

generic (feed #3)
generic (feed #3)
generic (feed #3)
twitter (feed #2)
Prerender o la carga instantánea de páginas, el prefetching de Google versión ES en http://t.co/zkGq0wFp #WPO #UX #SEO #Chrome

 

Por Ricard Menor, SEO freelance Barcelona

Un saludo a los amigos del turismo rural.
Me voy de vacaciones en breve :)

Prerender, usabilidad y velocidad de carga como factores SEO

SEO WPO Prerender Google Developers

Prerender y Prefetching precargan tus páginas para mejorar la UX

El Lunes 25 de Junio Google nos ofrecía una nueva perspectiva y renovada información sobre una llamativa y muy poco extendida técnica de mejora en usabilidad y velocidad de carga desde su blog para webmasters, en este artículo de Google se profundiza y se revisa el concepto primigenio de prefetching, compartido con Mozilla, aunque de la idea original se ha derivado una técnica que Google comparte con el mundo y que se basa más en sus propias capacidades técnicas e infraestructurales y planes estratégicos que en acuerdos comunes con W3C u otras entidades que ejercen influencia en el desarrollo de Internet y la www.

Como todo, el prerenderizado tiene cosas buenas y cosas malas, es recomendable leer con atención antes de ponerse manos a la obra.

A continuación os ofrezco la traducción EN > es-ES del artículo original, si vas a jugar con prerender y necesitas los datos te invito a seguir leyendo (debería decir “recomiendo”!)…

Guía para desarrolladores web sobre prerenderizado en Chrome

El prerenderizado es una característica experimental en Chrome desde su versión 13 en adelante,
esta característica puede seguir las sugerencias del autor de la página para acelerar la experiencia de navegación de los usuarios.
El autor del sitio incluye un elemento en HTML que instruye a Chrome para recopilar y renderizar una página adicional antes de que el usuario se traslade efectivamente a ella.

Como desarrollador web puedes estar interesado en lanzar el prerender o no, mucho más frecuentemente tendrás interés
en detectar si tu sitio está siendo prerenderizado.

Un vistazo a prefetching y prerender

Debido a que la Web es un sistema distribuído, puede darse un lapso entre el clic del usuario sobre un enlace y la carga efectiva de la página.

Este problema se hace especialmente notable en sitios que incluyen JavaScript, plugins y otros materiales referenciados como multimedia u hojas de estilo.

En algunos casos es posible saber donde es probable que el usuario haga el siguiente clic, por ejemplo cuando un usuario está leyendo un artículo multi-página es probable que haga clic en el enlace de “Siguiente página”.

En estos casos, estaría bien que el navegador pudiera comenzar a cargar la página ANTES incluso de que el usuario hiciera el clic, de forma que cuando haga el clic la página esté ya en camino o lista para ser leída. Este es el objetivo principal detrás del prefetching y el prerender. El concepto de prefetching está incluido en el estandar de HTML5.

El prefetching es una característica actualmente implementada en Firefox (saber más sobre Firefox y prefetching).
Permite a los autores web incluir un tag en el HTML que instruye al navegador para comenzar a recoger una URL dada. Cuando encuentra el tag, el navegador recoge el recurso de mayor nivel en dicha URL (a menudo una página HTML).
De todas formas el prefetching a menudo no conduce a mejoras en velocidad de carga que sean notadas por el usuario porque la mayor parte del contenido está en subrecursos como Javascript, CSS y ficheros multimedia. A la vez en algunos casos los subrecursos no son siquiera parte del HTML tal como los proporciona el servidor, siendo insertados vía scripts solamente cuando la página se carga.

El prerenderizado extiende el concepto de prefetching. En vez de limitarse a descargar el recursos principal, hace todo el trabajo necesario para mostrar la página al usuario sin llegar a mostrarla hasta que el usuario hace el clic. El prerenderizado se comporta similarmente al hipotético caso de un “medio clic” sobre un enlace de una página (abriéndola de fondo en una pestaña) y luego se pasara a esa pestaña. Aún así, con el prerender esa “pestaña de fondo” está totalmente oculta para el usuario y cuando este hace clic, sus contenidos se transfieren de forma inadvertida a la misma pestaña a la vista del usuario. Desde el punto de vista del usuario, la página simplemente se carga mucho más rápido que antes.

Los desarrolladores web pueden lanzar el prerenderizado como se describe a continuación. Comenzando en Chrome 17, Chrome mismo iniciará el prerenderizado en algunos casos, basándose en la interacción del usuario con la barra de direcciones.

Iniciando el prerenderizado

Decidir si usas o no usas prerenderizado

El prerenderizado es una funcionalidad avanzada en fase experimental, por lo que iniciarla en un momento poco adecuado puede derivar en la degradación de la experiencia de usuario, incluyendo un aumento de consumo de ancho de banda, mayor lentitud cargando otros enlaces y contenidos ligeramente obsoletos. Deberías considerar iniciar el prerenderizado solamente si tienes muy claro que enlace visitará el usuario a continuación. Por ejemplo, prerender podría ser potencialmente una buena idea para un enlace “Siguiente página” en un artículo. Ofrecer señales para prerendering será típicamente no apropiado para una inmensa mayoría de los casos.

Sintaxis para iniciar el prerenderizado

El prerenderizado en Chrome es iniciado por una etiqueta en HTML, similarmente a como se inicia el prefetching en Firefox. (Ten en cuenta de todos modos que a diferencia de Firefox los métodos de inicio mediante meta-http y cabeceras HTTP no son soportados de momento.)

Puedes iniciar el prerenderizado insertando un elemento link con su atributo rel en valor “prerender”, por ejemplo:

Cuando Chrome encuentra el elemento considerará prerenderizar la página enlazada. Esto sucedería durante el parseado de la página, o posteriormente si el elemento link se inserta dinámicamente en el documento vía JavaScript.

Usamos la rel ‘prerender’ en vez de ‘prefetch’ para denotar que se trata de una implementación experimental y asegurar que los usuarios de prefetch no disparan accidentalmente prerender sin entender como difiere respecto las implementaciones actuales de prefetch. Recuerda que la etiqueta es solamente una pista para indicar a Chrome que tal vez le interesaría prerenderizar algo — no garantiza que el prerenderizado suceda.

Algunas razones por las cuales el prerenderizado podría no suceder

Nota: Lista no exhaustiva, última actualización (del original publicado en Google en inglés) 13 de Junio de 2011.

  • El usuario emplea una versión de Chorme en la que el prerenderizado no está activado por defecto
  • El usuario ha deshabilitado el prerenderizado desmarcando la opción de configuración “Predict network actions to improve page load performance” (“Predecir acciones de red para mejorar el rendimiento de carga de páginas”)
  • Otra página está ya siendo prerenderizada. Chrome solamente hace prerender como máximo de una URL por instancia de Chrome (no una instancia por pestaña). Este limite podría cambiar en el futuro en algunos casos.
  • Hay múltiples directivas prerender en la página, situación indefinida sobre que directiva se acepta o ignora que dependerá de la secuencia en que dichas directivas son encontradas
  • Chrome encontró otra directiva prerender en los últimos 500 ms.
  • El usuario está navegando en una ventana de incógnito
  • El prerender es abortado en base a una situación causada por la página receptora. (Ver “Situaciones en las cuales el prerenderizado es abortado”).

Ver la sección “Debugging the Prerender” para más ayuda en el análisis de sucesos de prerenderizado en una instancia dada.
Para prevenir la presentación al usuario de contenido obsoleto, las páginas prerenderizadas con éxito serán purgadas (“expulsadas” en el texto original en inglés) tras 30 segundos si el usuario no ha hecho aún clic sobre el enlace a la página prerenderizada. Este limite puyede cambiar en el futuro. Las páginas que son prerenderizadas no aparecerán en el Histórico de navegación del usuario a menos que el usuario visite efectivamente la página. Aún así, los recursos cacheables de una página efectivamente prerenderizada y no visitada pueden permanecer en la caché, los cambios que los sitios prerenderizados hagan a las cookies persistirán.

A pesar de que el prerenderizado ha sido cuidadosamente diseñado con la seguridad en mente y a pesar de que Chrome abortará el prerenderizado en escenarios donde se detecte un sitio malicioso, existen escenarios de abuso, del mismo modo que existen en tecnologías establecidas como iframes.

Detectar cuando tu sitio está siendo prerenderizado

Incluso si no lanzas el prerender proactivamente, sigue siendo posible que otro sitio instruya a Chrome para prerenderizar tu sitio. Si tu página está siendo prerenderizada, esta podría (o no) ser mostrada al usuario (dependiendo de si el usuario hace el clic efectivo o no). En la inmensa mayoría de casos no tendrías que hacer nada especial para manejar el hecho del prerenderizado de tu página -simplemente debería funcionar.

Si necesitas saber si tu sitio está siendo prerenderizado (por ejemplo no quieres que una galería de imágenes se ponga a rotarhasta que el usuario en verdad está viendo la página con dicha galería, la API experimental de Visibilidad de Página (originalmente “experimental Page Visibility API“) proporciona una vía conveniente para detectar esos casos y reaccionar apropiadamente.

Nota: Chrome no pasa ninguna cabecera distinguible cuando el prerenderizado ocurre. Dado que la mayoría de prerenders convierte los prerenderizados en vistas de página reales, la API de Visibilidad de Página es el único modo de discriminar correctamente los prerenderizados. Cuando una página es mostrada al usuario, Chrome no manda nuevas peticiones, aunque podrías crear un script que use la API de Visibilidad de Página para lanzar una nueva petición.

Si tu sitio incluye scripts de terceros para analítica o publicidad, en muchos casos no deberías tener que hacer modificaciones a tu sitio -dichos terceros modificarán simplemente el script que proporcionan para hacer uso de la API de Visibilidad de Página. Deberías contactar con estas terceras partes directamente para saber si sus scripts soportan prerender. Puedes probar como se comporta tu página al ser prerenderizada usando este sencillo ejemplo.

Situaciones en las que el prerendering es abortado

Mientras prerenderiza un sitio web, Chrome puede en algunos casos encontrarse en una situación que potencialmente podría desembocar en un comportamiento susceptible de ser visualizado por el usuario, lo cual es incorrecto. En dichos casos el prerender será abortado de forma opaca al usuario.

Algunos de estos casos incluyen:

Nota: Lista no exhaustiva. Última actualización 11/10/2011.

  • La URL inicia una descarga
  • HTML Audio o Video en le página
  • Peticiones POST, PUT y DELETE XML HTTP
  • Autentificación HTTP
  • Páginas HTTPS
  • Páginas que provocan alertas de malware
  • Creación de ventanas/popup
  • Se detecta utilización de alta resolución
  • “Herramientas del Desarrollador” está abierto

Plugins como Flash no serán inicializados hasta que el usuario visite efectivamente la página prerenderizada que los contiene.

Depurar el prerendering

El Prerendering está diseñado para ser cuasi invisible para el usuario casual – los sitios que prerenderizan simplemente cargan más rápido en algunos casos. Chrome decidirá o bien no iniciar o bien abortar un prerender por determinadas razones, lo que significa que para los desarrolladores puede ser difícil a veces discernir si sucedió el prerenderizado en un caso específico.

– La siguiente sección explica como determinar si se usó prerendering en una página –

Tienes la opción de deshabilitar la característica de Chrome 17+ que puede iniciar el prerendering basándose en la interacción del usuario con la barra de direcciones.
Para deshabilitar este tipo de prerenderizado, arranca Chrome con la marca de línea de comandos --prerender-from-omnibox=disabled (Command-line flag en el original)

Comprobar si se usa prerendering en una página

La velocidad de carga de una página por sí misma no es necesariamente un indicador a prueba de tontos de si sucedió el prerender o no. Para chequear si hay prerenderizado para una página dada:

  1. Abre el Gestor de Tareas de Chrome
  2. Carga la página que incluye la señal para prerenderizar
  3. Busca una nueva línea que comienza con “Prerender: ” que muestra un icono especial. Si ves una línea tal, se está haciendo prerendering para esa página

screenshot of Chrome's Task Manager

Comenzando con Chrome 14 la pestaña de tráfico interno (net-internals tab en el original) incluye más información detallada sobre prerendering. Puedes ir a dicha pestaña copiando y pegando esta URL en la barra de direcciones de Chrome: chrome://net-internals/#prerender

Asegurar que prerender está habilitado en Chrome

Prerender se encuentra habilitado para muchos usuarios de Chrome 13 por defecto. Aún así, hay casos por los que prerender pueda estar deshabilitado. Si los pasos para comprobar si se usa prerendering en una página muestran que el prerendering está ocurriendo, entonces tienes habilitado el prerender. La antes mencionada página de test te alertará si tienes deshabilitado el prerender.

Para asegurar con certeza que el prerendering está habilitado:

  1. Mira en la configuración de Chrome y asegúrate que “Predict network actions to improve page load performance” está marcado (lo está por defecto)
  2. Inicia Chorme con la marca de línea de comando --prerender=enabled

Saber más sobre Prerender

Puedes participar en el grupo de debate sobre prerender

 NOTA: Última actualización del original, 30 de Marzo, 2012. 

Page Visibility API

,

SEO Barcelona | Resumen semanal 17 de Julio, 2012

SEO Barcelona - Bookmarks y Feeds: Resumen semanal Inbound Marketing SEO 2012

SEO freelance te ofrece este resumen sobre SEO 2012, semana del 17 de Julio, si no lo habías visto antes te diré que comparto semanalmente una selección de mis bookmarks y feeds para ayudarte a estar al día, tal como me gusta hacer a mi con webs, blogs y recursos de otr@s colegas; como cuesta tiempo estar al día en todo lo que ocurre en Internet aprovecho a compartir mis bookmarks y feeds de interés, hoy hay 8 lecturas que te pueden resultar útiles:

 

twitter (feed #2)
twitter (feed #2)
#empleo #SEO Manager UK, gran oportunidad internacional sector Gambling/Apuestas, contáctame en formulario web http://t.co/dF8nF6G4
twitter (feed #2)
http://t.co/Ipg0zFzm Hola Tomás, Me llama poderosamente la atención que sea un jubilado de 69 años quien tenga que mencionarte la…
twitter (feed #2)
http://t.co/KwdxReFL “Me resulta frustrante, de escasa ética e irresponsable que ande suelta por ahí toda clase de alimañas ejerciendo…
twitter (feed #2)
#FF @yoast goes crazy monetizing :) Go Joost, go! Good idea, Friday factor ;)
twitter (feed #2)
Digg vendido por piezas, Linkedin adquirió 15 patentes ($4M) vía @TechCrunch http://t.co/k7IKR2Rn
twitter (feed #2)
#empleo German speaking #SEO Manager, London, oportunidad internacional sector Turismo Online, pregunta aquí http://t.co/dF8nF6G4
generic (feed #3)

 

“Arigato” significa “Gracias” en Japonés, resulta que me lo pasé en grande tanto profesionalmente como en el plano personal durante el pasado Clinic SEO sobre Mobile SEO, que comenzó para todos a las 19:30 pero terminó para unos pocos a las 03:30 del Miércoles, al más puro estilo “pueblecito de irreductibles SEO que resisten ahora y siempre al panda, al pingüino y a lo que nos echen”.

Ahora que ya he demostrado que sé divertirme (arte casi olvidado ;) déjame demostrarte que sé hacer SEO…
Ricard Menor SEO Barcelona