Scopri Chrome Dev Insider

Ben Galbraith

Gli sviluppatori spesso ci dicono che è difficile stare al passo con i cambiamenti sul web e capirne il motivo. Oggi diamo il via a una nuova serie chiamata Chrome Dev Insider in cui condivideremo (1) Cosa è interessante e interessante, (2) Un approfondimento su come abbiamo preso una decisione su un argomento chiave (ad esempio cambiare FLOC) o affrontare il nostro lavoro con l'ecosistema (ad esempio Interop 2022) e (3) eventuali cambiamenti davvero importanti delle stringhe dello user agent.

Durante la pianificazione delle nostre roadmap, prendiamo in considerazione il feedback degli sviluppatori per comprendere, tra le altre cose, i principali punti dolenti e le loro esigenze. Un tema fondamentale che viene mostrato ripetutamente è la compatibilità dei browser, che garantisce che l'esperienza funzioni allo stesso modo su tutti i browser. Nell'ultimo anno abbiamo collaborato con l'ecosistema per affrontare questo tema nell'ambito della nostra priorità "semplificare lo sviluppo web".

L'anno scorso, Microsoft, Chrome e i giocatori dell'ecosistema hanno annunciato Compat 2021 che ha portato tutti i motori dei browser più diffusi (Chromium, Gecko e Webkit) a raggiungere un punteggio superiore al 90% nelle cinque aree di interesse principali identificate nell'anno. Tra le altre cose, Compat 2021 ha portato a creare una solida base per funzionalità potenti come CSS Grid (12% di utilizzo e in costante crescita) e CSS Flexbox (77% di utilizzo).

Il mese scorso Apple, Bocoup, Google, Igalia, Microsoft e Mozilla hanno collaborato come sostenitori per risolvere i principali problemi di compatibilità dei browser identificati dagli sviluppatori web e concordare un benchmark comune. Il risultato è Interop 2022, un progetto con l'obiettivo di rendere più omogenea la piattaforma. Il benchmark si concentra su 15 aree prioritarie identificate dagli sviluppatori come fondamentali per migliorare la loro produttività.

Scoop degli addetti ai lavori: collaborare con i nostri colleghi browser

Nell'ottica di un'importante priorità per il 2022, ho incontrato Robert Nyman e Philip Jägenstedt, che sono stati coinvolti in queste conversazioni per raccontare la storia interna. Ecco una panoramica della redazione.

Qual è l'origine di questa iniziativa?

Robert: Tutto è iniziato nel 2019, con il sondaggio MDN DNA 2019. I problemi di compatibilità si sono distinti chiaramente come il problema principale per gli sviluppatori di soluzioni per il web, pertanto abbiamo esaminato in modo molto più dettagliato il MDN Browser Compatibility Report 2020. Questi dati ci hanno fornito informazioni sufficienti e dati strategici per dare inizio all'impegno di Compat 2021, che a sua volta ha portato a proseguire questo lavoro e anche ad ampliare l'ambito di azione con Interoperabilità 2022.

Philip: Vorrei anche menzionare web-platform-tests e State of CSS 2021. Abbiamo avuto negli anni una solida collaborazione con altri fornitori di browser per i test utilizzando WPT e volevamo davvero fare affidamento su questo aspetto. I test per queste funzionalità erano per lo più già scritti, quindi dovevamo solo rivedere i test e aggiungere qualche copertura mancante. Google ha investito molto in wpt.fyi, ma dobbiamo ringraziare anche Mozilla per aver reso WPT il successo che è oggi. Anche Mozilla ha avuto un grande ruolo nelle indagini sul DNA della rete MDN. Oltre a questi, c'è anche lo stato di CSS 2021. Per realizzare un'iniziativa come Interop 2022, abbiamo bisogno di nuovi input sulle esigenze degli sviluppatori web, quindi abbiamo collaborato con la società che gestisce il sondaggio Sacha per includere alcune nuove domande sui problemi di compatibilità dei browser. Questo ci ha davvero aiutato nel processo di pianificazione di Interoperabilità 2022.

Ci sono insegnamenti o feedback da Compat 2021?

