Every Second Counts: Web Performance
Atualmente, vivemos numa sociedade caraterizada pelo imediato e pela tecnologia.
Segundo Shengyin Zhu et al (2020), 27% dos utilizadores abandonam um website que demore mais do que 5 segundos a carregar, sendo que estes primeiros segundos são cruciais e os que têm maior impacto na adesão de utilizadores.
Toda esta problemática afeta não só a experiência dos utilizadores (UX) como os resultados do site. A verdade é que, muita das vezes, este tempo não se deve à velocidade da ligação à rede, mas sim à forma como o código é desenvolvido. Existem vários caminhos pelos quais os front end developers podem optar desde a organização do código à forma como a página irá ser carregada que iremos ver em seguida.
Mas por que razão proceder à otimização do front end ao invés da do back end? Relativamente ao tempo de resposta de um website, não é possível vermos onde é gasto esse tempo mas sim onde não é gasto: no carregamento do documento html. Ainda, ao otimizarmos o back end iremos ter uma diminuição entre 5% a 10% do tempo de resposta contrariamente à do front end que estará entre os 40% a 45% [3]. Daí concluirmos que poderemos ter uma melhor experiência do utilizador ao nos debruçarmos sobre o front end.
Primeiro devemos ter conhecimento sobre como a Web percorre os nossos ficheiros. Inicialmente, o documento html é descarregado. Assim que o browser encontra um ficheiro css, procede ao seu download e, de seguida, a página começa a ser renderizada até o html ser executado. Ao obter uma tag de script, procede à sua execução, o que irá interferir na renderização da página e esta será “bloqueada”. Por vezes, alguns browsers pausam todos os processos enquanto está a acontecer o download e execução do script, o que causa transtornos ao consumidor final [5]. Posto isto e, para uma melhor performance do website, o código deve estar estruturado da seguinte forma: em primeiro lugar deve haver a correspondência para aplicar os styles e estes serem carregados antes do html ser processado, de seguida a tag html e, só no final, o script para que não interfira no desenvolvimento da página. A combinação de colocar os styles e scripts nos sítios adequados resulta numa resposta rápida e, posteriormente, numa melhor experiência de usabilidade.
Em seguida serão apresentadas as causas e soluções do funcionamento do front end na Web.
Otimização dos ficheiros css e js
Os ficheiros enviados para o browser contêm, muitas vezes, caracteres desnecessários como espaços em branco, tabs, quebras de linhas, comentários. Para aumentar a performance, utiliza-se um software como o Gzip, em que são reduzidos os dados e volume enviados proporcionando menor tempo de carregamento da página [1].
Ao colocar estes dois ficheiros num link externo dentro do html, a velocidade de carregamento acelera visto que, estes são armazenados em cache e não são feitos tantos pedidos ao servidor [2].
Reduzir o número de pedidos
A chamada Performance Golden Rule afirma que, apenas 10% a 20% do tempo de resposta da página é gasto no download do html e, os outros 80%-90%, são gastos nos restantes componentes da página.
Cache
Através do HTTP caching é possível armazenar em cache grande parte da informação e, consequentemente, reduzir o número de pedidos ao servidor. É através dela que os utilizadores podem ter acesso aos arquivos localmente, diminuindo o tráfego.
O cache-control, cabeçalho HTTP que determina o comportamento da cache do browser, ao ser definido, armazena o conteúdo vindo do html. Enquanto a página de cache-control estiver ativa, o browser irá ler o conteúdo necessário através da mesma sem ter de recorrer ao servidor. Assim que expirar, aí sim será enviado um novo pedido ao servidor. Desta forma, o tempo de espera do utilizador será menor pois não é necessário carregar consecutivamente os mesmos ficheiros.
Nas próximas imagens são apresentados dois exemplos que comprovam esta teoria. Na primeira imagem (Fig 2A.) são carregados os elementos necessários à execução da página. Como é possível ver, a quantidade de imagens ocupa a maioria do tempo de carregamento. Já na imagem seguinte (Fig 2B.), o número de pedidos reduziu abruptamente. Uma vez que, os ficheiros já estavam armazenados em cache, não foi preciso recarregá-los, o que reduziu o tempo de espera de carregamento [1].
Imagens
Observando, ainda, as imagens acima é um facto que estas são as que ocupam a maior percentagem de tempo de carregamento da página. O srcset é um atributo da tag img que especifica várias sources (URL’s) para uma mesma imagem. Juntamente com o sizes, são carregadas as mesmas imagens com diferentes resoluções e tamanho dependendo dos dispositivos utilizados. Isto é vantajoso visto que, apenas uma das imagens é carregada com a devida resolução, adaptando-se o tempo do seu carregamento [4]. A resolução de imagem num telemóvel terá de ser menor do que para um computador e, naturalmente, o tamanho e carregamento da mesma irá ser alterado.
<img srcset="big.jpg 200w, med.jpg 100w"
sizes="(min-width: 576px) 70vw,
(max-width: 576px) 80vw,
100vw"
src="big.jpg" alt="img"/>Agregado a estas tags, há ainda a possibilidade de recorrer à picture. Esta tag contém tanto as sources como a img. De todas as sources escolhe a mais adequada, mas se houver alguma falha, é utilizado o URL da img [4].
<picture>
<source srcset="big.jpg 200w" media="(min-width: 576px)"/>
<source srcset="med.jpg 100w" media="(max-width: 576px)"/>
<img src="big.jpg" alt="img"/>
</picture>Lazy loading
Continuando, ainda o tema das imagens, há alguns métodos que ainda podem ser implementados. Quando carregamos uma página fundamentalmente composta por imagens, não as podemos mostrar todas devido ao elevado tempo que a página iria demorar a carregar. Já que, o utilizador não as vai ver todos em simultâneo, é aplicado o lazy loading que se carateriza por carregar apenas os recursos quando necessários. Por exemplo, as imagens mostradas na tela são carregadas enquanto as últimas ainda não. Através do scroll, as imagens seguintes vão sendo carregadas à medida que vão aparecendo no ecrã. Se a imagem estiver na visão do utilizador, recebe o URL real da imagem para que seja carregada e assim sucessivamente [1].
Com isto, a velocidade de carregamento aumenta, continuando a página com a mesma estrutura.
CDN
Com o CDN (Content Delivery Network) há uma otimização não do servidor, mas da ligação servidor-cliente [2]. Aqui os servidores são divididos em dois grupos: o servidor edge e o servidor origin. O utilizador, ao realizar um pedido, irá comunicar primeiramente com o edge server. Caso este não tenha a informação necessária, é feito um pedido ao origin server. Ao mesmo tempo que a informação é apresentada ao utilizador, a mesma é armazenada no edge server para que, sempre que esse pedido seja feito, seja devolvido rapidamente através da memória no edge server [5].
Sucintamente, define-se por apresentar o conteúdo do website na “periferia” da rede mais próxima do utilizador, diminuindo o caminho entre o pedido e a resposta, aumentando a velocidade de resposta. Desta forma, o utilizador irá receber os conteúdos mais rápido e a congestão do website irá diminuir. Se a resposta ao pedido já existir no CDN, este é retornado diretamente para o browser sem ter de recorrer ao servidor [1].
Aplicadas estas soluções, poderemos ver resultados significativos no que toca à Web Performance.
Referências
[1] https://iopscience.iop.org/article/10.1088/1742-6596/1453/1/012045/pdf
[2] https://ieeexplore.ieee.org/abstract/document/6022862
[4] https://learning.oreilly.com/library/view/high-performance-responsive/9781491949979/ch05.html
