Microsoft Sway lento o bloccato su Chrome/Edge: cause 2024, soluzioni e playbook

Da fine giugno 2024 molti tenant Microsoft 365 hanno riscontrato gravi rallentamenti di Microsoft Sway: caricamenti infiniti, embed bloccati su browser Chromium, funzionamento migliore su Firefox. Qui trovi diagnosi, cause note, workaround e un playbook operativo.

Indice

Cos’è successo: contesto e quadro sintetico

A partire dagli ultimi giorni di giugno 2024 numerosi utenti hanno segnalato che Microsoft Sway:

rimane in caricamento indefinitamente oppure si apre solo dopo lunghi tempi di attesa, sia in fase di creazione/modifica, sia durante la lettura;
non visualizza correttamente gli embed Sway incorporati in siti e intranet (con maggiore evidenza su Chrome, Edge e Opera);
continua invece a funzionare in modo più affidabile su Firefox e, in alcuni casi, su dispositivi mobili;
risulta impattato anche quando il contenuto è pubblico (“Anyone with the link”).

Il Service Health Dashboard (SHD) di Microsoft ha esposto due incidenti ravvicinati:

SW806219 (28 giugno 2024): “Some users may experience slowness and intermittent issues in loading the Sway service”.
SW807143 (1 luglio 2024): “Some users may experience slowness or intermittent issues loading the Sway service”.

In entrambi i casi Microsoft ha indicato un problema su una porzione dell’infrastruttura e un’analisi di telemetria in corso per isolare la causa e distribuire una correzione. Lo SHD ha poi segnalato risoluzione il 2 luglio 2024 alle 12:25 AM GMT+8, ma varie segnalazioni hanno evidenziato perdurare dei sintomi per alcuni tenant e in determinati point of presence o percorsi di rete. Episodi sporadici di lentezza sono riemersi in settembre 2024.

Sintomi e pattern ricorrenti

Scenario	Comportamento osservato	Impatto per l’utente
Apertura Sway dal portale	Schermata di caricamento che persiste per minuti o non si completa	Impossibile creare o modificare contenuti
Visualizzazione link pubblico (Anyone with the link)	Pagina bianca, spinner infinito, blocco parziale delle sezioni	Comunicazioni esterne non fruibili
Embed in siti/intranet (iframe)	L’iframe non si inizializza o resta vuoto, soprattutto su browser basati su Chromium	Portali aziendali e pagine prodotto “rotte”
Browser e device	Firefox e mobile più affidabili; Chrome/Edge/Opera più impattati	Esperienza incoerente tra utenti e dispositivi

Cause identificate e possibili fattori concorrenti

Incidenti lato servizio

Gli ID SW806219 e SW807143 confermano che si è trattato primariamente di incidenti lato Microsoft Sway. Il fornitore ha indicato analisi della telemetria e rilascio di correzioni per normalizzare le latenze e gli errori di inizializzazione del servizio.

Risoluzione dichiarata e impatto residuo

Nonostante la chiusura ufficiale degli incidenti il 2 luglio 2024, molte organizzazioni hanno riportato un ripristino non uniforme, suggerendo:

ambito geografico non omogeneo (alcuni PoP o percorsi CDN più lenti o non aggiornati);
residui di cache o configurazioni locali che amplificano gli effetti (ma non li causano);
fault indipendenti o regressioni sporadiche riemerse a distanza di settimane.

È importante distinguere tra cause primarie (servizio Sway) e fattori aggravanti lato client/rete, utili solo a spiegare perché alcuni utenti risultassero maggiormente impattati.

Azioni consigliate per ruolo

Ruolo	Azione	Dettagli
Utente finale	Provare Firefox o un dispositivo mobile	In molte segnalazioni Firefox si è dimostrato il percorso più affidabile durante i picchi di degrado.
Utente finale	Verificare reti e cache	Aprire una sessione InPrivate/Incognito; disattivare estensioni; svuotare cache DNS. Serve a escludere concause locali.
Amministratore M365	Controllare lo Service Health Dashboard	Verificare se il tenant è interessato da incidenti correnti su Sway e seguirne gli aggiornamenti.
Amministratore M365	Aprire un ticket a Microsoft	Se lo SHD non segnala più anomalie ma i sintomi persistono, segnalare come problema residuo circoscritto allegando telemetria del tenant.
Sviluppatore web	Implementare fallback per gli embed	Aggiungere messaggi di stato, link alternativi o immagini statiche qualora l’iframe non si carichi entro un timeout ragionevole.

Checklist immediata per utenti e help‑desk

Riprovare su Firefox o su un device mobile.
Aprire una finestra InPrivate/Incognito, disattivare temporaneamente le estensioni, svuotare cache e cookie del solo dominio di Sway.
Svuotare la cache DNS e rinnovare il lease IP:
- Windows: aprire Prompt dei comandi come amministratore ed eseguire:
  ipconfig /flushdns ipconfig /release ipconfig /renew
