Il documento illustra un processo di ottimizzazione del front-end di un e-commerce basato su Magento 2, con un focus particolare sulle prestazioni mobili. Vengono presentate diverse tecniche di miglioramento, come la compressione dei file, l'ottimizzazione delle immagini e l'uso di HTTP/2, per migliorare la velocità e l'interattività del sito. Inoltre, si enfatizza l'importanza della velocità per SEO e pubblicità, suggerendo strumenti e metodi per monitorare e migliorare le prestazioni.

1. Ottimizzazione step-by-step
del front-end di un
e-commerce
Francesco Terenzani – 10 maggio 2019
WPO
#seriousmonkeyfrancesco.terenzani@smartguys.it

2. Cioè?
Ho preso una installazione «base» di Magento2.
Mi sono accorto che faceva schifo in termini di
performance, soprattutto da mobile.
Ti faccio vedere come l’ho ottimizzata per renderla
più veloce e fare più soldi.
2

3. Il focus è sul mobile.
AMP rimane la soluzione più veloce, ma
attualmente è forse ancora troppo rigida per l’e-
commerce.
3

4. Chi sono
• Ex web developer
• Consulente SEO in agenzia
dal 2007
• Consulente freelance da circa
un 1 mese :-)
4

5. Ottimizzazioni
di partenza
• Server ottimizzato
per Magento2
• HTTP/2
• Compressione Brotli
• Minificazione e
concatenazione file
JavaScript e CSS
• Caching lato server
e HTTP
5

6. Dicevamo… focus sul mobile
Test con connessione simulata «Fast 3G».
Strumenti per audit e simulazioni:
6
LIGHTHOUSE GOOGLE PAGESPEED
INSIGHT
=
WEB PAGE TEST

7. Perché connessione Fast 3G
È la connessione simulata da Google PageSpeed e che
dovrebbe rappresentare circa il 25% delle connessioni
3G più veloci e il 25% delle 4G più lente.
7
1.6 Mbps
DOWNLOAD
750 Kbps
UPLOAD
150 Ms
LATENZA

8. 8
In Lighthose
selezionando
«Applied Fast
3G» si hanno
risultati più
simili a Google
Pagespeed

9. Le velocità delle connessioni in Italia sono
mediamente migliori
9
Fonte: https://www.opensignal.com/reports/2018/10/italy/mobile-networks-update
Google Page Speed

10. FYI
10
Lighthose può essere installato e lanciato da riga
di comando, permettendo una configurazione più
precisa degli audit e una più facile automazione.
https://github.com/GoogleChrome/lighthouse
lighthouse --throttling.throughputKbps=11000 --throttling.requestLatencyMs=150 --
throttling.downloadThroughputKbps=11000 --throttling.uploadThroughputKbps=750
https://example.com

11. Partiamo dalla fine: i risultati
delle ottimizzazioni
11

12. PRIMA DOPO
12
Simulazione connessione 3G con WebPageTest.org
Painting in <3s

13. Una nota sulle metriche
13
Metriche legate al painting (velocità percepita)

14. Speed Index formula
14
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

15. Una nota sulle metriche
15
Metriche legate all’interattività

16. Una nota sulle metriche
16
Metrica legate alla lunghezza delle performance (ottima
per confronti tra competitors)

17. Primo audit con Lighthouse
17

18. Analisi delle richieste con Chrome
DevTools > Network (Fast 3G)
18
1.4 MB e 14.47
secondi?! :O

19. Rimuoviamo qualche “ottimizzazione” di
Magento
19

20. Effetti della modifica
20
30 -> 200
RICHIESTE HTTP
2MB -> 1MB
TRASFERITI

21. Impatto sulle performance
21

22. Perché non utilizzare quelle impostazioni
HTTP/1.1:
• Una connessione per ogni
richiesta HTTP e un numero
limitato di richieste in parallelo
• Concatenare i file per ridurre
le richieste
• Usare diversi domini per
parallelizzare i download
• Servire contenuti statici da
domini senza cookie
HTTP/2 supera alcuni limiti del
protocollo:
• Tutte le richieste passano dalla
stessa connessione con il server
(Multiplexing), il numero di
richieste in parallelo non sono
un problema
• Header compression
22

23. Per sfruttare HTTP/2 meglio più richieste
asincrone
Caricare file JavaScript in modo asincrono
23
defer, async requireJS
(come funziona Magento2 non “ottimizzato”)

24. Cerchiamo di migliorare l’interattività
24

25. Dobbiamo ridurre la quantità di
JavaScript
25

26. Dobbiamo ridurre la quantità di
JavaScript
26

27. Dobbiamo ridurre la quantità di
JavaScript
È un lavoro sporco:
• Rimuovere codice non utilizzato
• Rinunciare a funzionalità poco utilizzate
27

28. Risultato
28

29. Ottimizzazioni facili con alto
impatto per l’e-commerce: le
immagini
29

30. LazyLoading
30
Modulo per Magento2
https://www.weltpixel.com/magento-2-lazy-load-product-extension.html
Per ogni altro CMS
https://www.google.it

31. Verificare che il LazyLoading sia
Googlebot Friendly
1. Installare Node.js
https://nodejs.org/en/
2. Installare Puppeteer (Chrome + Web
DevTools da riga di comando)
https://github.com/GoogleChrome/puppeteer
3. Eseguire lo script
https://github.com/GoogleChromeLabs/puppeteer-
examples/blob/master/lazyimages_without_scroll_events.js
31
Non sempre Googlebot supporta il LazyLoading dei
contenuti. Per esserne “quasi” sicuri:
npm install puppeteer
node lazyimages_without_scroll_events.js
--url=https://example.com/
--output=results.html

