Atualmente o tamanho médio de uma página na web é 2MB e são feitas aproximadamente 70 requisições para carregar completamente.
Para referência: um disquete ocupava menos espaço que isso (1,44MB) e um memory card do PlayStation ocupava a metade (1MB).
Então com um 1MB era possível armazenar nosso progresso de todos os jogos, mas não é o suficiente para ler três paragráfos de texto na internet?
Quem aguenta? 😟
Hoje vou trazer umas reflexões sobre esse tema que estou chamando de O Inchaço da Web. Quem já ouviu falar, ou quiser buscar, ele é conhecido por "Web Bloat" na gringa.
Vou começar com o mesmo disclaimer que a palestra que incentivou essa publicação:
Let me start by saying that beautiful websites come in all sizes and page weights. I love big websites packed with images. I love high-resolution video. I love sprawling Javascript experiments or well-designed web apps.
*This talk isn't about any of those. It's about mostly-text sites that, for unfathomable reasons, are growing bigger with every passing year.*
While I'll be using examples to keep the talk from getting too abstract, I’m not here to shame anyone, except some companies (Medium) that should know better and are intentionally breaking the web.
Porque é ruim
O epub que tenho de um dos maiores livros do mundo, Em Busca do Tempo Perdido (Marcel Proust), possui quase 4 mil páginas e pesa menos do que a página para comprar esse ebook: enquanto o livro ocupa 4894 KB, a página de compra pesa 15940 KB.
Uma página com informações resumidas sobre o livro (e um botão para comprar) ocupa mais espaço do que o livro inteiro. Por isso ler livros no Kindle que possui hardware modesto é suave e fluido, mas comprar? Nem tanto.
Observe você mesmo:
→ https://www.amazon.com.br/Marcel-Proust-Search-volumes-English-ebook/dp/B0837BFZBL
64 / 215 requests 3.5 MB / 6.0 MB transferred 13.8 MB / 20.0 MB resources Finish: 1.2 min DOMContentLoaded: 1.73 s Load: 2.75 s
Precisamos de tudo isso para entregar o conteúdo?
Um site como semi-brincadeira criou o *Web Bloat Score Calculator - Web-BS.*
Basicamente faz a seguinte comparação: o tamanho da página web VS o tamanho de um print daquela mesma página.
Se a página é tão maior que a imagem e o conteúdo não é perdido, substitui a página pela imagem! 😄
Não de verdade, mas definitivamente re-pense sua página. Foi o que fiz com meu blog e farei com meu site.
Aqui: https://www.webbloatscore.com/
Acessibilidade
Sites pesados não são acessíveis.
No Brasil, embora o acesso seja amplo e quase 80% da população tenha acesso a internet, 90% da população mais pobre acessa somente via celular - e não é 5G. E dos que possuem residencial, menos de 50% são fibra ótica.
Para exemplificar esse problema resolvi fazer um teste irônico: quanto tempo leva para conseguir ler o conteúdo de uma página que fala sobre acessibilidade. Como a Apple é reconhecida pelo seu minimalismo, design limpo, engenharia inteligente, etc, peguei essa página sobre as Human Interface Guidelines, na seção de acessibilidade.
Os resultados foram mais tristes do que eu esperava. A página pesa quase 10 disquetes (~12MB) e faz quase 200 requisições.
Em um Moto G4, com a conexão 3g lenta (o padrão do Brasil), esses foram os resultados:
→ https://developer.apple.com/design/human-interface-guidelines/foundations/accessibility
178 requests 12.2 MB transferred
Finish: 4.4 min DOMContentLoaded: 36.28 s Load: 4.4 min
Embora o conteúdo tenha carregado em 36.28s, a página só se tornou visível após 2 minutos e 36 segundos. Para concluir tudo levou mais de quatro minutos! Li todo o conteúdo em cinco minutos, então literalmente me custou o tempo de outro artigo.
Imagine viver com essa conexão para estudar, escrever um artigo ou assistir a aula online enquanto o mundo está fechado por causa da pandemia?
Bom, sessa página são descritas as melhores práticas de acessibilidade de acordo com a Apple, a primeira delas sendo design with accessibility in mind:
Accessibility is not just about making information available to people with disabilities — it’s about making information available to everyone, regardless of their capabilities or situation. Designing your app with accessibility in mind means prioritizing simplicity and perceivability and examining every design decision to ensure that it doesn’t exclude people who have different abilities or interact with their devices in different ways.
É... ¯\_(ツ)_/¯
Qualidade
Páginas inchadas são lentas, dificeis de acessar, e com tanto conteúdo desnecessário que tira o foco do principal. Os anuncios e scripts de rastreamento rentabilizam e trazem mais compras, de fato. Por outro lado as páginas que anunciam perdem visitantes ou são bloqueadas por Ad-Blocks, cada vez mais utilizados.
O navegador Brave, por exemplo, tem ad-blocker por padrão e quantifica a economia. Segundo o navegador do meu computador principal - o que mais utilizo - essas são as estatísticas dos últimos três meses:
-
323.738 Rastreadores & anúncios bloqueados
-
6.24 GB Banda economizada
-
4.5 horas Tempo economizado
Misericórdia! Lembrando que isso é de uma máquina que uso apenas para trabalho e estudo, portanto acesso apenas conteúdos que giram em torno de tecnologia.
Páginas inchadas são páginas ruins. E isso tem causado uma quebra de expectativa de qualidade.
Esperança
Anti-Esperança
"Google AMP" e "Facebook Instant Articles" não são soluções. Na verdade, são anti-soluções.
Porque criar outro tipo de marcação (AMP) para resolver um problema que não existe no HTML?
Não precisamos de técnicas de otimização e minificação de megabytes de JavaScript automaticas. Podemos simplesmente remover, não utilizar, etc.
Para quem só sabe usar martelo, todo problema é um prego.
Por que JavaScript se tornou o martelo da Web?
Necessidade
A palestra que mencionei antes tem uma pirâmide alegórica a de nutricionistas adaptada para a web bem didática:
O conteúdo deve ser distribuído de tal forma que Texto > Formatação > Ilustrações > Estilização > Scripts
. Quando penso em um jornal, penso em um papel com uma grande quantidade de texto bem formatado, complementado com imagens. Me parece que jornais poderiam seguir essa pirâmide (diferente de um aplicativo interativo).
Ainda assim a página do G1 faz 70 requisições e carrega 3MB de conteúdo, sendo que 75% são scripts do site e de rastreamento, 10% imagens mal otimizadas e 15% o que parece ser conteúdo.
A verdade é que se você desativar o JavaScript no navegador a maioria das páginas que utilizamos não vai funcionar como esperado. E claro que não me refiro aos web apps, como um sofisticado aplicativo de Mapas, mas sim sites normais em que a maioria do conteúdo é textual.
Segundo a pirâmide, JavaScript está no topo, então porque permitimos que se tornasse uma parte vital? Para a maioria dos sites isso não é necessário e fazemos somente porque sim. Ou porque parece simples, ou certo, ou a moda.
Na publicação sobre a construção do blog comentei um pouco melhor sobre como reconstruí o site mas, em síntese:
-
O foco do conteúdo é texto puro (e seus links)
-
Migrei as imagens dos posts existentes, mas ainda estou decidindo sobre as capas
-
Utilizo CSS porque simplicidade e leveza não significa feio :p
-
JavaScript é desnecessário para consumir o conteúdo do blog, mas útil para estender duas funcionalidades:
-
Newsletter: a inscrição na newsletter é um aplicativo externo, para onde o usuário é redirecionado
-
Comentários: os comentários são um webapp por si só, injetados através de um widget Javascript
-
Em ambos os casos, JavaScript só estende comportamentos para além da funcionalidade de blog - e só acontecer a partir da ação do usuário. E o CSS não afeta a marcação, apenas os estilos. Então se você desativar tudo, remover todos os estilos, continuará sendo um blog funcional e legível, que pode ser consumido em qualquer leitor que você desejar.
É claro que as cinco pessoas que leem meu blog, incluindo a minha mãe, não serão afetadas por isso. Se você também tem um blog e pensa o mesmo, o ponto é que serve como prova de conceito e estudo. Pegue aquele projeto na gaveta que utilizou create-react-app
sem nem saber porque e experimenta reconstruir ele começando pelo bom e velho HTML. Ou, no meu caso, pelo mais simples ainda: texto puro (Markdown).
A esperança aqui é que esse é um tema em pauta, e cada vez mais tem ficado à tona a necessidade de reduzir a complexidade das coisas porque a tecnologia está evoluindo muito rápido.
Conseguimos enviar coisas para o espaço com menos de 1MB de RAM, mas precisamos de mais que isso para ler uma notícia local? Esse blog trazendo a informação pesa mais que, quase 2MB.
Conhecimento
O inchaço da web não é causado por falta de conhecimento e isso significa que não precisamos re-ensinar tudo para todos os programadores para evitar que ocorra.
Ninguém aumenta a complexidade de um site simples para um super produto porque desconhece o formato mais simples. Todos os devs web começam por HTML e CSS. O motivo é a busca constante por inovação, estar utilizando a tecnologia do hype e a comparação entre os concorrentes.
A forma como o mercado funciona hoje é insustentável para o desenvolvimento web. A maior parte do nosso trabalho se torna explicar o que as pessoas não precisam em vez de construir o que elas precisam.
Em vez de ensinar tudo do zero podemos "só" mudar o paradigma das indústrias e trabalhar com prazos mais justos e expectativas mais próximas da realidade - talvez aquela vitrine não precise ser um Remix utilizando Bootstrap, JQuery, microfrontends blá blá blá. Talvez precise ser um simples HTML + CSS + JavaScript com links para as redes sociais.
Paliativos
Enquanto reduzir o inchaço da web não se torna, de verdade, uma preocupação das grandes corporações...
Nos últimos meses, com a pandemia e todo o resto, meu interesse por esse assunto e minha missão por uma web mais minimalista foi amplificada pelo sentimento de sobrecarga.
Para qualquer atividade simples o esforço cognitivo aumentou muito:
-
Ler um artigo exige sair dos anúncios, pausar vídeos, recusar cookies, recusar newsletters, recusar notificações, etc;
-
Fazer uma pesquisa simples no Google precisa fazer um a dois scrolls para passar pelos resultados que são anuncios;
-
Acessar a caixa de entrada (e-mail) se tornou impossível, pela quantidade de e-mails de marketing, spam, para serviços que fui obrigada a inscrever ou nem recordo de ter acessado algum dia;
-
Acessar um aplicativo no celular exigia uma busca porque, hoje em dia, tudo é um aplicativo! E todos precisam de todo tipo de permissão. (poxa, Reddit!)
Para endereçar cada uma dessas situações, tomei algumas medidas individuais:
-
Artigos: comecei a utilizar agregadores e leitores específicos para newsletters. Meu preferido é o Matter e quando ele está indisponível uso o https://12ft.io/ diretamente. Também tive uma boa experiência com o Slick Inbox no celular.
-
Pesquisa: Migrei para o Brave Search. Gostaria de usar mais o DuckDuckGo, mas não funcionou para mim durante o trabalho.
-
E-mail: Migrei para o Proton todas as minhas contas importantes - Bancos, Github, etc e desativei a newsletter e marketing de todas elas. Ainda utilizo o Google porque é "gratuito" e tem filtros poderosos, faço isso através de um alias único do DuckDuckGo e para tudo que não são contas urgentes. Utilizo aliases do SimpleLogin para tudo que pede um e-mail e não deveria - depois excluo ou bloqueio. Dessa forma,
-
ProtonMail: notificações ativadas que acesso diariamente, pois são e-mails importantes como contato direto de amigos ou colegas e transações bancarias;
-
Google via Duck: notificações desativadas, leio ocasionalmente quando tenho tempo e vontade porque são sites menos relevantes, e-commerces, etc;
-
Google via SimpleLogin: notificações desativadas, leio quando necessário e bloqueio ou removo os aliases que não são mais úteis;
-
E as newsletters interessantes foram todas movidas para os aplicativos mencionados anteriormente.
-
-
Smartphone: migrei para a Minimalist Launcher para fazer um detox. Depois organizei a original de forma mais minimalista, com foco no que realmente preciso.
Idealmente o rumo do desenvolvimento web vai evoluir substancialmente e essa sensação de sobrecarga por utilizar a internet vai reduzir, vamos cultivar hábitos mais saudáveis. Mas, como dev, sei como é fácil cairmos na complexidade, e como as stacks de desenvolvimento atualmente contribuem para isso, então acho que é algo que ainda vai demorar. Já se tornou aceitável um computador para navegar na web para estudos precisar de SSD e 8gb RAM, hehe.
Até lá, essas são algumas medidas que tomei para melhorar a minha experiência individual. Além disso, reconstruí meu blog do zero. E vou manter o inchaço da web em mente para todas as soluções das quais eu fizer parte da construção, seja como arquiteta ou como desenvolvedora.
Precisamos reduzir a complexidade.
Muito obrigada por ler até aqui! Espero que essa tenha sido uma reflexão interessante. Se quiser ler mais sobre o tema, recomendo:
- Computers in Spaceflight: The NASA Experience
- Report: State of the Web
- Web bloat isn’t a knowledge problem
Como o inchaço da web tem te afetado?