- macOS: in Terminale eseguire:
  sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
- Linux (NetworkManager):
  sudo resolvectl flush-caches sudo systemctl restart NetworkManager
Provare una rete alternativa (hotspot mobile vs rete aziendale) per escludere filtri o proxy.
Se l’embed non si carica: cliccare Apri in nuova scheda (se disponibile) oppure richiedere un link diretto al contenuto.

Diagnostica avanzata per amministratori

Raccolta log e telemetria

HAR di rete (Chrome/Edge): F12 → Network → Preserve log → Clear, riprodurre l’errore, quindi Export HAR.
Console: copiare errori JavaScript o di sicurezza (CSP, CORS, Mixed Content).
Traceroute verso i domini di Sway dal PC dell’utente e dal perimetro (proxy/firewall): :: Windows tracert sway.office.com macOS / Linux traceroute sway.office.com
Confronto A/B: stesso Sway, stessa rete, due browser (Firefox vs Chrome). Annotare differenze di latenza e codici HTTP.
Orari e fusi: registrare timestamp con fuso orario locale e UTC per facilitare la correlazione con gli eventi del servizio.

Elementi da includere nel ticket Microsoft

Tenant ID (GUID) e area geografica del tenant.
URL/ID degli Sway affetti (almeno 3 esempi), orari di riproduzione e rete utilizzata.
HAR + screenshot della Network waterfall con chiamate lente/fallite.
Risultati dei traceroute da più location.
Eventuali correlation ID restituiti dal servizio o presentati nei messaggi di errore.

Mitigazioni per gli embed Sway su siti e intranet

Finché la stabilità non è garantita al 100%, è opportuno progettare gli embed con logiche di progressive enhancement e fallback. Di seguito alcuni pattern collaudati.

Fallback con timeout e messaggio d’emergenza

<figure class="sway-embed">
  <iframe
    id="swayFrame"
    title="Presentazione Sway"
    src="https://sway.office.com/{ID}?ref=embed"
    loading="lazy"
    sandbox="allow-scripts allow-same-origin allow-popups"
    referrerpolicy="no-referrer-when-downgrade"
    onload="window.dispatchEvent(new Event('sway:loaded'))"
  ></iframe>
  <div id="swayFallback" hidden>
    <p>Il contenuto Sway non si è caricato nei tempi previsti.</p>
    <p>Prova ad aprirlo in una nuova scheda o consulta la versione alternativa (PDF/HTML).</p>
  </div>
</figure>

Scheletro di caricamento e alternative

<style>
.sway-embed { position: relative; min-height: 480px; }
.sway-embed .skeleton {
  position:absolute; inset:0; animation:pulse 1.2s infinite ease-in-out;
}
@keyframes pulse { 0%{opacity:.5} 50%{opacity:.8} 100%{opacity:.5} }
</style>


