O autor do material, cuja tradução publicamos hoje, diz que, em meados de setembro de 2019, finalmente concluiu o projeto em que trabalha há um ano. O objetivo deste projeto era reduzir o tamanho do manifesto necessário para inicializar o pipeline JavaScript assíncrono da Wikipedia. Ou seja, o tamanho do manifesto era 36 Kb. Tinha que caber em menos de 28 Kb, o que corresponde a dois fragmentos de 14 kilobytes da sequência de pacotes da Internet.
O resultado deste projeto foi uma economia diária de 4,3 terabytes de tráfego.
No início, o tamanho do manifesto excedia 36 Kb e, após a otimização, seu tamanho se tornava menor que 28 KbO gráfico mostra uma diminuição gradual no tamanho do manifesto. Estamos falando de dados compactados (ou seja, é a carga líquida na rede, que cria a transferência desses dados do servidor para o navegador).
Processo de otimização
O manifesto de inicialização é representado por dados que não são fáceis de otimizar. A maior parte de seu código não é algo como lógica funcional que pode ser otimizada pelos meios tradicionais. Em vez disso, quase todo o manifesto é representado por dados puros. Esses dados são gerados automaticamente pelo sistema de entrega de conteúdo do
ResourceLoader . Eles são um registro de pacotes configuráveis do módulo. A Wikipedia usa o sistema ResourceLoader para trabalhar com JavaScript, CSS e recursos de texto.
O registro inclui metadados para todas as funcionalidades de front-end implantadas na Wikipedia. O manifesto lista os nomes dos pacotes configuráveis, suas versões atuais e suas dependências de outros pacotes configuráveis similares aqui descritos.
Comecei procurando um código que nunca foi usado na prática (
T202154 ). Isso incluiu a localização de trechos de código incompletos ou esquecidos relacionados aos recursos herdados. O código não utilizado foi removido imediatamente, garantindo a compatibilidade com navegadores que não passaram mais no nosso teste, o que garantiu sua inclusão no grupo de navegadores modernos (
Grade A ). Também preparei um
documento sobre o desempenho de carregamento da página. Este documento serviu de referência, permitindo que os desenvolvedores entendam o impacto de alterações de vários tipos nos vários estágios do processo de carregamento da página.
Reduza o número de módulos
O próximo passo foi colaborar com as equipes de engenharia da Wikimedia Foundation e da Wikimedia Deutschland. Precisávamos descobrir quais recursos do sistema usam um número excessivo de módulos. Por exemplo, tendo entendido isso, seria possível combinar pacotes anteriormente dispersos a partir dos quais uma certa funcionalidade foi construída. Esses pacotes, mesmo em um estado disperso, sempre carregados juntos. Isso levaria ao fato de que haveria menos pontos de extremidade no sistema cujos metadados deveriam ser armazenados no registro formado pelo ResourceLoader.
Aqui estão alguns pontos interessantes sobre a aplicação dessa abordagem de otimização:
- A extensão WikiEditor agora tem 11 menos módulos do que antes. Outros 31 módulos foram removidos do UploadWizard.
- Ao otimizar o programa ContentTranslation, 24 módulos foram combinados.
- O projeto MobileFrontend combina 25 módulos.
- 20 módulos removidos do RevisionSlider e TwoColConflict.
Também é muito importante que o cliente Wikidata para Wikipedia tenha sido otimizado. Essa parte do trabalho em si foi um projeto épico (
T203696 ). Inicialmente, 248 módulos individuais foram responsáveis pela implementação desse recurso. Depois que conseguimos nos livrar de mais de 200 módulos, havia apenas 42 deles.
O diagrama acima mostra as pequenas melhorias que foram feitas no projeto ao longo do ano. Todos eles nos aproximaram do objetivo. Gostaria especialmente de observar duas grandes quedas no tamanho do manifesto. Uma dessas quedas ocorreu na primeira semana de agosto. Foi então que uma versão aprimorada do Wikidata foi implantada. A segunda queda no tamanho pode ser observada no final do gráfico. Isso aconteceu em meados de setembro. Agora eu gostaria de falar sobre ele.
Reduzir tamanhos de metadados
A melhoria no manifesto que ocorreu em meados de setembro foi possibilitada por duas mudanças globais destinadas a uma organização de dados mais inteligente.
A primeira melhoria é que, anteriormente, os metadados do esquema de extensão
EventLogging faziam parte do manifesto principal. Esse mecanismo foi refatorado, tornando assim os metadados do esquema agora incluídos no pacote JS do cliente EventLogging. Como resultado, a contribuição para o tamanho do manifesto feita anteriormente pelo EventLogging foi reduzida em mais de 90%. Isso significava que o caminho crítico agora contém 2 KB a menos de dados! Além disso, isso significava que a expansão dos recursos do EventLogging não levava mais a um aumento no tamanho do manifesto. Ao montar esses pacotes configuráveis, um novo recurso do ResourceLoader,
Arquivos de Pacote, foi usado . Esse recurso foi introduzido em fevereiro de 2019, um dos motivos de interesse, pois pode ajudar a reduzir o número de módulos no registro. Os arquivos de pacote simplificam bastante o processo de combinação de dados gerados e código JavaScript em um único módulo.
A segunda melhoria ocorreu quando reduzimos o tamanho médio de cada entrada do registro (
T229245 ). O manifesto contém duas entradas para cada módulo. Este é o nome do módulo e o identificador (ID) de sua versão. O identificador de versão anteriormente precisava de 7 bytes de dados. Depois de pensar
no paradoxo do aniversário no contexto do ResourceLoader, decidimos que o espectro de probabilidade para IDs de versão poderia ser reduzido com segurança de 78 bilhões para "apenas" 60 milhões. Detalhes sobre isso podem ser encontrados nos
comentários do código. Mas, para resumir essa melhoria, podemos dizer que isso nos permitiu economizar 2 bytes na descrição de cada um dos 1.100 módulos que ainda estão no registro. Como resultado, o tamanho do manifesto foi reduzido em outros 2-3 Kb.
Abaixo está um fragmento ampliado do diagrama, mostrando os últimos dias de operação (esses indicadores são obtidos do sistema de monitoramento sintético, dados não compactados são usados aqui).
Redimensionamento do manifesto na fase final de um projetoA mudança foi capturada pelo sistema de monitoramento ResourceLoader. A captura de tela mostra o painel
Tamanho do manifesto de inicialização localizado em uma instância pública do Grafana. Aqui você pode ver que o tamanho do fluxo de dados descompactado diminuiu 2,8 Kb.
A implantação do sistema, realizada em meados de setembro, levou à consecução do objetivo original, que era comprimir o manifesto para um tamanho não superior a 28 Kb. A implementação desse projeto de larga escala levou ao fato de que o manifesto de inicialização foi reduzido em 9 Kb (estamos falando de dados compactados). Há um ano, esse tamanho era de 36,2 Kb e, após a conclusão do projeto, já era de 27,2 Kb.
Cerca de 363.000 visualizações de página são geradas a cada minuto na Wikipedia e em projetos relacionados. Em uma hora - 21 milhões e 800 mil. Diariamente - 523 milhões (
aqui estão as estatísticas das visualizações de página). Essa versão do sistema, implantada em meados de setembro, gerou uma economia de aproximadamente 1,4 terabytes de tráfego por dia. E se você comparar o que é hoje com o que era um ano atrás, acontece que 4,3 terabytes de tráfego agora são salvos diariamente.
O que vem a seguir?
Conseguimos ajustar o manifesto de inicialização do Wikipedia de 28 Kb. Esse é o tamanho escolhido devido ao tamanho menor e múltiplo de 14 Kb. Dados desse tamanho podem ser colocados em fragmentos da
sequência de pacotes
da Internet transmitidos ao navegador.
Agora enfrentamos uma nova tarefa: não desistir de posições. No ano passado, eu tenho observado de perto o
manifesto . Fiz isso para garantir nosso sucesso e descobrir possíveis problemas que estão nos afastando. No final, automatizei esse processo usando o
painel público da
Grafana .
Se você acredita neste painel, ainda temos muitas oportunidades para melhorar o empacotamento do código e resolver problemas ainda mais fortes do que agora, facilitar a criação de pacotes. Espero que essas próximas melhorias sejam úteis para nós, mas por enquanto estamos trabalhando em novos recursos do sistema, enquanto nos esforçamos para cumprir os requisitos para o nível de desempenho do projeto.
Caros leitores! Você já participou da otimização de grandes projetos da Internet?