32. 32

33. Compressione immagini senza perdita di
qualità
33
Ottimizzazione di tutte le immagini di Magento (o
di qualsiasi altro CMS/sito web).
find pub/media -type f -name "*.jpg" -exec jpegoptim --strip-all --all-progressive {} ;
find pub/media -type f -name "*.png" -exec optipng -o7 {} ;
Ottimizzare JPG
con jpegoptim
Ottimizzare JPG
con optipng

34. Ottimizzazioni dei CSS
34

35. Individuare regole non utilizzate con
Chrome
35

36. Individuare regole non utilizzate con
Chrome
36
Il 75-90% delle
regole non sono
utilizzate

37. Obiettivo
• Creare un CSS con le regole strettamente necessarie per ogni
tipologia di pagina:
• home.css
• category.css
• product.css
• Ad ogni pagina applicare lo specifico CSS e salvare in cache i
CSS per le altre pagine.
37

38. Come estrarre le regole per
ogni pagina?
38

39. 39
Con un tool
online
https://uncss-online.com/

40. 40
Con una libreria di
Node.js
https://github.com/GoogleChrome/puppeteer
https://github.com/peterbe/minimalcss

41. C’è un problema
Quando l’utente interagisce con un sito, JavaScript
può modificare il DOM.
Questi strumenti rimuovono anche i CSS relativi al
DOM modificato.
41

42. 42
Si può usare un libreria di
Node.js maggiormente
configurabile
https://gruntjs.com/
https://github.com/uncss/grunt-uncss

43. 43
Long story short:
Ogni pagina
include un suo
CSS ridotto del
90%

44. Pre-caching
44
Link da aggiungere nell’HEAD o come intestazione
HTTP:
In alternativa via JavaScript con i Service Workers
https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker

45. 45
https://github.com/filamentgroup/loadCSS
(Opzionale) Caricare in modo asincrono il
CSS completo

46. Ridotto al minimo il codice
CSS e JavaScript «critico»,
velocizziamone il caricamento
46

47. HTTP/1.1
• Inserimento “inline” nell’HTML
di CSS e JavaScript sincroni
HTTP/2
• HTTP/2 Server Push (può
potenzialmente sfruttare la
cache del browser)
47

48. HTTP/2 Server Push per Magento2
Modulo Yireo_LinkPreload:
https://github.com/yireo/Yireo_LinkPreload
(consiglio di modificarlo per evitare il push delle immagini)
48

49. Qualcosa sui font
49

50. Come si comportano i browser per
l’inclusione di font esterno
50
Testo invisibile
Testo con font
di fallback
Re-rendering
del testo
PRIMA DEL
CARICAMENTO
DEL FONT
SE IL FONT
RITARDA
QUANDO IL FONT
VIENE CARICATO
IE/Edge

51. https://developers.google.com/web/updates/2016/02/font-display
51
Per font locali si può usare font-display

52. In alternativa: usare font di sistema «belli»
52
https://getbootstrap.com/docs/4.0/content/reboot/#native-font-stack
Utilizzare un elenco di
font di sistema di diversi
dispositive e sistemi
(Native font stack)
Metodo utilizzato in
Bootstrap 4.

53. PRIMA DOPO
53
Windows 10
Open Sans vs Segoe UI

54. PRIMA DOPO
54
Android
Open Sans vs Roboto

55. Tag di terze parti (tracking, remarketing,
Ads,…)
Problema: Creano richieste verso domini non presenti nel codice
HTML inizialmente analizzato dal browser.
Per ridurre il problema: consigliare al browser di preconnettersi
utilizzando il seguente tag nell’HEAD del documento (o come
HEADER HTTP):
55
<link href="https://cdn.domain.com" rel="preconnect" crossorigin>

56. Individuare richieste di terze parti da
ottimizzare
56
Dominio e Initiator diversi dalla pagina
analizzata? Abbiamo un problema

57. Risultato finale
57

58. Soldi potenzialmente guadagnati
58
https://www.thinkwithgoogle.com/intl/it-it/feature/testmysite

59. Altri benefici
59

60. Visibilità SEO
• Segnale di ranking per ricerche desktop dal 2010:
https://webmasters.googleblog.com/2010/04/using-site-speed-
in-web-search-ranking.html
• … e per le ricerche mobile dal 2018
https://webmasters.googleblog.com/2018/01/using-page-
speed-in-mobile-search.html
60

61. Sempre più attenzione anche in Google
Ads
• Dal 2018 è stato introdotto il Mobile Speed Score in Google
Ads: https://support.google.com/google-ads/answer/9069088
• Nel 2019 è stato aggiornato l’algoritmo per fornire dati su un
numero maggiore di landing pages:
https://support.google.com/google-ads/answer/9238823
61

62. Risparmio banda per CDN e servizi a
consumo
62

63. Key takeaways
• Caricare JS asincrono
• Ridurre al minimo codice non utilizzato (JS e CSS)
• LazyLoading e ottimizzazione delle immagini
• Ottimizzare i tag di terze parti
• Valutare l’utilizzo di font di sistema
• Valutare l’utilizzo di AMP:
https://marketplace.magento.com/plumrocket-module-pramp.html
(modulo per Magento2)
63

64. Grazie
#seriousmonkeyfrancesco.terenzani@smartguys.it