SMConnect 2022 - Con lo sviluppo del web, delle nuove tecnologie e web API, i motori di ricerca hanno iniziato ad utilizzare veri e propri browser per il rendering delle pagine web, creare un Web Rendering Service per il rendering su larga scala nasconde però molte insidie. In questo talk parliamo della session isolation nel rendering delle pagine web, da parte di motori di ricerca e tool, e di come questa può influenzare i dati di crawling.

1. Session isolation e rendering
delle pagine web
GIACOMO ZECCHINI
Marketing Technology Director
MERJ
#SMConnect
twitter.com/giacomozecchini
slideshare.com/giacomozecchini
speakerdeck.com/giacomozecchini

2. ● Web rendering e motori di ricerca
● Background e contesto della ricerca
● Cosa si intende per “session isolation”
● Esempi pratici e problemi reali
● Come risolvere il problema
● Test
● Conclusioni
Di cosa parleremo oggi?
@giacomozecchini

3. Web rendering e motori
di ricerca
@giacomozecchini

4. Non siamo più negli anni ‘90
L’introduzione su internet di nuovi rendering
pattern ha cambiato molte cose, siamo
passati dall’HTML statico a nuovi pattern più
complessi come Client-Side Rendering e
Progressive Hydration.
https://www.patterns.dev/posts/rendering-introduction/ @giacomozecchini

5. @giacomozecchini
I motori di ricerca eseguono il rendering delle pagine
I principali motori di ricerca, per riuscire ad
utilizzare gli stessi contenuti visualizzati dagli
utenti tramite browser, sono stati forzati ad
eseguire il rendering delle pagine utilizzando
veri e propri browser.
https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

6. @giacomozecchini
Web Rendering System
I motori di ricerca hanno sviluppato dei web
rendering system (o web rendering service),
dei sistemi in grado di fare il rendering di un
grande numero di pagine utilizzando headless
browser automatizzati.
“Googlebot & JavaScript: A Closer Look at the WRS”: https://www.youtube.com/watch?v=Qxd_d9m9vzo

7. Web Crawler cercano di seguire
Di conseguenza, anche se più lentamente, vari
Web Crawler hanno iniziato ad aggiungere il
rendering alle loro funzionalità.
@giacomozecchini

8. Il rendering è un argomento complesso
Eseguire il rendering delle pagine in modo
automatico su larga scala è un argomento più
complesso di quanto sembra.
@giacomozecchini

9. Non esiste un metodo standard
Non esistendo un metodo standard possiamo
addirittura dire che nemmeno Google esegue
il rendering “correttamente”. Ogni sistema di
web rendering è costruito per rispondere a
determinati bisogni e include compromessi.
@giacomozecchini

10. Background e contesto
della ricerca
@giacomozecchini

11. Web Crawler e soluzioni personalizzate
A Merj utilizziamo vari web crawler.
Nel caso di bisogni particolari e complessi,
non coperti dalle funzionalità dei tool esistenti,
progettiamo delle soluzioni custom.
@giacomozecchini

12. Da dove è partita la ricerca
Il progetto da cui è nata successivamente
questa ricerca riguardava la costruzione di
una data pipeline: dalla creazione di un data
source, delle pagine HTML, all’inserimento
delle stesse in un machine learning model.
@giacomozecchini

13. L’integrità dei dati è fondamentale
Durante lo sviluppo del progetto, il team “Legal
& Compliance” della compagnia ci ha chiesto
assicurazioni sull’integrità dei dati inseriti nel
machine learning model.
@giacomozecchini

14. Dati contrastanti nell’output dei tool
In aggiunta al processo standard di
valutazione dell’integrità dei dati, abbiamo
incluso nei test alcuni dei web crawling tool
più utilizzati, finendo per trovare alcuni dati
contrastanti.
@giacomozecchini

15. Cosa si intende per
“session isolation”
@giacomozecchini

16. Richieste “stateless”
Il concetto “stateless”, applicato alle richieste
HTTP di bot come Googlebot, è molto simile
alla session isolation, che però è applicata al
rendering delle pagine.
@giacomozecchini

17. Session isolation 101
Una sessione di rendering è considerata
“isolata”, se durante il rendering la pagina non
può accedere a dati immagazzinati nel
browser storage da rendering precedenti e
comunicare con altre pagine che vengono
renderizzate parallelamente.
@giacomozecchini

18. Esempi pratici e
problemi reali
@giacomozecchini