Robert: È stato davvero utile misurare e ottenere punteggi e approfondimenti sul rendimento di ciascun motore del browser, in modo da poter seguire i progressi e assicurarci di discutere e risolvere problemi non chiari o a cui dare priorità. Ci siamo anche resi conto che "Interop" era un nome migliore per l'iniziativa. I termini compatibilità e interoperabilità in genere si distinguono per fornitori di browser, dove compat si riferisce a compatibilità del sito e interoperabilità si riferisce a due o più browser che hanno lo stesso comportamento. In questa terminologia, questo impegno riguarda l'interoperabilità, per cui il progetto si è allineato con questa denominazione.

Qual è la nostra vision in questo contesto?

Robert: Per mantenere il web aperto, la diversità dei browser e dei motori di rendering è fondamentale. Sfortunatamente, al momento questo ha un prezzo elevato per i nostri sviluppatori che devono stare al passo con i diversi livelli di supporto delle funzionalità in ciascun motore. La nostra vision è che gli sviluppatori considerino la piattaforma web l'opzione più fattibile e la scelta più allettante per le loro esigenze e che possano concentrarsi sulla creazione delle migliori esperienze possibili invece di dedicare molto tempo a risolvere problemi di interoperabilità. Ed è molto chiaro che, per raggiungere questo obiettivo, le funzionalità più richieste devono essere presenti in tutti i principali motori dei browser per consentire davvero agli sviluppatori di avere successo sulla piattaforma web.

Come facciamo collettivamente a far progredire le cose quando si incontrano browser con (a volte) obiettivi diversi?

Philip: Il nostro approccio è stato quello di cercare aree di interesse comune, per individuare collaborazioni vantaggiose per tutti in cui gli obiettivi sono già abbastanza allineati. Dando la priorità a un numero limitato di cose su cui lavorare contemporaneamente, ci concentriamo su queste aree, andiamo avanti più velocemente e otteniamo una qualità superiore rispetto a quella che otterremmo se lavorassimo semplicemente separatamente. Questa è l'idea.

Penso che sia importante riconoscere che ci sono dei limiti a questo approccio basato sul consenso, in cui gli obiettivi non sono sufficientemente allineati. Occorre procedere in qualche altro modo. A volte portare più prove delle esigenze degli sviluppatori web o degli utenti può essere d'aiuto, ma in ultima analisi i fornitori di browser possono offrire prodotti che non hanno un accordo ampio. Nel migliore dei casi, il valore della funzionalità viene poi dimostrato dagli sviluppatori web che la provano, scoprendo che è in grado di soddisfare le loro esigenze e chiedono la stessa funzionalità in tutti i browser.

Tornando a Interoperabilità 2022, vediamo che a un certo punto nella pipeline verranno aggiunte funzionalità non di progettazione o di layout?

Philip: Assolutamente sì. Interoperabilità 2022 non si limitava alle funzionalità di stile e layout, ma ha dovuto puntare molto verso CSS. In parte perché lo stato di CSS 2021 era nuovo, ma anche perché gli sviluppatori web ci hanno detto che è qui che hanno i maggiori problemi con le differenze tra i browser. Diverse aree di interesse, come gli elementi del modulo e delle finestre di dialogo, vanno oltre il CSS; inoltre, stiamo conducendo alcuni sforzi di indagine sulla modifica delle API e degli eventi del puntatore e del mouse. Spero che, per l'interoperabilità 2023, avremo più dati aggiornati sulle esigenze degli sviluppatori in tutto il web e che includeremo più funzionalità di questo tipo nel nostro impegno.

Modifiche principali imminenti

Uno degli obiettivi di questa serie è quello di avvisare gli sviluppatori sui prossimi cambiamenti chiave. gli aspetti importanti per migliorare l'esperienza utente e le funzionalità della piattaforma.

Le tempistiche indicate di seguito indicano i tempi previsti per l'applicazione di queste modifiche. Tuttavia, le possibili versioni di release delle funzionalità potrebbero cambiare.

riduzione dello user agent