[https://sway.office.com/{ID}?ref=embed](https://sway.office.com/{ID}?ref=embed)

Se il tuo CMS lo consente, pubblica accanto all’embed una versione statica (immagine, PDF o HTML semplificato) generata dai contenuti originali, così da mantenere la comunicazione anche in caso di fermo prolungato.

Validazione preventiva dell’embed

Prima di pubblicare una pagina con Sway, testa il caricamento su Firefox, Chrome, Edge, reti aziendali e reti mobili. Imposta una soglia di accettazione (es. TTI < 5 s) e rimanda la pubblicazione se la pagina non la soddisfa.

Piano B per la comunicazione: soluzioni pratiche

Newsletter/annunci: prepara in anticipo una release alternativa in PDF/HTML da pubblicare su SharePoint o inviare via e‑mail.
Eventi/riunioni: salva copie offline (PDF o screenshot) dei contenuti critici per l’erogazione senza rete.
Tracciabilità: indica nella pagina una data di ultimo aggiornamento e il canale alternativo in caso di problemi.

Perché alcuni browser risultavano meno impattati

Durante gli incidenti, molti hanno riferito di una migliore riuscita del caricamento con Firefox. Questo non implica un problema intrinseco dei browser Chromium: più probabilmente riflette differenze nella gestione della pipeline di rete, del preloading, delle politiche di timing out o dei percorsi CDN. In ogni caso, usare Firefox come “via di fuga” si è dimostrato un workaround efficace per garantire la continuità operativa.

Flusso decisionale di troubleshooting

Isola il fattore locale: InPrivate, estensioni off, cache DNS e rete alternativa.
Conferma lato servizio: controlla lo SHD per Sway (incidenti correnti o appena chiusi).
Ripristino operativo: in emergenza usa Firefox o mobile e attiva i fallback sugli embed.
Telemetria: raccogli HAR, traceroute e screenshot.
Escalation: apri un ticket se il disservizio persiste > 2 ore senza indicazioni sullo SHD.
Verifica post‑ripristino: riesegui test incrociati su più browser/reti e aggiorna gli stakeholder.

Template per la richiesta di supporto

Oggetto: Sway - lentezza/caricamento intermittente su tenant <NOME> (dal <DATA ORA TZ>)

Sintesi: dall’ utenti in  segnalano caricamenti infiniti o embed vuoti su Chrome/Edge/Opera.
SHD: nessun incidente attivo (ultimo noto: SW806219 / SW807143). Persistono impatti residui.

Esempi:

- URL/ID Sway #1
- URL/ID Sway #2
- URL/ID Sway #3

Allegati: HAR, traceroute, screenshot console, differenze tra Firefox e Chrome.
Richiesta: verifica telemetria del tenant, eventuale rerouting su PoP alternativo e indicazioni ETA.

Test matrix per la convalida post‑ripristino

Test	Firefox	Chrome	Edge	Opera	Mobile	Esito / Note
Apertura editor Sway	OK	—	—	—	OK	TTI < 5 s target
Link pubblico	OK	—	—	—	OK	Verifica first contentful paint
Embed in portale	OK	—	—	—	N/A	Controllo fallback a 8 s

Stato e cronologia consolidata

2 luglio 2024: Microsoft dichiara risolti gli incidenti.
1–4 luglio 2024: persistono segnalazioni di problemi; i moderatori invitano a monitorare lo SHD o ad aprire ticket per casi residui.
Settembre 2024: segnalati episodi isolati di lentezza o caricamenti bloccati.

Raccomandazioni operative (pronte all’uso)

Verifica continua: controlla quotidianamente lo SHD; gli ID degli incidenti cambiano.
Escalation rapida: se il servizio è inutilizzabile per oltre 2 ore senza indicazioni sullo SHD, apri un ticket allegando HAR e traceroute.
Piano B: mantieni una versione PDF/HTML dei contenuti critici, pubblicabile rapidamente su SharePoint o inviabile via e‑mail.
Monitoraggio post‑ripristino: testa gli Sway prioritari su più browser e reti prima di dichiarare chiuso l’incidente.
Feedback strutturato: usa i canali ufficiali (Feedback Hub/strumenti Microsoft) per segnalare regressioni o problemi sugli embed Chromium‑based.
Progettazione resiliente: implementa fallback, skeleton loader e link alternativi negli embed.
Comunicazione interna: definisci un modello di messaggio per informare tempestivamente utenti e stakeholder su stato, workaround e ETA.

FAQ

Il problema è della mia rete o di Microsoft Sway?

Gli incidenti del 28 giugno e 1 luglio 2024 indicano un’origine lato servizio. Le verifiche locali (cache, estensioni, rete) restano utili per evitare che concause amplifichino il disservizio.

Perché Firefox funziona meglio?

Durante i picchi di degrado, in molti casi il caricamento su Firefox riusciva più spesso. È un buon workaround operativo, non una soluzione definitiva.

Gli Sway pubblici “Anyone with the link” sono sicuri?

Sì, ma quando il servizio è degradato anche i link pubblici possono risultare lenti o bloccati. Prevedi sempre una versione alternativa consultabile.

Come posso capire se il problema è rientrato per il mio tenant?

Verifica lo SHD, poi esegui la test matrix su browser e reti. Se tutti i test superano la soglia di accettazione, puoi considerare il ripristino end‑to‑end.

Serve aggiornare le regole del firewall/proxy?

In generale no, ma è buona pratica verificare che i domini di Sway e Microsoft 365 non siano filtrati o ritardati (ispezione TLS, rate limiting, limiti di dimensione, ecc.).

In sintesi

Il periodo di instabilità di Microsoft Sway tra fine giugno e inizio luglio 2024 è stato causato da incidenti lato servizio (SW806219 e SW807143). Nonostante la chiusura ufficiale il 2 luglio 2024, alcuni tenant e percorsi di rete hanno patito effetti residui, con particolare impatto sugli embed in browser Chromium‑based. Le azioni più efficaci risultano: monitoraggio continuo dello SHD, apertura di ticket quando necessario, uso di Firefox come ripiego operativo, adozione di fallback per gli embed e predisposizione di un Piano B (PDF/HTML) per contenuti critici. Seguendo il playbook di diagnosi ed escalation qui proposto, le organizzazioni possono ridurre drasticamente i tempi di disservizio percepito e migliorare la resilienza delle proprie comunicazioni digitali.

Riepilogo operativo “da incollare”

Quando Sway è lento o bloccato: prova Firefox/mobile, InPrivate, svuota cache DNS, rete alternativa.
Se persiste > 2 ore: controlla SHD e apri ticket con HAR, traceroute, esempi URL/ID.
Per i siti: usa fallback e link alternativi negli embed; prepara copie statiche.
Dopo la risoluzione: riesegui test incrociati e aggiorna gli stakeholder.