19. Customizzazione dei contenuti
@giacomozecchini
Alcuni dei problemi reali causati da una
mancata session isolation li possiamo trovare
in tutti quei siti web che hanno delle
customizzazioni dei contenuti basate sulla
navigazione degli utenti.

20. Box dei “Prodotti visti di recente”
@giacomozecchini
Un esempio abbastanza pratico e semplice da
visualizzare sono i box dei “Prodotti visti di
recente”. Questi box mostrano la storia di
navigazione recente dell’utente, con link ai vari
prodotti, e si possono trovare su moltissimi
siti web.

21. Ikea.com
@giacomozecchini

22. Asos.com
@giacomozecchini

23. Adidas.com
@giacomozecchini

24. Box dei “Prodotti visti di recente”
@giacomozecchini
Per tutti e tre i precedenti esempi il box
“Prodotti visti di recente” è implementato
salvando le pagine visitate dall’utente durante
la navigazione nella memoria del browser.

25. I dati in memoria influenzano il rendering
@giacomozecchini
Per quei web crawler che eseguono il
rendering delle pagine web senza isolare le
sessioni di rendering, i dati salvati nella
memoria del browser possono influenzare i
risultati.

26. @giacomozecchini

27. @giacomozecchini

28. @giacomozecchini

29. @giacomozecchini

30. @giacomozecchini

31. @giacomozecchini

32. @giacomozecchini

33. Un corretto rendering produce risultati diversi
@giacomozecchini
Se osserviamo come i motori di ricerca e i
web crawler che hanno una corretta session
isolation eseguono il rendering delle pagine, il
risultato è differente.

34. @giacomozecchini

35. @giacomozecchini

36. @giacomozecchini

37. @giacomozecchini

38. @giacomozecchini

39. @giacomozecchini

40. @giacomozecchini

41. Questa differenza nel rendering delle pagine
produce contenuti aggiuntivi e link
“fantasma”. Questi contenuti aggiuntivi e link
sono visibili solo nei risultati dei tool con
problemi di session isolation.
Contenuti aggiuntivi e link “fantasma”
@giacomozecchini

42. @giacomozecchini
Senza session isolation
Con session isolation

43. L’ordine di crawling/rendering conta
@giacomozecchini
A seconda dell’ordine di crawling e rendering i
risultati di un tool che non ha una corretta
session isolation possono includere contenuti
addizionali che cambiano ogni volta.

44. @giacomozecchini
Partendo dalla PAGINA 1
Partendo dalla PAGINA 3

45. Tre problemi principali
@giacomozecchini
Riassumendo, senza un’adeguata session
isolation i risultati prodotti:
● Hanno problemi di integrità
● Sono diversi da quelli prodotti dai principali
motori di ricerca
● Rendono difficile il debug dei problemi

46. Alcuni degli effetti per chi lavora nella SEO
@giacomozecchini
Le analisi si baseranno su dati sbagliati:
● Le analisi dei contenuti avranno dati
aggiuntivi
● Le analisi dei link interni avranno X% link
aggiuntivi
* I contenuti e link aggiuntivi non saranno visibili da Google & Co

47. Alcuni degli effetti per chi lavora nella SEO
@giacomozecchini
Tutto questo si traduce in:
● Analisi sbagliate
● Scelte errate
● Perdita di tempo e soldi

48. Questo problema non si limita ai Web Crawler
Questo problema è difficile da individuare ed
è bene far notare che può influenzare tutti quei
sistemi che utilizzano browser-based
software come Web Performance tool e
anche CI/CD pipelines.
@giacomozecchini

49. Se è un’opzione deve essere chiara
Ci sono alcuni casi dove mantenere dei dati in
memoria è necessario per completare dei test
o altro. In questi casi dovrebbe essere
un’opzione specificata molto chiaramente.
@giacomozecchini

50. Come risolvere il
problema
@giacomozecchini

51. Costruiamo un sistema di web rendering
@giacomozecchini
Poniamo il caso vogliate costruire un sistema
di web rendering senza problemi con la
session isolation.
Di seguito alcune soluzioni incorrette o
parziali e infine la soluzione ottimale.

52. Soluzione incorretta o parziale #1
@giacomozecchini
Pulire i Cookie del browser dopo il rendering
di ogni pagina. È una scelta pessima, non solo
i Cookie hanno accesso alla memoria del
Browser.

