¿Es este un buen enfoque para la imagen Lazy Loading for SEO?

14

Para las imágenes cargadas a través de AJAX, o que no quiero indexar, use el enfoque de atributo data- *:

<img data-src="path/to/image.jpg" class="js-lazy-load" />

El javascript asigna el atributo data-src al atributo src :

<img src="path/to/image.jpg" />

Pero para las imágenes en el código HTML que yo no quiero indexada:

<a href="path/to/image.jpg" class="js-lazy-load">Image alt text here</a>

El javascript reemplaza el ancla con una etiqueta de imagen :

<img src="path/to/image.jpg" alt="Image alt text here" />

Parece que preservaría la capacidad del índice y la intención de la página (para accesibilidad) sin afectar el SEO (con suerte). Pero me encantaría una segunda opinión.

Editar: Cualquier comentario sobre cómo este enfoque, página con enlaces a imágenes versus página con etiquetas IMG en línea , se compararía con respecto al rango de página. Supongo que a las etiquetas IMG en línea les iría mejor ya que cada enlace saliente disminuiría el rango general de la página (a menos que tuvieran rel = "nofollow", lo que sería contraproducente).

seo google javascript

— Aeron
fuente

Los enlaces salientes no restan valor a su rango de página. Así no es como funcionan las relaciones públicas.

— Lèse majesté

¿El número total de enlaces salientes restaría valor al RP que tiene cada enlace? Entonces, si originalmente la página tenía 5 enlaces, cada uno con un 20% de RP, pero con este enfoque habría 50, ¿cada uno ahora tendría un 2%?

— Aeron

Eso es correcto. La cantidad de PR que se pasa se divide por el número de enlaces en la página, pero debido a la esculpición de PR, los nofollowenlaces ahora también se incluyen al dividir PR entre enlaces. Entonces, incluso si tiene 45 enlaces nofollow y 5 enlaces regulares, los 5 enlaces regulares solo pasarían el 2% del jugo del enlace. Aunque si Google fuera inteligente, tratarían los enlaces de imágenes de manera diferente a los enlaces HTML, ya que su solución es válida para la usabilidad y accesibilidad, y no se debe desanimar diluyendo su flujo de relaciones públicas.

— Lèse majesté

10

Ese es un buen enfoque. Otro enfoque que podría adoptar es usar el <noscript />elemento para almacenar la versión normal de la imgetiqueta, que sería indexada por Google, y usar JS para crear la versión de carga diferida.

Alternativamente, puede utilizar las convenciones hashbang AJAX de Google combinadas con la API de historial de HTML5 para crear estados de página con marcadores e índices. Esto es especialmente preferible si está haciendo algún tipo de página de desplazamiento infinito, ya que proporciona una forma de pseudopaginación, algo que la mayoría de las implementaciones de desplazamiento infinito necesitan desesperadamente ( :: tos :: Google Images :: tos ::) .

Editar: el uso de enlaces como marcadores de posición para las imágenes podría hacer que el flujo de PR de la página se divida entre más enlaces, aunque PR siempre se conserva a menos que lo use, nofollowen teoría, esto aumentaría el PR de esas imágenes para búsquedas de imágenes.

Si no quiere eso, o desea que la página se degrade con gracia para los usuarios que no son JS, puede ir por la ruta opuesta y comenzar con imágenes regulares, pero usando JS de bloqueo para sustituir el srcatributo de las imágenes al cargar la página (o incluso simplemente elimine los elementos de la imagen y almacene los srcatributos en su cola de carga diferida). Si lo hace correctamente, puede hacerlo antes de que cualquiera de las imágenes comience a descargarse.

— Lèse majesté
fuente

2

Me encantaría ver eso: Google no mira <noscript>y todavía no he encontrado una manera de bloquear la carga de imágenes en Firefox; la sustitución src(incluso con una <script>etiqueta inmediatamente después de la <img>etiqueta) no parece impedir que la imagen se descargue en la última versión de Firefox. Si conoce otra forma de hacerlo, ¡por favor comparta!

— mindplay.dk

@ mindplay.dk: Google puede optar por no usar noscripttexto en fragmentos, pero todo lo que he leído me lleva a creer que indexa el noscriptcontenido en general. Sin embargo, tienes razón al sustituir src. Mi idea original era poner un script antes de la primera imagen, para que bloquee la carga de las imágenes hasta que el script se haya cargado y ejecutado. Pero después de más exámenes, esto no funcionaría ya que las imágenes no aparecerían en el DOM en ese punto. Usted podría bloquear la descarga por el gasto excesivo con conexiones simultáneas con el anfitrión, pero eso es poco práctico en estos días.

— Lèse majesté

Un truco sucio alguien se le ocurrió es utilizar JS para comentar las imágenes JS-clasificado como tal (hay una versión más larga que se ocupa de análisis especulativo): <script>document.write('<'+'!--');</script><img src=...>. Tendrás que decidir por ti mismo si ese es un enfoque aceptable.

— Lèse majesté

2

He visto imágenes cargadas con este patrón:

<img data-src="path/to/image.jpg" class="js-lazy-load" />

ser recogido por Google y Google Image Search y otros también lo han visto . Dado que Google ahora ejecuta JavaScript en su página, puede que no sea necesario poner la imagen real en el atributo src. Descuidar un atributo src puede provocar un borde gris alrededor de su imagen, por lo que probablemente sea mejor usar algo como:

<img src="placeholder.gif" data-src="path/to/image.jpg" class="js-lazy-load" alt="Image alt text here" />

Nótese bien. Esto no se aplica necesariamente a otros motores de búsqueda.

— Willster
fuente