Quali dimensioni del browser bisogna testare per il responsive design?

Non esiste un elenco definitivo di dimensioni del browser che garantisca un design responsive. Parti da larghezze di riferimento ridotte, intermedie e ampie, come 390, 820 e 1440 pixel CSS, poi prova valori immediatamente inferiori e superiori a ogni breakpoint in cui cambia la disposizione dei tuoi contenuti. Il breakpoint migliore è dove il layout inizia a non funzionare, non dove termina la larghezza di un particolare modello di telefono.

Il test di rendering dei siti web di ClockTools può acquisire una pagina pubblica alle dimensioni di riferimento per mobile, tablet e desktop, verificando anche i metadati della pagina. Usalo per un rapido controllo visivo, poi interagisci con la pagina negli strumenti per sviluppatori del browser e su dispositivi reali rappresentativi prima del rilascio.

Perché tre screenshot non equivalgono a tre dispositivi?

Il viewport CSS è l'area disponibile per i contenuti web, misurata in pixel CSS. Non coincide semplicemente con il numero di pixel fisici riportato nelle specifiche del dispositivo. Zoom, rapporto tra pixel del dispositivo e pixel CSS, controlli del browser, finestre a schermo diviso, barre di scorrimento e orientamento possono tutti modificare il viewport disponibile.

Ecco perché un elenco delle «dimensioni dei telefoni più diffusi» diventa obsoleto. La guida di MDN al responsive design consiglia layout che si adattino all'intero intervallo disponibile, mentre la sua introduzione alle media query suggerisce di aggiungere un breakpoint dove i contenuti iniziano a presentare problemi di impaginazione, anziché puntare a ogni singolo dispositivo.

Tre screenshot restano comunque utili. Sono rapidi punti di riferimento che fanno emergere grandi differenze nella navigazione, nelle colonne, nelle tabelle e nella tipografia. Considerali un primo controllo lungo un intervallo di larghezze, non la prova che tutte funzionino.

Che cosa rivela ogni viewport di ClockTools?

Lo strumento di ClockTools offre tre acquisizioni selezionabili in modo indipendente:

Il risultato riporta anche stato della risposta, titolo, H1, URL canonico, valore robots, dimensione dell'HTML e tempi di risposta. Questa combinazione è utile perché un bello screenshot di una pagina reindirizzata, bloccata, noindex o con un URL canonico errato non basta a superare la verifica prima del rilascio.

Il motore di rendering accetta pagine HTTP o HTTPS pubbliche. Rifiuta intenzionalmente localhost, indirizzi IP privati e pagine di reti interne, perché la richiesta di acquisizione viene eseguita all'esterno del tuo dispositivo. Non inviare link di anteprima firmati, password, token o URL riservati di ambienti di staging.

Come organizzare una verifica dei breakpoint?

Procedi in cinque passaggi, anziché raccogliere un'enorme matrice di dispositivi:

1. Inizia con una larghezza ridotta di 320 o 360 pixel per far emergere le assunzioni sulla larghezza minima.
2. Acquisisci una dimensione mobile comune, come 390 pixel, e verifica le interazioni in orientamento verticale.
3. Aumenta lentamente la larghezza finché i contenuti stessi non richiedono un cambiamento di layout; annota quel valore.
4. Prova un pixel sotto e un pixel sopra ogni breakpoint dichiarato, poi ripeti con etichette lunghe, errori di validazione e menu aperti.
5. Concludi con una larghezza desktop ampia, come 1440 pixel, e una finestra ancora più larga, per individuare righe di lunghezza incontrollata o contenuti multimediali deformati.

Per un foglio di stile che cambia a 768 pixel, la coppia più utile è 767 e 768, non soltanto una generica preimpostazione tablet. Se un'altra griglia cambia a 1024, aggiungi 1023 e 1024. Questi valori al limite rivelano intervalli scoperti di un pixel e regole min/max sovrapposte.

Considera anche l'altezza quando un'intestazione fissa durante lo scorrimento, una finestra modale, un banner di consenso o una tastiera su schermo possono occupare spazio verticale. Ruota almeno un dispositivo touch o un simulatore. Un layout che funziona a 390 x 844 può comunque presentare problemi alla stessa larghezza se l'altezza disponibile è molto minore.

Quali problemi responsive correggere per primi?

Stabilisci le priorità in base alla possibilità per l'utente di completare l'attività principale della pagina:

Il documento esplicativo WCAG sul reflow spiega perché, a larghezze ridotte, i contenuti dovrebbero ridisporsi senza richiedere lo scorrimento in due direzioni, con eccezioni limitate per contenuti come mappe o tabelle di dati che necessitano davvero di due dimensioni.

Verifica stati realistici dei contenuti. Sostituisci i segnaposto brevi con l'etichetta più lunga supportata, mostra gli errori sotto i campi, apri la navigazione, espandi i pannelli a fisarmonica e carica la riga di tabella più grande plausibile. I problemi responsive emergono spesso dopo un'interazione, non nello screenshot iniziale privo di errori.

Quando serve un dispositivo reale?

Usa hardware reale quando il funzionamento dipende dal tocco, dalla tastiera su schermo, dai margini delle aree sicure, dalle autorizzazioni per fotocamera o posizione, dall'audio, dalla rotazione, dalle impostazioni di riduzione del movimento, dai controlli del browser mobile o dalle prestazioni su un dispositivo con risorse limitate. Un'acquisizione con browser headless non può riprodurre ogni metodo di input e comportamento del sistema operativo.

Prova la pagina anche con lo zoom del browser e il testo ingrandito. Un layout può rientrare nel viewport nominale e tuttavia tagliare i contenuti quando il testo cresce. Lo strumento di editing HTML in tempo reale è utile per isolare un esperimento CSS, mentre lo strumento di confronto dei testi può confermare esattamente quali modifiche alle regole responsive distinguono due versioni.

Una documentazione pratica del rilascio consiste in una piccola matrice: larghezza e altezza verificate, stato dei contenuti, browser o motore, problema osservato e risultato dopo la correzione. Queste evidenze restano utili più a lungo di una cartella di screenshot nominati soltanto con i marchi dei dispositivi.