53. Soluzione incorretta o parziale #2
@giacomozecchini
Aprire e chiudere il browser per ogni singola
pagina e cancellare “manualmente” le cartelle
ed i file dove il browser salva i dati ad ogni
rendering. Rimuove i dati ma non è efficiente.

54. Soluzione incorretta o parziale #3
@giacomozecchini
Usare la modalità incognito. Finché rimane
aperta la modalità incognito le pagine
possono accedere alla memoria del browser e
può esserci comunicazione tra le varie tab. La
soluzione può funzionare solo se viene chiuso
e riaperto il browser per ogni pagina. Non è
efficiente, ricordate?

55. La soluzione ottimale è usare Browser Context
@giacomozecchini
Introdotto a BlinkOn 6, il Browser Context è un
modo efficiente per avere una corretta session
isolation. Ogni Browser Context è eseguito in
un renderer process separato, la memoria è
isolata (cookies, cache, local storage, etc.) e la
comunicazione cross-tab tra differenti
Browser Context non è possibile.

56. @giacomozecchini

57. Come utilizzare il Browser Context
@giacomozecchini
Aprire e chiudere un nuovo Browser Context
per ogni pagina di cui dobbiamo fare il
rendering. Questa procedura garantirà una
corretta session isolation.

58. Usare questa soluzione avrà un effetto
minimo sulle performance del web crawler.
La maggioranza degli utenti dei tool di web
crawling rinuncerebbero sicuramente a
qualche secondo per garantire l’integrità dei
dati.
Data integrity > Performance
@giacomozecchini

59. Documentazione tecnica
@giacomozecchini
● https://chromedevtools.github.io/devtools-protocol/
tot/Target/#method-createBrowserContext
● https://pptr.dev/next/api/puppeteer.browser.createi
ncognitobrowsercontext
● https://playwright.dev/docs/api/class-browserconte
xt

60. Test
@giacomozecchini

61. @giacomozecchini

62. Metodologia
@giacomozecchini
Per testare i web crawler abbiamo creato un
testing environment con 1000 pagine che
cercano di comunicare tra di loro accedendo
alla memoria del browser o tramite cross-tab
communication.

63. Perché 1000 pagine?
@giacomozecchini
Abbiamo utilizzato 1000 pagine per
massimizzare la possibilità di avere il
rendering di due o più pagine parallelamente.
Utilizzare meno pagine avrebbe potuto creare
falsi negativi.

64. Storage isolation
@giacomozecchini
I seguenti test si basano su Web API che
permettono il salvataggio e l’accesso a dati
salvati nella memoria del browser. Il goal dei
test è quello di capire se durante il rendering
di una pagina è possibile accedere a dei dati
salvati durante il rendering di altre pagine.

65. Test #1: Cookie
@giacomozecchini
https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie
I Cookie non hanno bisogno di presentazioni, permettono di salvare
informazioni nella memoria del browser.
Spiegazione test: ogni pagina crea e salva un cookie, poi cerca di
leggere se vengono salvati altri cookie nella memoria del browser
dalle altre pagine.
Il test fallisce se: la pagina riesce a leggere un cookie che non
proviene dalla pagina stessa.

66. Test #2: IndexedDB
@giacomozecchini
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
IndexedDB è un JavaScript-based object-oriented database che
permette di salvare e leggere informazioni nella memoria del browser.
Spiegazione test: ogni pagina crea o si connette al database e salva
un oggetto, poi cerca di leggere se vengono salvati altri oggetti nella
memoria del browser dalle altre pagine.
Il test fallisce se: la pagina riesce a leggere un oggetto che non
proviene dalla pagina stessa.

67. Test #3: LocalStorage
@giacomozecchini
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
LocalStorage permette di salvare e leggere key/value nella memoria
del browser.
Spiegazione test: ogni pagina salva un oggetto nella memoria, poi
cerca di leggere se vengono salvati altri oggetti nella memoria del
browser dalle altre pagine.
Il test fallisce se: la pagina riesce a leggere un oggetto che non
proviene dalla pagina stessa.

68. Test #4: SessionStorage
@giacomozecchini
https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
SessionStorage è come il LocalStorage ma i dati non persistono in
memoria e sono cancellati quando la sessione viene chiusa.
Spiegazione test: ogni pagina salva un oggetto nella memoria, poi
cerca di leggere se vengono salvati altri oggetti nella memoria del
browser dalle altre pagine.
Il test fallisce se: la pagina riesce a leggere un oggetto che non
proviene dalla pagina stessa.