L'intestazione User-Agent, e le relative interfacce JS associate, non solo trasmette informazioni utili su browser e dispositivi, ma porta con sé anche una derivazione precedente e informazioni imprecise. Più problematico dell'offerta quasi infinita di bug di analisi delle stringhe UA è il fatto che viene inviato passivamente ai server per tutte le richieste di navigazione e di sottorisorse. Questo rappresenta circa 10 bit di entropia che i server possono utilizzare per creare identificatori di monitoraggio stabili quando gli utenti navigano sul web.

Il nostro piano attuale è quello di ridurre la stringa UA esistente continuando a fornire la versione principale del browser a bassa entropia, il nome della piattaforma e la mobileness, congelando le informazioni sull'alta entropia. Per i casi d'uso che richiedono informazioni aggiuntive rispetto a quelle contenute nell'intestazione, abbiamo fornito l'API User-Agent Client Hints dalla versione 89 di Chrome.

Abbiamo eseguito una prova dell'origine per 6 mesi per sperimentazioni e feedback e siamo stati felici di non aver ricevuto feedback in merito al malfunzionamento nonostante avesse oltre 200 partecipanti.

• Sequenza temporale: nella versione 101 di Chrome, procediamo con la fase 4, ovvero la riduzione delle informazioni MINOR.BUILD.PATCH nella stringa UA a 0.0.0. Inoltre, continueremo a informare i siti e a dare il tempo di prepararsi per le fasi 5 e successive. Abbiamo anche creato criteri aziendali per disattivare queste modifiche ed eseguiremo una prova del ritiro fino alla versione 113 di Chrome per dare ai siti più tempo per prepararsi a queste modifiche.
• Invito all'azione:esegui la migrazione del tuo sito ai Client Hints di UA o partecipa alla prova relativa al ritiro.

API Local Fonts Access

Chrome sta lanciando l'API Local Font Access. Sebbene i siti siano in grado di utilizzare da tempo i caratteri locali, questa API elenca l'elenco di caratteri locali e dà accesso ai dati dei caratteri stessi. Questa funzionalità offre agli utenti la possibilità di utilizzare tutti i caratteri con design basato sul web e altre applicazioni.

I caratteri locali sono da tempo noti come vettore di fingerprinting. Anche se questa nuova API non aumenta la possibilità di utilizzare i caratteri per il fingerprinting, Chrome richiede che un utente conceda una nuova autorizzazione "local-fonts" per un sito prima di poter utilizzare la nuova API Local Font Access.

In futuro, prevediamo di richiedere che gli stessi "local-fonts" che ti è stata concessa prima di utilizzare qualsiasi altra API che fornisca l'accesso ai caratteri locali.

• Tempistiche: targeting di Chrome 103 (giugno 2022)
• Invito all'azione: scopri di più sull'API e su come utilizzarla per iniziare a implementarla.

Far funzionare BFCache con Cache-control: no-store

Abbiamo identificato un'opportunità significativa per migliorare la frequenza con cui la cache back-forward può offrire navigazioni back-forward istantanee. Ciò richiede una modifica del comportamento di BFCache nelle pagine pubblicate con Cache-control: no-store HTTP header. Abbiamo una proposta pubblica progettata per evitare sorprese significative monitorando vari indicatori (ad esempio, la rimozione delle pagine dalla BFCache ogni volta che un cookie solo HTTP cambia) e le eliminazioni (ad esempio i criteri di gruppo per i clienti Enterprise/Edu) per contesti unici. Si tratta di un'opportunità complessa, ma entusiasmante, e ci piacerebbe avere ulteriori valutazioni e feedback.

• Tempistiche:targeting di Chrome 104 (luglio 2022), senza sorprese significative.
• Invito all'azione: consulta la proposta per ulteriori dettagli, tra cui come consentire un'implementazione in fase di sviluppo e come condividere il tuo feedback, ad esempio gli scenari effettivi in cui il nostro approccio creerebbe nuovi ostacoli.

Tramite questa serie, spero di poter dare alla nostra community di sviluppatori un senso di concentrazione e connessione, avvicinandole al mio team e al loro lavoro. Non perderti i prossimi aggiornamenti.

Nel frattempo, buon lavoro.

Cosa ne pensi della prima edizione di Chrome Dev Insider? Inviaci il tuo feedback.