Existe uma técnica completamente incomparável que permite manter o desempenho de um projeto da Web sob controle. Consiste em introduzir mecanismos no processo de desenvolvimento, cujos resultados são claramente visíveis. Esses mecanismos são projetados para sempre lembrar o programador da importância do desempenho. Há algo neste contexto que eu realmente gosto. Este é o cabeçalho HTTP da política de recursos . Este título é um recurso relativamente novo que permite ao desenvolvedor ativar e desativar determinados recursos do navegador enquanto navega no site. Por exemplo, você pode dizer ao navegador que ele não deve permitir o uso da API de geolocalização passando o seguinte cabeçalho:
Feature-Policy: geolocation 'none'
Há Feature-Policymuitas vantagens em usar um cabeçalho em termos de segurança e desempenho. Mas agora gosto especialmente de como Feature-Policyvocê pode usá-lo para tornar mais visíveis os problemas de desempenho do site que geralmente são fáceis de esquecer. Isso pode ser comparado a algo como "desempenho linting". Em particular, estamos falando sobre identificar problemas com imagens usadas em projetos da web.Política de imagens de grandes dimensões
Se a imagem for transmitida ao navegador em um formato compatível, ela será exibida. Esse é o comportamento padrão do navegador. O navegador, tentando ajudar aqueles que estão visualizando a página, também dimensiona automaticamente essas imagens. Portanto, eles ficam bem, mesmo que sejam representados por grandes arquivos gráficos. Como resultado, se você usar imagens maiores que os tamanhos necessários para a página, isso será, à primeira vista, invisível.Política ( diretiva )oversized-imagesinforma ao navegador que ele não deve permitir o uso de imagens cujo tamanho exceda, por um número especificado de vezes, o tamanho de seus contêineres. A imagem, de acordo com a restrição padrão, não pode exceder 2 vezes o contêiner. Mas esse valor, se necessário, pode ser redefinido.Portanto, se o navegador receber o próximo cabeçalho, ele não permitirá que você exiba imagens tiradas de nenhuma fonte (isso é definido graças none), cujas dimensões são mais de duas vezes o tamanho de seus contêineres (em largura ou altura).Feature-Policy: oversized-images 'none';
Se você precisar de mais flexibilidade, poderá informar ao navegador que ele não deve exibir imagens que sejam três vezes maiores que os contêineres:Feature-Policy: oversized-images *(3) 'none';
De qualquer forma, se a imagem não corresponder aos limites especificados, um stub será exibido em vez da imagem e uma mensagem de erro será enviada ao console.Se o site usar a política de imagens de tamanho grande, serão enviadas imagens grandes, mas um stub será exibido e uma mensagem de erro será exibida no consoleImagens não otimizadas
Outro problema comum com gráficos é o uso de imagens não otimizadas. Muitas vezes, você pode encontrar imagens que não foram compactadas adequadamente. Seu tamanho, no entanto, pode ser selecionado corretamente. Portanto, para arquivos com fotos, ao capturá-las e criá-las, muitos metadados desnecessários podem ser adicionados, que geralmente permanecem nos arquivos e quando usados nos navegadores. Um exemplo particularmente irritante disso são as imagens, cujos metadados contêm suas próprias miniaturas para visualização. Muitas vezes eu vi como a miniatura incorporada na imagem (cuja presença os designers e desenvolvedores nem conheciam) "pesava" mais do que a própria imagem!Entre outras coisas, aqui você pode recordar a compactação de imagem usual, suportada por muitos formatos, o que permite alcançar o equilíbrio perfeito entre a qualidade da imagem e o tamanho do arquivo.As políticas de imagens com perda não otimizadas e de imagens sem perda não otimizadas permitem que o navegador saiba que ele corresponde ao tamanho do arquivo e ao tamanho da imagem em pixels.Feature-Policy: unoptimized-lossy-images 'none';
Feature-Policy: unoptimized-lossless-images 'none';
Se o número de bytes por pixel (Byte por pixel, BPP) for muito alto, o navegador exibirá um esboço em vez da imagem e uma mensagem de erro no console.A aplicação de políticas não otimizadas- * faz com que um stub seja exibido em vez de imagens inadequadas - assim como a política de imagens superdimensionadas, onível recomendado de BPP para imagens compactadas com perda é de 0,5 e 1 para imagens compactadas sem perda. Além disso, ao analisar imagens, é permitido um pequeno desvio do tamanho total desses níveis. Agora, esse desvio para imagens compactadas com perda é de 1 Kb, para imagens compactadas sem perda - 10 Kb.Por exemplo, suponha que tenhamos uma imagem JPEG de 200x200 pixels. JPEG é um formato de compactação com perda de imagem, resultando em um nível recomendado de BPP de 0,5. Ao mesmo tempo, o tamanho total da imagem pode exceder o tamanho recomendado em apenas 1 Kb. Para descobrir qual tamanho uma imagem semelhante deve se adequar a um navegador, é necessário multiplicar as dimensões dos lados da imagem em pixels entre si e pelo BPP e, em seguida, adicionar o desvio permitido ao que acontece.(200 x 200 x .5) + 1024 = 21,024byte ou 20.5KbSe a imagem for compactada sem perda, é permitido um desvio do tamanho “ideal” de 10 Kb, enquanto o BPP dessa imagem será 1. Caso contrário, os cálculos serão exatamente iguais:(200 x 200 x 1) + 10,240 = 50,240byte ou 49.1KbÉ provável que o tamanho do desvio permitido mude no futuro. De fato, embora o Blink, por padrão, use esse indicador para imagens compactadas sem perda, iguais a 10 Kb, já estão em andamento experimentos com uma política unoptimized-lossless-images-strictque altera esse indicador, baixando-o para o nível de 1 Kb.Mídia não especificada
O novo é o velho bem esquecido.Durante muito tempo, o uso de atributos de imagem heighte widthfoi mais ou menos comum. Sem esses atributos, o navegador não sabia quanto espaço a imagem deveria ocupar até o momento em que a imagem foi carregada. Isso levou a mudanças nos layouts de página. A página foi exibida e, depois que a imagem chegou, seu conteúdo mudou. O navegador mais uma vez teve que recontar o layout para alocar espaço para a imagem.Quando chegou a hora dos layouts em que os tamanhos das imagens precisavam ser redimensionados de maneira flexível usando CSS, a presença ou ausência desses atributos não exercia mais um papel especial. Como resultado, muitos simplesmente pararam de usar esses atributos.Mas graças ao trabalho recenteiniciado por Jen Simmons, Firefox e Chrome podem calcular a proporção das imagens com base em seus atributos heighte width. Quando essa abordagem é combinada com os estilos aplicados às imagens, os navegadores podem reservar espaço para as imagens durante a passagem inicial do layout.A política de mídia sem tamanho informa ao navegador que todos os elementos de mídia devem ter atributos que especificam os tamanhos desses elementos. Se não houver tais atributos, o navegador deverá usar os valores padrão. Tudo, de fato, é um pouco mais complicado, mas a conclusão é que, se a imagem não tiver os atributos apropriados, o navegador usará o valor padrão de 300x150pixel.Feature-Policy: unsized-media 'none';
Quando essa política é aplicada, as imagens serão exibidas, mas se o tamanho não for especificado em HTML, o desenvolvedor notará rapidamente que as imagens são exibidas no tamanho padrão. E, como sempre, uma mensagem de erro será enviada ao console.A aplicação da política de mídia sem tamanho leva ao fato de que imagens e vídeos sem os atributos de altura e largura são exibidos, mas o navegador define seus tamanhos para 300 x 150 pixels.Provavelmente, vale a pena mencionar um recurso que a princípio me pareceu incomum. Ela se mostra ao compartilhar políticasunsized-mediaeoversized-images. Nesta situação, não se deve surpreender com a aparência de mais do que antes, o número de mensagens sobre imagens muito grandes. O fato é que, devido à aplicação da política, ounsized-medianavegador redimensiona imagens que não possuem atributosheightewidthaté300x150pixels. Após o qual é esse tamanho que o navegador usa como ponto de referência para determinar se a imagem corresponde ao seu contêiner.Atrair atenção para problemas menos visíveis
Nas políticas relacionadas à imagem, gosto do fato de que elas, no processo de desenvolvimento de projetos, tornam possível tornar visível o que geralmente está oculto. Como resultado, o desenvolvedor descobre que não cuidou de otimizar as imagens ou que esqueceu de definir seus atributos heighte width. Todos esses erros são refletidos imediatamente na aparência das páginas. De fato, a principal vantagem do uso das políticas acima é que elas permitem que o desenvolvedor descubra rapidamente os problemas com as imagens. Enquanto políticaunsized-mediapode levar a uma diminuição no número de situações nas quais ocorrem “trocas” de layouts de página; o uso de outras políticas não impede o carregamento de imagens inadequadas. Como resultado, o único ponto forte da aplicação dessas políticas é que elas chamam a atenção dos desenvolvedores para os problemas.Existem várias outras políticas que podem ser úteis em termos de análise de páginas quanto ao impacto de algo em seu desempenho. É aqui que políticas como o script de sincronização vêm à mente (essa política bloqueia a execução de scripts síncronos), sync-xhr(bloqueia solicitações síncronas de AJAX) e document-write(bloqueia chamadas document.write).Essas políticas são ótimas ferramentas para controlar certos aspectos do desempenho da página, mas elas próprias não fornecem aos desenvolvedores o mesmo feedback perceptível que muitas das políticas acima fornecem na forma de imagens ausentes. Obviamente, se a página possui um script síncrono, sem o qual não é exibido, isso não é fácil de perder (e essas páginas não são tão difíceis de encontrar). Mas essas políticas geralmente indicam erros na forma de mensagens exibidas no console. E, para ser sincero, suspeito que a maioria dos desenvolvedores não presta muita atenção ao console (acho que todos devemos ter mais cuidado com o console).Mas, no entanto, podemos tornar os erros detectados pelas políticas "invisíveis" muito mais visíveis usando a APIReportingObserver para monitorar violações e exibir notificações relevantes na página. Tais notificações podem ser feitas muito visíveis.let reportingAlerts = document.createElement('ul');
reportingAlerts.setAttribute('id','reportingAlerts');
document.body.appendChild(reportingAlerts);
const alertBox = document.getElementById('reportingAlerts');
new ReportingObserver((reports, observer) => {
let fragment = document.createDocumentFragment();
Object.keys(reports).forEach(function(item) {
let li = document.createElement('li');
li.textContent = reports[item].body.message + ': ' + reports[item].body.featureId;
fragment.appendChild(li);
});
alertBox.appendChild(fragment)
}, {types: ['feature-policy-violation'], buffered: true}).observe();
Eu esbocei um exemplo no CodePen de como isso pode parecer.Um exemplo de como você pode exibir notificações de violações da política especificadas pelo cabeçalho da Política de Recursos. Essas notificações são projetadas para saída no ambiente de desenvolvimento ou onde o projeto é preparado para saída para produção.Menos uso do cabeçalho da política de recursos
O grande ponto negativo de usar o cabeçalho Feature-Policyé o suporte dos navegadores. Aparentemente, agora ele é suportado apenas por navegadores baseados em Blink (Opera, Edge, Chrome, Samsung). Os navegadores Firefox e Safari suportam o atributo allowpara itens iframe. Mas mesmo onde é Feature-Policysuportado, para garantir a integridade de muitas políticas, você precisa ativar o sinalizador Experimental Web Platform features(você pode encontrá-lo no endereço about:flags).Como uso o cabeçalho da política de recursos
Aquele menos o título Feature-Policy, mencionado acima, para mim, pessoalmente, não é um problema específico. Prefiro usar as políticas definidas por este cabeçalho como um verificador de páginas baseado em navegador. Portanto, não preciso me esforçar para aplicar Feature-Policyna produção ou garantir que as políticas funcionem para todos os meus usuários. Eles são necessários apenas por mim e por aqueles que estão desenvolvendo o site. De qualquer forma, eu uso o Chrome como o navegador principal no processo de desenvolvimento. Portanto, garantir o desempenho Feature-Policeno meu ambiente de trabalho é ativar o sinalizador apropriado. Depois disso, os políticos trabalham sem nenhuma intervenção adicional da minha parte.Descobri que a maneira mais fácil de usar o cabeçalho é Feature-Policycom uma extensão do navegadorModHeader . Esta extensão permite que você defina seus próprios títulos que são passados para as páginas quando são visualizados.A extensão ModHeader permite configurar as opções de cabeçalho da política de recursos. Eles podem ser ativados e desativados, se desejado.Eutenho três conjuntos de valores de cabeçalhoFeature-Policyque uso periodicamente:oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';script-sync 'none'; unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';
Costumo manter o primeiro ligado. É muito emocionante viajar por páginas da web às quais as políticas usadas nela se aplicam. É assustador ver quão grandes são algumas imagens. Há muitas coisas na web moderna que poderiam ser melhoradas.Portanto, a política é muitas vezes desencadeada nas páginas unsized-media(e eu também peço por isso); portanto, seu uso durante o trabalho normal na Internet é inconveniente. É por isso que eu o destaquei em uma política separada, que eu posso ativar e desativar. O mesmo se aplica às políticas sync-scripts, cuja aplicação "quebra" muitos sites.Algumas das equipes com as quais trabalhei começaram a usar as políticas que descrevi durante o desenvolvimento. Isso permite que eles prestem atenção rapidamente a problemas anteriormente invisíveis. Obviamente, recomendo incluir todas as políticas Feature-Policyno ambiente de desenvolvimento, o que permite identificar e corrigir erros rapidamente.Sumário
Espero que o suporte Feature-Policyapareça, como resultado, não apenas no Chrome. Embora este seja o meu navegador principal, também tenho que usar outros navegadores. Seria útil se eles suportassem Feature-Policy. Mas aqui, no entanto, vemos essa situação rara em que até o suporte experimental de uma certa oportunidade é suficiente para que seja um benefício real.Problemas sutis de desempenho também são problemas. E a capacidade de tornar esses problemas mais visíveis é um dos melhores métodos que um desenvolvedor pode usar para identificá-los e corrigi-los.Queridos leitores! Você planeja usar o cabeçalho da Política de recursos para identificar problemas imperceptíveis em projetos da web?