69. Cross-tab communication
@giacomozecchini
I seguenti test si basano su Web API che
permettono l’invio e la ricezione di dati. Il goal
dei test è quello di capire se durante il
rendering di una pagina sono stati ricevuti dei
messaggi da altre pagine.

70. Test #5: Broadcast Channel
@giacomozecchini
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API
Broadcast Channel permette l’invio e la ricezione di messaggi
attraverso un “channel” che può connettere finestre, tab, iframe, etc.
Spiegazione test: ogni pagina si connette al channel e invia un
messaggio, poi aspetta di ricevere messaggi provenienti dalle altre
pagine.
Il test fallisce se: la pagina riceve un messaggio che proviene dalle
altre pagine.

71. Test #6: Shared Worker
@giacomozecchini
https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker
Shared Worker permette l’invio e la ricezione di messaggi attraverso
lo stesso worker che può connettere finestre, tab, iframe, etc.
Spiegazione test: ogni pagina si connette allo Shared Worker e invia
un messaggio, poi aspetta di ricevere messaggi provenienti dalle altre
pagine.
Il test fallisce se: la pagina riceve un messaggio che proviene dalle
altre pagine.

72. @giacomozecchini
Test Risultati
Cookie Il 29% dei tool ha fallito il test
IndexedDB Il 64% dei tool ha fallito il test
LocalStorage Il 71% dei tool ha fallito il test
SessionStorage Il 21% dei tool ha fallito il test
Broadcast Channel Il 14% dei tool ha fallito il test
Shared Worker Il 14% dei tool ha fallito il test
Il 71% dei tool ha fallito almeno uno dei test.

73. GitHub link
@giacomozecchini
Potete replicare l’ambiente di
test utilizzando il codice
pubblicato su GitHub:
https://github.com/merj/test-
crawl-session-isolation

74. Conclusioni
@giacomozecchini

75. Non cancellate i dati manualmente!
@giacomozecchini
Un web crawler potrebbe passare tutti i test di
questa ricerca cancellando manualmente i
dati della memoria del browser alla fine del
rendering di ogni pagina, questo approccio è
pericoloso e non garantisce l’integrità dei
dati.

76. Utilizzare scorciatoie non è lungimirante
@giacomozecchini
Le Web API incluse nella ricerca non sono le
uniche che hanno accesso alla memoria del
browser o che permettono comunicazione
cross-tab. Cercare di aggiungere tutte le
nuove Web API alla lista dei dati da cancellare
è un processo complesso e molto
dispendioso in termini di tempo.

77. Migliorare la qualità del web crawling!
@giacomozecchini
Le risposte dei vendor sono state molto trasparenti ed alcuni di
loro ci hanno incluso nell’intero processo di correzione dei
problemi.
Siamo soddisfatti che il nostro obiettivo di migliorare la qualità
di web crawling dell’industria sia stato compreso.

78. @giacomozecchini
Web Crawler Status
Ahrefs Ha corretto i problemi - 15 Novembre 2022
Botify Ha passato tutti i test
ContentKing Ha corretto i problemi - 27 Ottobre 2022
FandangoSEO Ricerca inviata, in corso di verifica da parte del tool
JetOctopus Ricerca inviata, in corso di verifica da parte del tool
Lumar (formerly Deepcrawl) Ha passato tutti i test
Netpeak Spider Ricerca inviata, in corso di verifica da parte del tool
OnCrawl Ha passato tutti i test
Ryte Ha corretto i problemi - 10 Ottobre 2022
Screaming Frog Ha corretto i problemi - 17 Agosto 2022
SEO PowerSuite WebSite Auditor Ricerca inviata, in corso di verifica da parte del tool
SEOClarity Ricerca inviata, in corso di verifica da parte del tool
Sistrix Ha passato tutti i test
Sitebulb Ricerca inviata, in corso di verifica da parte del tool
Tabella aggiornata al: 15/11/2022

79. Considerazioni finali
@giacomozecchini
● Il rendering è un argomento
complesso
● La validazione dei dati è uno
step cruciale

80. Blog
Abbiamo pubblicato la ricerca
sul blog con tutti i dettagli:
https://merj.com/blog/validat
ing-session-isolation-for-web-
crawling-to-provide-data-integ
rity
@giacomozecchini

81. Grazie!
Domande? Mi trovate su Twitter, i DM
sono aperti: @giacomozecchini
slideshare.com/giacomozecchini
speakerdeck.com/giacomozecchini
@giacomozecchini