Parece que o Lighthouse 6 introduz algumas novas métricas e remove algumas outras da v5, portanto, uma mudança na pontuação é certamente provável. Este artigo explica o que mudou:

https://web.dev/lighthouse-whats-new-6.0/

Há também um link no final para uma calculadora de pontuação que é realmente útil para analisar a pontuação e entender quais fatores contribuem mais.

https://googlechrome.github.io/lighthouse/scorecalc

Tenho a impressão de que há mais foco na interatividade do thread principal na v6, portanto, se o seu site inclui grandes pacotes JS, isso provavelmente é um fator significativo.

Sim @shanekenney , estou ciente, mas realmente não sei como reduzi-lo, além de remover partes do site para ver quais partes estão provocando isso

Você também vê o impacto nos sites gaysbyjs e theme-ui? Estou curioso / adoraria saber em quais otimizações em seu site eles podem estar pensando ou se identificaram alguma causa específica

Esse problema é ótimo para que possamos discutir as pontuações gerais dos insights do Lighthouse / PageSpeed ​​e as possíveis regressões que vemos na v6.

@kuworking, uma coisa que vale a pena notar é que lighthouse-metrics.com parece usar _ "Emulado Nexus 5X" _ para 5.6 e _ "Emulado Moto G4" _ para 6.0, o que também pode adicionar algum ruído à comparação.

Esta referência de mais de 922 sites afirma na v5 que a pontuação média de desempenho de um site Gatsby é 75 . Vou tentar fazer uma visualização rápida usando soluções hospedadas para evitar que minha rede local seja mais um fator de variabilidade.

Atualmente (com Lighthouse v5.6 / PageSpeed ​​Insights)

PSI roda em Moto G4 em "Fast 3G". Fonte

Certos sites de "sinalização" construídos usando Gatsby não estão realmente tendo um ótimo desempenho no PageSpeed ​​Insights (que ainda está usando o Lighthouse v5.6 eu suponho - sujeito à variabilidade padrão em cada execução, possivelmente executando 3x ou 5x e a média pesaria

• gatsbyjs.org (Mobile 72/100, TTI 9s) Fonte
• reactjs.org (Mobile 62/100, TTI 9.5s) Fonte
• gatsbyjs.com (Mobile 77/100, TTI 6.6s) Fonte

No entanto, alguns outros sites (e a maioria dos iniciantes) têm um desempenho muito bom no PageSpeed ​​Insights:

• store.gatsbyjs.org (Mobile 99/100, TTI 2.5s) Fonte
• thirdandgrove.com (Mobile 91/100, TTI 4.0s) Fonte

O TTI médio é perceptível - e embora a v6 mude o peso geral do TTI de 33% para 15% e reduza a Primeira CPU ociosa, ela adiciona TBT com um peso de 25%, o que possivelmente poderia explicar uma regressão das pontuações em geral apenas devido a análise e execução geral de JS.

Lighthouse v6 (com WebPageTest.org )

• Este rodou WPT em _Moto G (gen 4), Moto G4 - Chrome_ com uma conexão de _3G Fast (1.6mbps / 768kbps 150ms RTT) _. Isso parece ser o mais próximo de uma correspondência de dispositivo / rede que podemos chegar antes que o PSI atualize sua versão do farol subjacente.
• Certifique-se de verificar _Capture Lighthouse Report_ em _Chromium_. Desativei a visualização de repetição para manter o escopo em um visitante de primeira vez, primeiro carregamento da página.

Aqui estão os resultados, você pode ver o relatório do Lighthouse clicando em seu número. Estou extraindo os valores desse relatório.

• gatsbyjs.org (72 -> 67/100, TTI 7,5s, TBT 2150ms) Fonte
• reactjs.org (62 -> 66/100, TTI 7.8s, TBT 3520ms) Fonte
• gatsbyjs.com (77 -> 66/100, TTI 8.4s, TBT 2440ms) Fonte

No entanto, observe a regressão nos dois sites a seguir:

• store.gatsbyjs.org ( 99 -> 54/100 , TTI 6.8s, TBT 1300ms) Fonte
• thirdandgrove.com ( 91 -> 63/100 , TTI 14s !, TBT 1330ms) Fonte

Algumas das perguntas em aberto que tenho.

1. O TTI geral (e o TBT) é explicado pela análise + execução de JS ou há outros fatores que prejudicam a interatividade?
2. Em caso afirmativo, poderíamos ser mais agressivos (no Gatsby por padrão, como as últimas mudanças, como habilitar blocos granulares , ou sob algum sinalizador experimental) ao construir os blocos para _apenas_ enviar o que o primeiro carregamento precisa (ou seja, evitar o aplicativo- [hash] .js por ter excesso)? Também pode ser simplesmente documentar maneiras de brincar com a extensão da configuração do webpack com mais orientações.
3. Padrões como Módulo / nomodule podem ajudar a diminuir pedaços? Recomendando / documentando o uso de @ loadable / components? Reidratação parcial ?
4. Este pode ser um segundo passo para obter pontuações altas, mas como o FMP não é mais um fator, o LQIP em gatsby-image ajudando ou prejudicando quando se trata de LCP? O LCP de store.gatsby.org na corrida acima foi de 4.7s!

(Estou usando os links acima apenas como exemplos - se alguém quiser que um determinado link seja removido, posso editar a mensagem com prazer)

Meu site (https://matthewmiller.dev/) parece ter melhorado (~ 92 a ~ 95), mas alguns dos novos testes revelam algumas coisas que provavelmente poderiam ser melhoradas.

O teste de JavaScript desnecessário, por exemplo,
(A primeira coluna é o tamanho, a segunda coluna é a quantidade desnecessária)

Presumo que isso se deva aos itens necessários para outras páginas que estão sendo incluídos aqui, então usar algo como componentes carregáveis ​​pode ajudar um pouco.

Para mim, estou tendo grandes dificuldades em entender Largest Contentful Paint , no sentido de que estou obtendo valores muito grandes sem saber o porquê e vendo uma discrepância entre o valor no relatório (por exemplo, 7,4 se o LCP rótulo que aparece na guia Performance - ViewTrace (~ 800 ms)

Posso ver que algo semelhante parece acontecer no inicial https://parmsang.github.io/gatsby-starter-ecommerce/

Como uma atualização - parece que o PageSpeed ​​Insights lançou a atualização para executar o Lighthouse v6 (pode não estar em todas as regiões ainda).

Link para testar https://gatsbyjs.org/ . Atualmente obtendo resultados variando de 60 a 80 anos, principalmente dependendo dos valores de TBT e TTI.

@kuworking pode haver um problema com o Lighthouse v6 reconhecendo a imagem gatsby.

De acordo com o webdev

Para elementos de imagem que foram redimensionados de seu tamanho intrínseco, o tamanho relatado é o tamanho visível ou o tamanho intrínseco, o que for menor.

No meu caso, acho que o Lighthouse não está respeitando o tamanho da vista.

E aqui está a imagem em questão

Pode ser responsável pelo tamanho intrínseco que é de 3000 pixels, portanto, o LCP 13s para mim.

@ daydream05 Eu tinha teorias e descobertas semelhantes também, então testei minhas páginas sem imagens e ainda tinha um LCP longo louco (10-12 segundos). Tenho muita coisa acontecendo no meu projeto, então poderiam ser outras variáveis ​​também, mas estou curioso se você testou uma página com conteúdo de texto e ainda sem imagens.

Caiu de 100 para 79 ~ https://dougsilkstone.com/ recentemente. Salta até 90 quando o Gerenciador de tags do Google (e o Google Analytics) são removidos.

Vou relatar mais descobertas enquanto eu testo as coisas.

Editar: Hit 100 ao remover a fonte carregada do typekit do gatsby-plugin-web-font-loader (também usando o cache de fontes de pré-carregamento)

O GTM está afetando bastante meu projeto, mas não é uma mudança tão drástica quando eu o removo (5-10 pontos no máximo nas pontuações abaixo de 50 após LH6). Eu ainda preciso fazer mais testes, mas só queria lançar isso aí.

@Jimmydalecleveland interessante! Eu também tenho outro site onde a tela é apenas texto e está culpando o texto principal como a causa principal do LCP. E o LCP só leva em consideração o que está à vista, o que não faz sentido. Como um texto pode ser um problema tão grande.

@dougwithseismic Eu também uso o typekit e ele é um dos principais culpados pelas pontuações mais baixas do farol. Gostaria que houvesse uma maneira de consertar o typekit, já que eles não suportam a exibição de fontes

Eu acho que o Lighthouse v6 é realmente difícil em estruturas JS porque eles mudaram o peso das pontuações. (Mais foco no tempo de bloqueio) E os sites de Gatsby têm historicamente baixos índices de avaliação de script / thread principal devido à reidratação e outras coisas.

@dougwithseismic como você vinculou a fonte typekit sem usar a folha de estilo?

Estou tendo uma experiência semelhante, com o lighthouse 5.7.1 minha pontuação de desempenho foi de cerca de 91, no entanto, o lighthouse 6 diminuiu drasticamente minha pontuação de desempenho para cerca de 60.

Caiu de 100 para 79 ~ https://dougsilkstone.com/ recentemente. Salta até 90 quando o Gerenciador de tags do Google (e o Google Analytics) são removidos.

Vou relatar mais descobertas enquanto eu testo as coisas.

Editar: Hit 100 ao remover a fonte carregada do typekit do gatsby-plugin-web-font-loader (também usando o cache de fontes de pré-carregamento)

Eu nem mesmo tenho esses plug-ins instalados, mas minha pontuação móvel caiu de 90+ para 60 ~ 70+

O mesmo aqui. Queda enorme de 90 para 60 em vários sites.

+1 queda de cerca de 30+ pontos

Alguém está abordando isso? Parece que não adianta usar Gatsby em vez de Next se ele não fornecer melhores pontuações prontas para usar.

Alguém está abordando isso? Parece que não adianta usar Gatsby em vez de Next se ele não fornecer melhores pontuações prontas para usar.

Você tem algum número do Next?

Estou me perguntando se essas pontuações são o novo normal para webs rápidas (que não são estáticas, sem JS e provavelmente também sem imagens)

Você tem algum número do Next?

https://nextjs.org/ tem uma pontuação de 85, com a Largest Contentful Paint (3.8) e a First Contentful Paint (2.8) sendo os principais infratores. Ele também tem um monte de "JS não usados". Isso está abaixo de ~ 95 no Farol 5.7.1. É "apenas" uma queda de cerca de 10 pontos, enquanto os sites gatsby parecem perder o dobro de pontos.

Eu sou muito novo neste mundo, mas estou acompanhando este problema depois que meu site gatsby perdeu cerca de 25 pontos quando testado com o lighthouse 6.0.0 da npm. Curiosamente, se estou usando os insights de velocidade da página em vez do farol npm, meu site volta para cerca de ~ 99. Enquanto o gatsbyjs.org obtém ~ 70 em insights de velocidade da página, mas ~ 84 com farol npm. Provavelmente algo está sendo ajustado em algum lugar, eu acho? Todos eles estão recebendo avisos de 'JS não usado' que

Alguém está abordando isso? Parece que não adianta usar Gatsby em vez de Next se ele não fornecer melhores pontuações prontas para usar.

Você tem algum número do Next?
Estou me perguntando se essas pontuações são o novo normal para webs rápidas (que não são estáticas, sem JS e provavelmente também sem imagens)

Um site Next.js -> https://masteringnextjs.com/ 77 pontuação móvel. Muitos "JS não usados".

Vejo melhores pontuações com lighthouse-metrics https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Mas também não vejo imagens lá e, na minha experiência, as imagens parecem ter um alto (e legítimo impacto IMO)

No entanto, gatsbyjs.org não tem imagens e sua pontuação é (relativamente) ruim https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (em comparação com o exemplo @cbdp )

Vamos ver o que os desenvolvedores de gatsby pensam sobre isso

Com alguns ajustes, o site está de volta às melhores pontuações.

Parece-me o caso do Google movendo as postagens da meta para serem mais
estrito quanto ao desempenho - notavelmente FCP.

Nossos sites não são lentos de forma alguma, mais ainda, apenas sendo julgados por diferentes
critério. Vou ajudar nisso ✌️

Na terça-feira, 9 de junho de 2020, 18:48 kuworking, [email protected] escreveu:

Alguém está abordando isso? Parece que não adianta usar Gatsby
Em seguida, se não entregar melhores pontuações prontas para usar.

Você tem algum número do Next?
Estou me perguntando se essas pontuações são o novo normal para sites rápidos (que
não são estáticos, sem JS e provavelmente também sem imagens)

Um site Next.js -> https://masteringnextjs.com/ 77 pontuação móvel. Muito
de "JS não utilizado".

Eu vejo melhores pontuações com métricas de farol
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Mas também não vejo imagens lá, e na minha experiência as imagens parecem
tem um alto (e legítimo IMO) impacto

No entanto, gatsbyjs.org não tem imagens e sua pontuação é (relativamente) ruim
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(em comparação com @cbdp https://github.com/cbdp exemplo)

Vamos ver o que os desenvolvedores de gatsby pensam sobre isso

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

Só queria usar esta calculadora útil para comparar os resultados da v6 com a v5: https://googlechrome.github.io/lighthouse/scorecalc/

As pontuações do Lighthouse geralmente variam muito, mesmo quando usado por meio do PageSpeed ​​Insights. Por exemplo, para https://www.gatsbyjs.org/ recebi tudo de 64 a 88 de desempenho móvel após 5 execuções. Portanto, para rastrear esse problema, a calculadora pode ser útil para ver as consequências de pesos diferentes na mesma corrida (nota: como as métricas são um pouco diferentes, alguns valores como FMP devem ser assumidos usando medições anteriores).

PS: Aqui, tenho uma comparação de duas execuções do PageSpeed ​​Insights para gatsbyjs.org:
Execução 1 - v6: 67 - v5: 85
Execução 2 - v6: 78 - v5: 87
O maior impacto é causado pela nova métrica "Tempo total de bloqueio", que está abaixo de uma pontuação de 70 em ambas as execuções e também tem um peso de 25%.

Sim, para adicionar ao @Pyrax : LCP (pintura com maior conteúdo) e TBT pesam 25% cada no Lighthouse v6. Portanto, concentramos nossos esforços em abordá-los. Nós achamos:

LCP

• Remover todas as animações que podem ser acionadas no carregamento (por exemplo, cookie 💩 banner).
• Mudar para tracedSVG de gatsby-img pareceu ajudar um pouco, já que temos grandes imagens de heróis na maioria das páginas. (Não tenho certeza do motivo, na verdade, sem uma investigação mais aprofundada. A UX também melhora um pouco.)

TBT

• De longe, Unused JS do pacote de Gatsby parece ser o maior cuplrit (com backup de documentos do web.dev ), de longe. Treehaking de nível de página poderia certamente ser melhorado aqui?

Esta atualização recente do Lighthouse parece ter acabado com as pontuações de desempenho de todos, incluindo as suas próprias:

O único site gatsby meu que não foi realmente obliterado é um site que tem basicamente uma única página e 99% html. Mas mesmo aquele caiu cerca de 5-10 pontos.

Estou vendo o inverso da maioria das pessoas, ou seja, o Lighthouse no navegador Chrome ainda está mostrando boas pontuações para meu site, mas quando executado no PageSpeed ​​Insights ele cai a pontuação de desempenho em 20-30 pontos ... talvez minha versão do Farol do Chrome está atrás? O Chrome é o mais recente, não tenho certeza de como verificar a versão do Lighthouse integrada ...

Esta atualização recente do Lighthouse parece ter acabado com as pontuações de desempenho de todos, incluindo as suas próprias:

O único site gatsby meu que não foi realmente obliterado é um site que tem basicamente uma única página e 99% html. Mas mesmo aquele caiu cerca de 5-10 pontos.

Estou vendo o inverso da maioria das pessoas, ou seja, o Lighthouse no navegador Chrome ainda está mostrando boas pontuações para meu site, mas quando executado no PageSpeed ​​Insights ele cai a pontuação de desempenho em 20-30 pontos ... talvez minha versão do Farol do Chrome está atrás? O Chrome é o mais recente, não tenho certeza de como verificar a versão do Lighthouse integrada ...

A versão do farol é mostrada na parte inferior da auditoria.

@dylanblokhuis ah, sim, aí está. Estou no 5.7.1, a v6 ainda não é fornecida no Chrome?

@dylanblokhuis ah, sim, aí está. Estou no 5.7.1, a v6 ainda não é fornecida no Chrome?

Não é. De qualquer maneira, ainda não. Se você quiser o mais recente, pode instalá-lo a partir do npm e, em seguida, executar lighthouse https://yoursite.com --view e obterá sua pontuação no mesmo formato que está acostumado com a auditoria do Chrome :)

Para qualquer pessoa que teve uma grande perda nas pontuações, # 24866 também pode ser relevante. Houve uma mudança aparentemente bastante significativa na maneira como Gatsby está entregando os pedaços. Embora a mudança definitivamente pareça fazer muito sentido, pelo menos para nós, essa mudança resultou em um código que foi distribuído em blocos sendo concentrado em commons e app blocos. Significa um carregamento / análise de js significativamente maior.

O mais preocupante aqui é que essas métricas começarão a impactar o Page Rank relativamente em breve.

Eu eliminei todas as solicitações de terceiros (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha) e isso está apenas dando um aumento de pontuação relativamente pequeno, então algo mais está em jogo.

Além disso, para quem deseja executar o Lighthouse 6 localmente, ele já está disponível no Chrome Canary e deverá ser lançado no Chrome em julho.

Primeiro: entrei em contato com um engenheiro do Google que está trabalhando no web.dev e perguntei sobre isso. Não tenho certeza se isso levará a alguma explicação maior, mas eles parecem ter a intenção de ajudar. Farei o acompanhamento quando conseguir conversar com eles.

Minha pontuação de desempenho foi de 94-99 para 40-55. 😢

A maior pintura com conteúdo para meu site se aplica principalmente a páginas com imagens grandes. Por algum motivo, ele está dizendo que as imagens estão levando cerca de 14 segundos para carregar.

Se você abrir qualquer um dos sites iniciais mínimos do

Aqui estão as duas primeiras coisas que vi com muitas imagens:

ghost.gatsby.org :

gcn.netlify.app :

No entanto, o blog inicial do

gatsbyjs.com :

Compare as pontuações antigas com as novas no Chrome

Você ainda pode comparar as pontuações do método Lighthouse antigo com o novo sem usar a CLI. Acho útil ver o que mudou.

Ver testes antigos do farol

Para ver as pontuações antigas do Lighthouse, execute a extensão do Lighthouse Chrome nas ferramentas de desenvolvedor do Chrome, em vez da barra de ferramentas do navegador.

Ver novos testes do Lighthouse

Clique no ícone da barra de extensões do Chrome.

Minha página muda

Estas são as duas pontuações que tenho para a mesma página:

Farol antigo (por meio de ferramentas de desenvolvimento do Chrome)

Novo farol (via extensão do Chrome na barra de endereço)

🤷‍♂️

@nandorojo minha impressão com as imagens é que a emulação é feita com uma conexão muito lenta e aí as imagens demoram muito para serem renderizadas

Como a opção de remoção de imagens nem sempre é possível, talvez essas pontuações dos anos 70 sejam as normais para este tipo de páginas

E, a opção de atrasar o carregamento para que o usuário possa iniciar sua interação mais cedo, não parece funcionar (no meu caso)

Ei, desculpe pela resposta tardia. Já trabalhei no Lighthouse, vou tentar explicar o melhor que puder.

Os desenvolvedores do Chrome publicaram "Web Vitals", métricas essenciais para um site saudável. Ele contém muitas métricas, mas as principais são Largest Contentful Paint (LCP) , First Input Delay (FID) e Cumulative Layout Shift (CLS) . Para ferramentas como Lighthouse FID é trocado por Total Blocking Time (TBT) .

O Lighthouse v6 também leva essas métricas em consideração e mudou. Isso não significa que Gatsby seja lento. Pode ser que algumas otimizações diferentes sejam necessárias.

É assim que as coisas mudaram:

Se você quiser saber mais sobre o LCP, consulte https://www.youtube.com/watch?v=diAc65p15ag.

Então, vamos falar sobre Gatsby. O próprio Gatsby ainda é muito rápido e estamos melhorando ainda mais. Estamos criando novas APIs para que os construtores de páginas como MDX, rich text do Contentful, ... possam otimizar o pacote também. Muito pode ser feito otimizando seu LCP. Certifique-se de que, ao usar fontes e imagens, eles não sejam carregados lentamente e sejam carregados o mais rápido possível. Esses ativos devem ser carregados da mesma origem do seu site, eles não devem ser carregados de um CDN.

Infelizmente, o TBT é um problema difícil de resolver e para o qual o React não se otimiza. Se você deseja descartar o TBT, deve verificar o pré-ato . Preact tem a mesma API que React, mas tem uma pegada javascript menor. Eles fazem as coisas de maneira diferente, mas os componentes do React são compatíveis. Você o instala executando gatsby recipes preact .

Algo que percebi ao criar o perfil de gatsbyjs.com & gatsbyjs.org é que devemos carregar o Google Analytics, etc. um pouco mais tarde do que agora para garantir que ele não se torne parte do TBT.

Se olharmos para .com adiando análises e GTM e garantindo que as fontes carreguem mais rápido, já podemos ver uma melhoria de +17. Se adicionarmos pré-ação à mistura, veremos +6.

Podemos fazer o mesmo para .org, começamos com uma pontuação de 63. Com alguma otimização de LCP e TBT, podemos chegar a 75.

Não tenho certeza do que devemos fazer com esse problema. Sinto que podemos fechá-lo, pois não há muito mais que possamos fazer aqui. O que vocês acham?

@wardpeet Ty para uma visão extra.

Temos investigado muito esse assunto em um grande projeto Gatsby que temos, que usa Contentful e será usado em vários sites para nós (os temas de Gatsby são fantásticos). Compartilharei algumas descobertas, caso sejam úteis para alguém que esteja examinando isso.

1. Temos uma situação que pode não ser muito comum, mas já vi o suficiente para acreditar que também não é única, em que tivemos que usar useStaticQuery para capturar imagens provenientes de Contentful e .find um pelo identificador. Sempre soubemos que isso era errado, mas não fomos punidos por isso até que a escala do site cresceu para ter mais de 300 imagens e o LH6 apareceu e nos atingiu.

A razão para isso é porque as imagens são parte de incorporações de Rich Text e não podemos fazer o graphql para elas no nível de consulta de página (é essencialmente um campo json que Contentful tem pacotes para analisar). Ao usar o analisador de pacote Webpack, notamos um enorme arquivo JSON (cerca de 720 KB) e rastreamos os dados dessa consulta, que foram agrupados em um modelo que usamos para a maioria das páginas do Webpack. Isso significa que todos os usuários que visitam nosso site estão baixando-o como parte do bloco para o modelo de página inteira, independentemente de a página usar imagens ou não.

Grande woopsie de nossa parte, mas se alguém mais está fazendo grandes consultas estáticas (para as quais você, obviamente, não pode passar parâmetros para diminuir o tamanho), certifique-se de estar atento a essas situações e fique de olho em seus pedaços de pacote.

1. Tivemos algum sucesso hoje ao usar a proposta loading para a imagem de Gatsby em imagens que estão acima da dobra (imagens Hero para nós). Temos tentado trabalhar na pintura com maior conteúdo e isso gerou bons resultados em alguns testes iniciais. Há uma parte importante que eu quase perdi nisso: se você definir loading="eager" para sua imagem superior, você pode querer definir fadeIn={false} também para essa imagem, porque a transição entre a base64 e totalmente carregada a imagem leva tempo, o que atrasa o LCP.

Aqui está a documentação dos adereços a que me refiro e a nota sobre fadeIn está na parte inferior: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

Gostaria de compartilhar capturas de tela, mas não sei se tenho permissão, desculpe. Se você usar o Chrome devtools e olhar para o painel de desempenho, você receberá pequenas tags na linha "timings" para FP, FCP, FMP e LCP. Quando mudamos para o carregamento crítico da primeira imagem, não vimos apenas um aumento de pontuação de desempenho de ~ 8-10, mas você pode ver a tag LCP carregada imediatamente após o FMP em vez de um segundo ou mais tarde no meu caso.

Espero que ajude alguém a solucionar isso e obrigado a todos que responderam até agora.

Algo que percebi ao criar o perfil de gatsbyjs.com & gatsbyjs.org é que devemos carregar o Google Analytics, etc. um pouco mais tarde do que sabemos para ter certeza de que ele não se tornará parte do TBT.

@wardpeet, como você está adiando a análise e o GTM?

@wardpeet obrigado pela sua resposta. É útil. Talvez a melhor saída desse problema seja alguma documentação que descreve como otimizar cada uma das métricas no novo Lighthouse. Tenho certeza de que nosso site parece rápido para os usuários e que o próprio Gatsby está fazendo um ótimo trabalho de otimização do site para usuários reais. No entanto, se os indicadores vitais da web do Google começarem a informar o page rank, obter uma boa pontuação do farol se tornará essencial para a maioria dos sites.

@Jimmydalecleveland tivemos um problema semelhante em que precisávamos carregar todos os itens de um recurso para que pudéssemos usar dados de dentro do markdown para configurar um filtwr (ou seja, não poderíamos filtrar usando GraphQL) e otimizado usando fragmentos diferentes (um subconjunto de campos muito menor) ao carregar um recurso completo vs ao carregar todos os recursos para filtragem. Isso reduziu muito o nosso pelo JSON e, portanto, o tamanho do nosso pacote.

@treyles, você precisa ter cuidado ao atrasar o carregamento do Analytics, pois isso pode significar que suas estatísticas estão incompletas. Por exemplo, pode significar que sua taxa de rejeição relatada não é precisa. Existem alguns scripts que o marketing não nos permitiria atrasar (pixel, analytics, hotjar e, portanto, gerenciador de tags), mas outros, por exemplo, Intercom, são bons e uma otimização que vale a pena. Em termos de como atrasar esses scripts, os scripts fornecidos por terceiros geralmente carregam de forma assíncrona, mas isso por si só não é suficiente. Provavelmente, você precisará substituir esses scripts pelos seus. Ouça window.load e acione o download. Você precisa ter cuidado, pois alguns scripts dependem de window.load para inicializar, e se você o usou para carregar o script, ele não será acionado novamente, então você precisa inicializá-los manualmente. Por exemplo com a Intercom nós:

• removeu o padrão <script>...</script> fornecido pela Intercom.
• adicionou um ouvinte para window.load
• adicionou um breve atraso neste ouvinte
• acionou uma versão modificada do script padrão do Intercom que carregou seu lib async.
• sondado para ver quando o script foi carregado (Intercom não fornece um evento confiável)
• inicializaram manualmente seu script (o que foi feito em page.load por seu script padrão).

@wardpeet, obrigado pelo insight muito útil!

Em relação a esta solução:

Certifique-se de que, ao usar fontes e imagens, eles não sejam carregados lentamente e sejam carregados o mais rápido possível. Esses ativos devem ser carregados da mesma origem do seu site, eles não devem ser carregados de um CDN.

Isso não iria contra o funcionamento da imagem de gatsby? Além disso, a maioria dos CMSs lida com a transformação da imagem no servidor e hospedada em seu próprio CDN. (O que é uma coisa boa, imo). Mas se o hospedarmos em nosso próprio site, isso não seria contraproducente também?

Adicionando ao que @Undistraction disse, Gatsby é rápido, mas se não for rápido de acordo com os olhos do Google, então se torna problemático. Especialmente porque eles estão incluindo isso na atualização do ranking da

@Jimmydalecleveland Eu encontrei uma maneira de trabalhar com a imagem gatsby dentro do rich text do essência . O código foi copiado e colado de gatsby-source-contentful . Basicamente, você pode gerar o fluido com conteúdo ou adereços fixos fora do GQL. O que é perfeito para rich text do contentful.

Também criei uma solicitação pull para que possamos acessar as APIs diretamente de gatsby-source-contentful .

Algo simplesmente não combina para mim. Eu construí um site muito simplista com cerca de uma imagem por página, estou usando SVG para imagens sem gatsby-image, também tentei remover o google analytics e isso não fez muita diferença, minha pontuação foi de cerca de 50 - 60 para desempenho.

Algo que é realmente intrigante para mim é que apenas a página inicial (index.js) está obtendo uma pontuação muito baixa, enquanto outras páginas, como a página de serviços ou a página de contato, estão obtendo uma pontuação de ~ 80. Construí este site de forma bastante consistente e, portanto, não há uma diferença enorme entre as páginas e, ainda assim, por algum motivo, a página inicial tem uma pontuação de ~ 50, enquanto as páginas de serviços têm uma pontuação de ~ 80.

Como mencionei antes, com o lighthouse v5, a pontuação foi de ~ 90, simplesmente não faz sentido que um site simples como este agora teria uma pontuação baixa de ~ 50.

Aliás, algum de vocês tentou definir a imagem acima da dobra como eager ?
Isso desativa o carregamento lento e pode aumentar a pontuação. O desfoque ou SVG
efeitos de carregamento podem ser confusos no Farol (que, se for o caso, é
uma falha em seu algoritmo).

No sábado, 13 de junho de 2020, 10:48 t2ca [email protected] escreveu:

Algo simplesmente não combina para mim. Eu construí um site muito simplista
com cerca de uma imagem por página, estou usando SVG para imagens sem imagem gatsby,
Também tentei remover o google analytics e isso não ajudou muito
diferença, minha pontuação foi de cerca de 50 - 60 para desempenho.

Algo que é realmente intrigante para mim é que apenas a página inicial
(index.js) está obtendo uma pontuação muito baixa, enquanto outras páginas como o
página de serviços ou a página de contato estão obtendo uma pontuação de ~ 80. Eu construí isso
site bastante consistente e, portanto, não há uma grande diferença entre
páginas e ainda por algum motivo a página inicial tem uma pontuação de ~ 50 enquanto o
páginas de serviços tem uma pontuação de ~ 80.

Como mencionei antes, com o lighthouse v5, a pontuação foi de ~ 90, apenas
não faz sentido algum que um site simples como este agora teria um baixo
pontuação de ~ 50.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

@KyleAMathews Sim , e isso aumentou significativamente a pontuação de desempenho e as primeiras tintas. É o que descrevi como ponto 2 em meu longo comentário acima. Cancelar o fadeIn é o que finalmente deixou LH feliz.

Edit : Eu, provavelmente por ignorância, sinto que o foco em LCP não é a abordagem correta a ser adotada universalmente com relação às imagens. Obviamente anedótico, mas eu sinto que um site parece muito mais rápido quando todo o conteúdo é carregado e as imagens desaparecem depois, a menos que a imagem seja crucial para o conteúdo.

Um exemplo comum seria um artigo do Medium. Claro, você poderia dizer que é uma falha de design, mas a maioria dos artigos do Medium (e muitos outros blogs) começam com uma grande e velha imagem no topo que é apenas para criação de clima ou cenário e eu não me importo se carrega .

Aliás, algum de vocês tentou definir a imagem acima da dobra como eager ? Isso desativa o carregamento lento e pode aumentar a pontuação. Os efeitos de desfoque ou carregamento de svg podem ser confusos no Lighthouse (o que, se for o caso, é uma falha em seu algoritmo).
…

Vou tentar isso agora.

Acho que fiz bons progressos aqui. Aumentei minha pontuação de 57 para 84 com mudanças muito básicas. Meu LCP passou de 12s para 2s .

Dito isso, é inconsistente. Desde que fiz as alterações que descreverei abaixo, minha pontuação varia de 69 a 84. Há claramente alguma variação aleatória nas pontuações de desempenho.

TLDR

Primeiro, como @KyleAMathews e @Jimmydalecleveland sugeriram, tentei definir loading="eager" e fadeIn={false} nos componentes da imagem gatsby que estavam acima da dobra.

Em seguida, me livrei de base64 das minhas consultas.

Isso fez uma grande diferença.

O bom

• Adicionar _noBase64 aos fragmentos de imagem aumentou minha pontuação em 20 pontos!

  • Parece que as imagens base64 estão adicionando muito peso aos dispositivos móveis. Estou pesquisando imagens de conteúdo usando localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 .

• loading="eager" e fadeIn={false} reduziram meu tempo de pintura com maior conteúdo em cerca de 50%!

  • Minha pontuação de desempenho real só subiu de 6 a 7 pontos por algum motivo, mas o LCP está definitivamente progredindo ...

Minha consulta é semelhante a esta:

localFile {
  childImageSharp {
      fluid(maxWidth: 800, quality: 100) {
        ...GatsbyImageSharpFluid_withWebp_noBase64
      }
   }
}

E meu gatsby-image parece com isto:

<Image 
  fluid={localFile.childImageSharp.fluid}
  fadeIn={false} 
  loading="eager"
/>

O menos bom

Minha UX no meu site agora parece muito pior. O fade in base64 + forneceu uma grande UX. Agora, está um pouco instável. Eu acho que é uma troca que temos que considerar agora.

Antes e depois de eager & fadeIn={false}

Aqui estão algumas comparações lado a lado das mesmas páginas. A única diferença é que à direita, as imagens têm loading="eager" e fadeIn={false} .

1. Página inicial

LCP caiu 49%. Pontuação de desempenho de até 6 pontos.

2. Página do produto

LCP caiu 46%. Pontuação de desempenho de até 7 pontos.

O que há de estranho neste exemplo acima: as capturas de tela à esquerda têm o comportamento padrão da imagem gatsby (elas aparecem e não têm eager ativadas.) E ainda, embora a pontuação de desempenho seja inferior , as pequenas capturas de tela na parte inferior fazem com que pareça que está carregando mais rápido do que a imagem à direita.

Talvez esteja dentro da margem de erro de como eles julgam o desempenho, ou talvez seja um bug relacionado ao fade em vigor, como @KyleAMathews mencionou.

Depois de definir _noBase64 em fragmentos de imagem

Aqui estão as mesmas telas do exemplo acima. Todos eles têm loading="eager" , fadeIn={false} adereços na imagem de Gatsby. Além disso, os fragmentos de imagem no graqhql são GatsbyImageSharpFluid_withWebp_noBase64

É um pouco inexplicável, mas estou executando um teste de farol na mesma página repetidamente e obtive 84, 75 e 69.

Meio estranho, mas de qualquer forma, aumentou minha pontuação.

Eu acho que o algoritmo do Farol estava parecendo excepcionalmente generoso aqui lol ^

Após uma investigação mais aprofundada, descobri que o farol estava reclamando de um elemento específico que estava impactando a pontuação do LCP.

Tudo o que fiz foi simplesmente mover este elemento, que é apenas um parágrafo, e minha pontuação saltou acima de 80. Vai entender. Não tenho certeza de por que mover um parágrafo aumentou minha pontuação de ~ 50 para ~ 80.

@nandorojo Obrigado pelo artigo completo. Não tentamos remover base64 completamente, mas seria uma chatice se precisássemos. Também colocamos o carregamento antecipado apenas na primeira imagem da página, então, se você ainda não estiver fazendo isso, vale a pena tentar se você puder controlar isso.

Após uma investigação mais aprofundada, descobri que o farol estava reclamando de um elemento específico que estava impactando a pontuação do LCP.

Tudo o que fiz foi simplesmente mover este elemento, que é apenas um parágrafo, e minha pontuação saltou acima de 80. Vai entender. Não tenho certeza de por que mover um parágrafo aumentou minha pontuação de ~ 50 para ~ 80.

@ t2ca Foi isso que eu consegui (embora a minha fosse uma tag de cabeçalho). Mas para onde você o moveu?

@ t2ca Foi isso que eu consegui (embora a minha fosse uma tag de cabeçalho). Mas para onde você o moveu?

@michaeljwright A primeira coisa que fiz foi excluir o parágrafo e verificar a pontuação do farol. Depois de remover o parágrafo, minha pontuação aumentou cerca de 20 pontos. Repeti o teste muitas vezes apenas para ter certeza. Eu também coloquei o parágrafo de volta e fiz mais testes e minha ferida estava mais baixa novamente.

Finalmente, decidi apenas mover o parágrafo, estou usando framer-motion dentro de uma div e acabei de mover o parágrafo fora da div. Isso me dá o mesmo resultado de quando excluí o parágrafo.

@ t2ca Acho que o LCP penaliza qualquer animação em nossas páginas de herói, o que é uma chatice.

Aqui estão minhas pontuações de LCP onde a tag de parágrafo é o LCP

Com animação:

Sem animação:

@ t2ca Acho que o LCP penaliza qualquer animação em nossas páginas de herói, o que é uma chatice.

Aqui estão minhas pontuações de LCP onde a tag de parágrafo é o LCP

Com animação:

Sem animação:

@ daydream05 Obrigado por confirmar!

@ daydream05

Isso não iria contra o funcionamento da imagem de gatsby? Além disso, a maioria dos CMSs lida com a transformação da imagem no servidor e hospedada em seu próprio CDN. (O que é uma coisa boa, imo). Mas se o hospedarmos em nosso próprio site, isso não seria contraproducente também?

Não, porque gatsby-image também funciona com imagens locais, não há necessidade de hospedá-lo em um CDN diferente. Tudo se resume a otimizar sua primeira renderização (o que está na janela de exibição). Hospedá-lo em um domínio / CDN diferente significa que você precisa abrir uma nova conexão (dns resolve, tls handshake, ...) isso pode levar até 300 ms em um dispositivo lento e então você ainda tem que baixar sua imagem.

Adicionando ao que @Undistraction disse, Gatsby é rápido, mas se não for rápido de acordo com os olhos do Google, então se torna problemático. Especialmente porque eles estão incluindo isso na atualização do ranking da

Estaremos otimizando Gatsby ainda mais para garantir que nossos usuários possam obter 100 gratuitamente.

@ t2ca Acho que o LCP penaliza qualquer animação em nossas páginas de herói, o que é uma chatice.

Isso é esperado porque sua tela nunca para de pintar. Normalmente, o LCP deve ignorar as animações CSS, mas isso depende de como você faz as animações.

@ t2ca

Se você pode nos mostrar o site, podemos ajudar a descobrir como melhorá-lo, mas provavelmente está deixando a imagem muito animada.

@nandorojo

Redação incrível! Alguma chance de você nos fornecer links para os relatórios do farol?

Isso é esperado porque sua tela nunca para de pintar ...

@wardpeet , você se importaria de expandir isso, por favor?

@DannyHinshaw recebi essa explicação do farol
“O que eu acho que está acontecendo é que o LCP se preocupa com as imagens totalmente carregadas e o tempo relatado é quando a imagem está completamente carregada e não quando é visível pela primeira vez. Este tempo pode ser diferente devido às imagens progressivas e tintas iterativas. "

E então este link, talvez de ajuda
https://web.dev/lcp/#when -is-maior-contentful-paint-reportado

Nesse ínterim, o que você também pode tentar é mudar o seu Largest Contentful Paint (LCP) de uma imagem para texto (se você tiver o luxo), pré-carregar / pré-buscar fontes e carregar lentamente as imagens. No meu caso, isso significou reduzir o tamanho da imagem do herói no celular, o que impulsionou nossa pontuação de volta aos 90, enquanto o problema estava sendo discutido.

import semiBoldFont from 'static/fonts/SemiBold-Web.woff2';
...
<Helmet>
   <link rel="prefetch" href={semiBoldFont} as="font"></link>
</Helmet>

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwhatsmypayment.com%2F
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

Isso é esperado porque sua tela nunca para de pintar ...

@wardpeet , você se importaria de expandir isso, por favor?

Claro que não sei que site era este, tentei encontrar URLs neste tópico, mas foi difícil. LCP não leva em conta animações CSS (transição, adereços de animação em css). No entanto, se você tiver conteúdo que usa setTimeout / setInterval que alterna o componente de reação, ele o levará em consideração. A última abordagem resultará em pontuações CLS realmente ruins.

Então, se você quiser animar o texto / imagem do herói. Use animações css.

Olá,

Tentei descobrir por que meu projeto está tendo uma pontuação tão baixa no Google Page Speed ​​Insights, auditoria do Google Lighthouse e muito mais.

A não ser começar do zero, não tenho certeza de qual é o problema. Usei este iniciador / tema para começar: https://github.com/alexislepresle/gatsby-shopify-theme

Eu principalmente e estou no processo de mudar coisas de CSS, como passar de bulma para chakra-ui.

Este é meu repositório: https://github.com/Chizzah/genesis-style
Tentei remover todas as coisas da conta e gatsby-plugin-appollo-shopify, mas isso não mudou as coisas.

Aqui está o link ao vivo: https://genesis-style.netlify.app

Parece que nada do que faço muda as coisas. Eu preferiria não ter que começar do zero. Se alguém puder me dar uma dica ou algo assim, eu agradeço.

Acho que me acostumei muito com Gatsby dando 90-100s grátis

Obrigado por este tópico, pois uma discussão sobre como conseguir boas pontuações de farol é necessária. Pontuações excelentes tornaram-se mais difíceis com a v6, principalmente devido à nova métrica LCP. Meu site (https://www.jamify.org) caiu de ~ 100 para ~ 70 com o Lighthouse v6.

A fim de trazê-lo de volta para 100 no desktop, eu tive que

• remova uma imagem de fundo que não era necessária (pois foi escolhida incorretamente como LCP)
• otimizar o tamanho das imagens
• defina gatsby-image para loading="eager" e fadeIn=false
  (isso é realmente uma chatice, pois gosto do efeito de desfoque)

No celular, ainda estou preso no 80, novamente devido a um LCP de 5 segundos. Isso pode ser melhorado com o dimensionamento adequado de imagens especificamente para celular:

No geral, essas otimizações são bastante viáveis, no entanto, estou bastante infeliz por agora ter que escolher entre imagens de carregamento lento com desfoque ou uma boa pontuação Lighhouse: roll_eyes:

Alguém já fez algum teste no farol v6.1? Eu percebi uma melhora na minha pontuação de desempenho.

Perguntou ao Addy do Google sobre o problema de desfoque do LCP e é algo que eles estão trabalhando para corrigir https://twitter.com/addyosmani/status/1277293541878673411

A lição aqui é não tratar as novas pontuações de desempenho como absolutas ainda - elas ainda estão refinando casos extremos.

Eu acredito que o problema fica pior com o Lighthouse 6.1. Existem algumas boas sugestões aqui em torno do LCP, mas não estamos olhando muito para o TBT, o que eu acho que é o maior motivo para pontuações ruins no celular e o mais difícil de resolver.

Você pode testar o Lighthouse 6.1 no Chrome Canary. Eu comparei meu site entre 6.0 e 6.1, assim como vários outros mencionados aqui e o TBT aumentou drasticamente. Por exemplo, em meus testes 6.1:

• gatsbyjs.org TBT: 2550ms
• meu site TBT: 2200ms
• TBT do site @styxlab : 1250 ms

Qualquer coisa acima de 600 para TBT é vermelha e o peso de acordo com a calculadora é de 25%, então um fator importante. O TBT é causado por funções que levam mais de 50 ms para serem executadas entre o FCP e o tempo de interação.

A imagem acima é um perfil do meu site. Se você usa o Lighthouse no Chrome, pode clicar no botão Exibir rastreamento para carregar os resultados na guia do perfil para ver o mesmo. Qualquer tarefa após FCP com uma bandeira vermelha no canto conta para TBT. Ainda estou para me aprofundar em quais são as tarefas, então talvez alguém com mais conhecimento de Gatsby possa ajudar nessa área e talvez @wardpeet possa dar sua visão sobre o TBT, se possível. Existem algumas tarefas grandes que levam entre 500ms - 1s em meus testes, então acho que devem ser analisadas.

@IanLunn esse é um traço interessante, você conseguiu ter uma noção do que essas tarefas eram?

É provável que haja uma correlação entre quanto JS cada site Gatsby tem e quão caro ele se torna no thread principal do navegador. No entanto, acho que a sala aberta para discussão poderia ser, há uma maneira de Gatsby ajudar a "mitigar" o impacto por meio da forma como carrega consultas e scripts juntos?

Existem três áreas que estou tentando entender melhor no momento:

• Gatsby adiciona por padrão <link rel=preload/> para cada script necessário (de acordo com o padrão PRPL ), independentemente de quantos estão lá. Eu notei algumas diferenças no FCP medido (o que me surpreendeu bastante), mas principalmente na lacuna entre FCP / LCP ao removê-los (o que provavelmente não é uma ideia brilhante fazer sem outras alterações). Esta edição do farol discute o último.
• As consultas acabam criando JSONs (page-data.json e os hash para consultas estáticas) que são avaliados no thread principal. Veja https://github.com/gatsbyjs/gatsby/issues/18787 mas não parece que encontramos (ou se houver) uma alternativa que não bloqueia o tópico principal. Quanto maiores os dados, maior o impacto no desempenho (portanto , os orçamentos de desempenho para tamanhos de consulta certamente seriam muito bem-vindos) - mas os dados não são realmente necessários até o processo de reidratação, ou são?
• Os pedaços reais são adicionados como <script src=foo.js async /> no final de </body> . Isso significa que assim que o navegador terminar de analisar o HTML (que deve estar logo no rastreamento), ele começará a analisar e executar esses scripts (já que eles já estavam pré-carregados). Tarefas longas surgirão inevitavelmente, pois o thread principal é solicitado para analisar e executar todo esse javascript. Existe uma maneira melhor de lidar com isso (pelo menos _quando_ esses scripts começarem a ser analisados) para evitar o bloqueio do thread principal? Existe alguma maneira de fazer isso (a análise ou a execução) em pequenas tarefas incrementais que não atrasam o feedback de entrada (e, portanto, prejudicam o TTI), nem bloqueiam o encadeamento principal em intervalos de tempo (e, portanto, prejudicam o TBT)?

Embora no momento seja verdade, os sites de Gatsby estão sendo um pouco penalizados devido ao LCP ainda não reconhecer o padrão LQIP de gatsby-image - quando se trata de qualquer coisa relacionada a TBT / TTI (e possivelmente uma grande penalização no custo de Javascript comparado ao Farol v5) Não acho que haja algo no roteiro da equipe do farol onde as coisas irão melhorar em relação às pontuações atuais.

@juanferreras A maior tarefa parece ser domready / ready.js (terceiro). Tenho a impressão de que sua declaração sobre o farol penalizador de JavaScript está correta e, embora pequenas otimizações possam ser possíveis em Gatsby, não é algo solucionável.

Se é assim que vai ser no Lighthouse, estou tentado a pelo menos pedir que diminuam o peso do TBT ou dêem a opção de definir o ambiente de teste desejado. Fornecer uma pontuação com base em um telefone de orçamento nem sempre é apropriado para o site que está sendo testado. Devemos ser capazes de mostrar aos chefes / clientes que sim, um telefone barato obtém uma pontuação de 75, mas um telefone de gama alta que 95% dos nossos usuários têm obtém uma pontuação de 90, por exemplo.

• As consultas acabam criando JSONs (page-data.json e os hash para consultas estáticas) que são avaliados no thread principal. Consulte # 18787, mas não parece que encontramos (ou se houver) uma alternativa que não bloqueia o thread principal. Quanto maiores os dados, maior o impacto no desempenho (portanto , os orçamentos de desempenho para tamanhos de consulta certamente seriam muito bem-vindos) - mas os dados não são realmente necessários até o processo de reidratação, ou são?

@juanferreras , com relação a essa questão de analisar dados json no thread principal, o que vem à mente é o web worker. Gatsby pode registrar um web worker, se disponível no cliente, e armazenar esse tipo de coisa nele, o processo de reidratação não é realmente necessário imediatamente, então acredito que seja possível

O Web worker é compatível com os principais navegadores, incluindo o ie10.

… Não estamos olhando tanto para o TBT, que eu acho que é o maior motivo para pontuações ruins no celular e o mais difícil de resolver.

Quero adicionar algo que acho relevante para o Tempo de bloqueio total. Depois de revisar meus pacotes com o analisador de pacote Webpack, percebi que os dados de consultas estáticas estão incluídos nos pacotes JavaScript. Tenho certeza de que há um bom motivo para isso, mas funciona contra um TBT baixo.

TBT é um problema difícil de resolver, especialmente porque o React não foi feito para isso. Passar para o pré-ato é um bom primeiro passo. Estaremos melhorando o TBT cada vez mais nos próximos meses, queremos que Gatsby tenha uma pegada realmente pequena.

Na versão gatsby> 2.24.0, fornecemos suporte a polyfill aprimorado, portanto, carregamos polyfills apenas em navegadores legados como o IE11. Também removemos as consultas estáticas do webpack há alguns dias (@MarkosKon).

@Teclone infelizmente, webworkers não são bons para análise JSON. Você ainda paga o preço pela serialização e desserialização entre threads. Com ShardArrayBuffer seria uma história diferente, infelizmente eles estão desabilitados por padrão por causa de Meltdown / espectro

Eu estava obtendo 100/100 em tudo no farol integrado (6.0) no Chrome e, em seguida, usei a versão web.dev (6.1) e ele voltou com desempenho na década de 70 devido ao LCP (cerca de 5-6 segundos em 6,1, cerca de 0,5 segundos em 6,0). É uma imagem decorativa de cabeçalho (usando gatsby-background-image) da qual ele está reclamando.

Olhando para meu próprio site, o tempo de execução do Webpack tem o maior tempo de execução de javascript. Algo que a página nem precisa até que o usuário comece a interagir com a página.

Gatsby parece carregar todos esses recursos (pedaços) de uma vez. O arquivo js em si é muito pequeno, é um carregador, você pode ver que leva apenas 2ms para passar o arquivo. Mas o próprio arquivo carrega pedaços e arquivos de modelo.

Na verdade, quando inspeciono os arquivos em bloco, descubro que todos eles são importações dinâmicas, que, esperamos, sejam carregados apenas quando são necessários, mas não, todos eles são carregados por padrão. Esse comportamento não é o que eu esperava.

Otimizamos bastante a imagem do nosso cabeçalho, como usar uma imagem diretamente em vez de Gatsby-Image e reduzir a resolução e a compactação, e a nossa é um pouco melhor. Apenas descobri da maneira mais difícil que o Safari não oferece suporte a WebP (grr). E continua sendo o caso de que a versão web do Lighthouse é muito menos indulgente do que a integrada no Chrome, pelo menos para nosso site de desenvolvimento "oculto". O tempo dirá se os dados agregados do usuário ajudam quando estiverem ativos - não estou convencido de que haja tantos usuários do Moto G5 no mundo real!

@derykmarl Deve ter suporte em breve: https://www.macrumors.com/2020/06/22/webp-safari-14/
Não entendo por que a Apple demorou tanto para oferecer suporte a um formato de imagem difundido ...

Eu li que o pagespeedinsight emula como a pontuação é calculada. Parece que eles não limitam a rede, então você pode obter seu relatório mais rápido. Eu pessoalmente uso https://lighthouse-metrics.com/, mas eles não são compatíveis com o 6.1 ainda.

O problema com o farol 6.x é que ele depende do tempo de percepção, você pode executar o mesmo teste 10 vezes e não terá os mesmos resultados dependendo das condições da rede.

voltou com desempenho na década de 70 devido ao LCP

Eu tinha um LCP que era a imagem de fundo do meu site, fui capaz de reduzir drasticamente meu LCP dividindo a imagem em 6 sub-imagens. Eu fiz um script python para fazer isso facilmente, contanto que você saiba a altura que deseja que cada um de seus segmentos tenha

from PIL import Image
import os
import ntpath

def crop(pathToFile, height, width=False):
    im = Image.open(pathToFile)
    imgwidth, imgheight = im.size
    [name, ext] = ntpath.basename(pathToFile).split('.')

    if(not width):
        width = imgwidth

    k=1
    for i in range(0,imgheight,height):
        for j in range(0,imgwidth,width):
            box = (j, i, j+width, i+height)
            a = im.crop(box)
            a.save(os.path.join("./" + name + "-" + str(k) + "." + ext), compress_level=9, optimize=True)
            k +=1

pathToFile = '/path/to/your/img.jpg'
crop(pathToFile, 933)

Também descobri que este site de compactação de imagens funciona muito bem para reduzir o tamanho da imagem sem perder muita qualidade. Normalmente, eu poderia descer até a marca de qualidade de 20% -30% e reduzir drasticamente o tamanho do meu arquivo.

Eu fiz algumas perguntas sobre isso online e algumas pessoas recomendam que eu só divida minha imagem em 2, acima e abaixo da dobra, mas descobri que dividir em 6 funciona muito melhor.

@wardpeet na nota TBT / TTI, podemos ver como outros sites baseados em reação agora estão mitigando o impacto geral no thread principal do navegador.

O próprio reactjs.org (que também é construído com Gatsby até onde eu sei) parece ter um TTI consideravelmente menor (7-8 ~ vs 12 ~) do que o novo gatsbyjs.com (parabéns pelo lançamento!). NextJS também manteve números muito bons em TTI / TBT, apesar de serem baseados no React (também pode ser devido ao tamanho relativo dos scripts - onde gatsby.com tem cerca de 628,3 kb de script de acordo com PSI, reatjs.org 466,1 kb e nextjs.org apenas 216,8kb)

(esta é obviamente uma única execução e não deve ser usada como uma comparação real, mas a tendência é bastante consistente em várias execuções).

A maior parte da diferença de pontuação se deve ao Custo geral de Javascript ™? Se a equipe de Gatsby otimizar o novo site em algum momento, isso pode ser uma grande oportunidade de compartilhar alguns insights sobre o processo, desde que não haja muita mágica para adicionar em como o framework gatsby já lida com javascript internamente.

@juanferreras @wardpeet , Também há algo que descobri em meu próprio projeto. Se você estiver usando componentes estilizados, por alguns motivos, os estilos são recalculados / regenerados durante a hidratação e reinjetados no navegador. Isso ocupa muito do tópico principal.

Isso se deve a problemas de hidratação em gatsby. https://github.com/styled-components/styled-components/issues/2171

Gatsby também está trabalhando para executar o ssr durante o desenvolvimento, https://github.com/gatsbyjs/gatsby/issues/25729 , isso ajudará a pescar esse tipo de problema de desempenho. também.

@teclone

https://github.com/styled-components/styled-components/issues/2171 não parece oferecer solução. Como você corrigiu isso no seu projeto?

@dfguo , por enquanto, não há solução para isso, porque ninguém sabe exatamente por que os estilos se regeneram durante a reidratação, porque o gatsby na produção não oferece ajuda no desenvolvimento com erros de reidratação.

Ou seja, não há log do console do React apontando diferenças durante a reidratação porque ele está desabilitado na construção de produção do gatsby.

O objetivo deste trabalho em andamento # 25729 é executar o verdadeiro SSR em desenvolvimento, portanto, poderemos ver por quê. incluindo a equipe gatsby.

BTW, você pode construir um site Gatsby com gatsby build --no-uglify para construir seu site com a versão de desenvolvimento do React para ver os logs. https://www.gatsbyjs.com/docs/gatsby-cli/#build

O Dev SSR será muito útil no futuro para coisas como essa!

Portanto, decidi migrar meu site de @emotion e theme-ui para linaria enquanto implementava o modo dark-light com variáveis ​​css personalizadas

O objetivo era reduzir o tempo de bloqueio / thread principal / qualquer coisa relacionada a js, uma vez que agora css não são mais avaliados em tempo de execução, mas compilados em tempo de construção (na verdade linaria parece muito mais alinhado a gatsby declarações do que @emotion este respeito)

O processo não é totalmente tranquilo, a maioria das coisas que fiz com @emotion apenas funcionam com linaria , mas alguns outros não e você tem que reescrevê-los e / ou reimplementá-los por meio de um CSS personalizado variáveis

A experiência DX com gatsby é __bad__, o recarregamento a quente não funciona (você tem que parar e começar novamente a qualquer mudança, pois o navegador parece perder a conexão), mas no geral o processo tem sido bom, pois força você a ser mais consciente sobre o que você realmente precisa das habilidades de tempo de execução do @emotion

__Dito isso, as métricas do farol são muito semelhantes__

Eu posso comparar as duas implementações do netlify e, na verdade, o site @emotion tem 70 anos e o site linaria tem 70 baixos-médios

Nem preciso dizer que não estou muito animado

Analisando o pacote:

• o documento do site aumentou de 14 Kb para 28 kb
• o script do framework permaneceu idêntico em 38,7 kb
• O script do aplicativo diminuiu de 58,2 kb para 46,1 kb
• E um quarto script ( component--content.. . Então, 20bae078.. agora) foi de 44,2 kb para 46,8 kb

Então, presumo que os estilos em js mudaram para estilos em css (e ~ 12 kb são IMO significativos), mas isso não teve nenhum impacto real nas métricas do farol (e é isso que importa, não é?)

Portanto, não estou dizendo que mudar para linaria não faz sentido, não ficaria surpreso se alguém fizesse o mesmo e obtivesse melhores resultados (em teoria, esse deveria ser o caso (?)), mas em minhas mãos o processo não valeu a pena

Ainda assim, explorando o script do aplicativo, abri um novo problema tentando descobrir como reduzir o js bundle https://github.com/gatsbyjs/gatsby/issues/26655

A experiência DX com gatsby é ruim , o recarregamento a quente não funciona (você tem que parar e começar novamente a qualquer mudança, já que o navegador parece perder a conexão), mas no geral o processo tem sido bom, pois o força a ser mais consciente sobre o que você realmente precisa das habilidades de tempo de execução do @emotion

@kuworking Eu encontrei um problema semelhante, mas notei que isso só acontecia em gatsby versões anteriores a 2.24.9 ; Não tenho certeza se a causa é a mesma, mas achei que poderia ajudar alguém saber que as pessoas estão falando sobre isso na edição # 26192 .

@kuworking Eu encontrei um problema semelhante, mas notei que isso só acontecia em gatsby versões anteriores a 2.24.9 ; Não tenho certeza se a causa é a mesma, mas achei que poderia ajudar alguém saber que as pessoas estão falando sobre isso na edição # 26192 .

Eu estive com "gatsby": "2.24.14" por várias semanas, eu diria, e até agora só experimentei isso com linaria
Mas sabendo disso, não atualizarei o gatsby até que isso seja descoberto, obrigado 👍

@kuworking O que eu quis sugerir é que talvez se você 2.24.9 , o problema de parada do servidor de desenvolvimento não aconteceria mesmo com linaria ; mas isso é apenas uma ideia. Ficaria curioso para saber se é esse o caso.

A experiência DX com gatsby é ruim , o recarregamento a quente não funciona (você tem que parar e começar novamente a qualquer mudança, já que o navegador parece perder a conexão), mas no geral o processo tem sido bom, pois o força a ser mais consciente sobre o que você realmente precisa das habilidades de tempo de execução do @emotion

Você tentou uma atualização rápida ?

Recentemente, migrei um site gatsby de produção (~ 120 páginas) para pré-agir na esperança de melhorar o TBT e LCP. Nosso site usa svg pesado com componentes react svg gerados com svgr e estilizados usando materiais-ui styles. Os resultados de desempenho médio ficaram na faixa de + -5 da pontuação inicial (~ 45 desempenho móvel de ~ 85 antes da v6) e, embora a migração tenha sido relativamente fácil usando o tema, ela exigiu uma migração para atualização rápida, não.

Honestamente, um pouco desapontado por não haver nenhuma outra otimização que eu possa encontrar para tentar ou métricas mais detalhadas para disparar além do aviso genérico de farol "Remover javascript não utilizado".

A velocidade é um dos principais motivos pelos quais escolhemos o gatsby e, embora as páginas ainda carreguem rápido, é difícil justificar do ponto de vista de SEO quando suas pontuações de insight são tão afetadas ...

sussurros: Mudei para NextJS e estou obtendo melhores pontuações 🤭

sussurros: Mudei para NextJS e estou obtendo melhores pontuações 🤭

E quanto a Svelte?

Seria bom saber se os desenvolvedores de Gatsby estão dando a isso algum senso específico de importância / prioridade no roteiro (além do esperado), uma vez que presumo que não haja soluções imediatas, mas talvez algum tipo de direções e implementações futuras focadas em isso ou aquilo

Já que gatsby faz alguma compilação com gatsby-node *, eu me pergunto se eles estão explorando maneiras de aumentar essa parte e desalavancar a parte do cliente

* Para diminuir o pageContext que eu estava usando (dados sobre todas as postagens publicadas), estou armazenando (por meio de gatsby-node ) a maioria desses dados em json arquivos e buscá-los se necessário no site, o que reduz o tamanho do pacote, mas também parece mais lógico

Não fique muito preocupado com as pontuações do farol - especialmente quando eles estão
significa uma referência em relação a outros sites, e não uma meta onde devemos
esforce-se para alcançar uma pontuação perfeita.

Não foi até recentemente que gatsby estava acertando 100s puro - claro, lá
são alguns problemas a serem resolvidos, mas o jogo de SEO agora é velocidade e conteúdo
mais links, e nós temos tudo coberto.

Meus dois centavos.

Na sexta-feira, 28 de agosto de 2020, 16:57 kuworking, [email protected] escreveu:

sussurros: Mudei para NextJS e estou obtendo melhores pontuações 🤭

E quanto a Svelte?

Seria bom saber se os desenvolvedores de Gatsby estão dando a isso algum
senso de importância / prioridade no roteiro (diferente do esperado
um), uma vez que suponho que não há soluções imediatas, mas talvez alguns
tipo de direções futuras e implementações focadas neste ou naquele

Já que gatsby faz alguma compilação com gatsby-node *, eu me pergunto se eles
estão explorando maneiras de aumentar essa parte e desalavancar a parte do cliente

* Para diminuir o pageContext que eu estava usando (dados sobre todos
as postagens publicadas), estou armazenando (por meio do gatsby-node) a maioria
desses dados em arquivos json e buscá-los, se necessário, no site,
o que reduz o tamanho do pacote, mas também parece mais lógico

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

Desculpe pela resposta tardia, há muita coisa relacionada ao desempenho e as métricas de carga são apenas uma pequena peça do quebra-cabeça. Estamos motivados neste trimestre e no próximo a diminuir o tamanho de Gatsby e reduzir o TBT. Os maiores problemas no momento são o tamanho do pacote React, MDX, páginas grandes (conteúdo / estilo), scripts de rastreamento e fontes / imagens como conteúdo principal no primeiro carregamento.

No momento, estou pesquisando scripts de imagem e análise de gatsby para ver como podemos melhorar o tempo de carregamento e adiar análises.

Infelizmente, não posso dar nenhuma estimativa. Também estamos olhando nosso site .com e nossos clientes para ver quais são os problemas comuns, para que possamos assar essas otimizações no gatsby ou em nossos plug-ins.

Editar:

Fico feliz em olhar para qualquer um de seus códigos-fonte para obter mais informações sobre o que todos vocês estão fazendo e como podemos melhorar.

Fiz um post no reddit onde tentei agregar todas as dicas de melhoria que pude encontrar. Se você puder sugerir mais dicas, liste-as

Remover apenas a imagem gatsby (

Em alguns testes recentes que eu estava fazendo, descobri que o uso de tracedSVG na verdade melhorou drasticamente a pontuação de desempenho da pintura com maior conteúdo. Eu imagino que isso será corrigido no Lighthouse, mas a partir de agora isso acontece porque o SVG é considerado ter as mesmas dimensões da imagem de resolução total, então ele nunca muda do SVG como o destino LCP para a imagem completa.

Ao usar base64, a resolução pequena o torna um candidato ao LCP, então o Lighthouse usa a imagem de resolução total sempre que carrega.

Portanto, se você não se importa com a aparência dos SVGs rastreados (eu os prefiro pessoalmente), experimente.

Por que v5 resulta mais melhor do que v6? Estou usando o NextJS, o resultado sempre muda de 60 para 85.

+1

Tenho trabalhado em um sucessor de imagem gatsby. Ainda não está 100% lá, ainda é necessário escrever uma versão composta para que você possa criar seu próprio sabor da imagem gatsby, mas isso corrigirá a maioria das pontuações ruins do farol.

Você já pode usá-lo, mas ainda não foi testado em batalha.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

Você pode instalá-lo por npm install --save @wardpeet/gatsby-image-nextgen . Existe uma camada de compatibilidade para os usuários atuais do gatsby-image .

Coisas que ainda não são suportadas:

• o ajuste do objeto deve ser feito por css fora do componente
• direção da arte

Demonstração da imagem gatsby atual:
site: https://wardpeet-using-gatsby-image.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

Nova demonstração gatsby-image-nextgen:
site: https://gatsby-image-nextgen.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fgatsby-image-nextgen.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet Seu link pagespeed-insights para a demonstração atual vai para nextgen para que eles mostrem as mesmas pontuações.
Trabalho incrível, aliás. É realmente emocionante ver o progresso.

Obrigado corrigido!

Esta atualização apontou algo para mim que eu não conectei antes, não estou usando gatsby-image mas na verdade gatsby-background-image que aparentemente não usa gatsby-image sob o capô ... Posso ter que reescrever esse componente com este novo @wardpeet/gatsby-image-nextgen se isso for possível ....

Este artigo lista algumas dicas adicionais https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/ embora eu ache que muitas delas já foram mencionadas neste tópico ...

@DannyHinshaw quando o plugin estiver completo. Vou dar uma olhada nesse plugin também. Eu tenho que olhar para as imagens de observação também

Publiquei uma nova versão de @wardpeet/gatsby-image-nextgen - 0.0.2.

1. minimiza css e js no html
2. carregamos apenas os bits necessários, quando o carregamento da imagem nativa está habilitado, carregamos apenas cerca de 2kb (sem gzip).
3. certifique-se de que o placeholder só seja chamado no primeiro carregamento, as imagens em cache carregam imediatamente
4. Corrigir animação desfocada decodificando async

Estou me perguntando quantos de vocês precisam de um componente Image composable onde possam construir seu próprio wrapper e quantos de vocês estão realmente usando direção de arte e querem isso dentro da imagem gatsby por padrão? Minha primeira ideia era desabilitar a funcionalidade, mas habilitá-la com a imagem gatsby composable, então você terá que fazer seu próprio componente de imagem para suportá-la.

Demonstração mais recente: https://gatsby-image-nextgen.netlify.app/

@wardpeet Isso é ótimo! Eu confio fortemente na direção de arte incorporada de gatsby-image. Mas eu acho que um exemplo / caminho de atualização suave também seria adequado!

Sempre recebi 99 no celular, agora um 76. Tudo está ótimo, exceto meu LCP que é 7.0 e diz que é a minha imagem de herói. Não faz sentido. Quando eu acesso meu site em qualquer celular, ele é extremamente rápido. As pessoas ficam maravilhadas, sabe? Também me diz para colocar minhas imagens em webp ou outros, mas eu já utilizo childImageSharp_withWebp, então não entendi. Estou começando a achar que Gastby Image e background-image não estão funcionando com esta nova versão no lighthouse e no pagespeedinsight. Minha mente está confusa. Eu fui e matei animações, redimensionei todas as minhas imagens pela metade e não subiu um único ponto. Estou lendo isso e não vejo nada que me ajude ... Oh, eu acabei de olhar ... E- eu acho que

@davidpaulsson se importa em compartilhar um exemplo de como você faz isso? Como a direção de arte ainda é possível com a nova imagem do gatsby, você precisa seguir alguns passos manuais.

@davidpaulsson se importa em compartilhar um exemplo de como você faz isso? Como a direção de arte ainda é possível com a nova imagem do gatsby, você precisa seguir alguns passos manuais.

Certo! Eu uso assim atualmente

const artDirection = [
  medium.childImageSharp.fluid,
  {
    ...large.childImageSharp.fluid,
    media: `(min-width: 1390px)`,
  },
];

return <Img fluid={artDirection} />

@wardpeet Hi Ward. O blurha.sh pode ser útil para a imagem gatsby nextgen?

@wardpeet Eu usei seu plugin gatsby-image-nextgen e ele de fato melhorou meu tempo de LCP (diminuiu de ~ 5s para ~ 1,5s). Obrigado por isso!

No entanto, também estamos usando direção de arte, semelhante a como @davidpaulsson está usando, e não consigo fazer com que funcione como funciona com gatsby-image.

Você poderia explicar as etapas manuais necessárias para tornar isso possível com o plugin nextgen? Obrigado novamente!

@Jimmydalecleveland Obrigado Jimmy! Substituir GatsbyImageSharpFluid_withWebp por GatsbyImageSharpFluid_withWebp_tracedSVG melhorou drasticamente a pontuação de desempenho do meu novo Gatsby Webiste. Eu não estava recebendo mais do que 54% e agora com o tracedSVG estou recebendo mais de 80%. Isso é uma grande melhoria 💯

Em alguns testes recentes que estava fazendo, descobri que o uso de tracedSVG na verdade melhorou drasticamente a pontuação de desempenho da pintura com maior conteúdo. Eu imagino que isso será corrigido no Lighthouse, mas a partir de agora isso acontece porque o SVG é considerado ter as mesmas dimensões da imagem de resolução total, então ele nunca muda do SVG como o destino LCP para a imagem completa.

Ao usar base64, a resolução pequena o torna um candidato ao LCP, então o Lighthouse usa a imagem de resolução total sempre que carrega.

Portanto, se você não se importa com a aparência dos SVGs rastreados (eu os prefiro pessoalmente), experimente.

@abdullahe Nós o verificamos antes e ele depende do canvas e o node-canvas não é super confiável. Ou pelo menos não era no passado. Avisarei se considerarmos novamente :)

@guydumais certifique-se de colocar loading="eager" pois deve alterar sua pontuação também.

@BenjaminSnoha & @davidpaulsson Vou compartilhar um exemplo daqui a pouco. O maior problema com a direção de arte se a proporção de aspecto entre as imagens mudar, como horizontal para vertical.

@wardpeet como alguém usaria @wardpeet/gatsby-image-nextgen com gatsby-remark-images ? É o caso de simplesmente apontar para ele como um plugin em gatsby-config.js , ou não é possível até que ele seja mesclado com o gatsby monorepo?

embora isso possa não ter nada a ver com o lighthouse, estou me perguntando por que os arquivos JSON de dados da página gatsby não suportam hashing de conteúdo, assim como os arquivos js.

Eu sei que o hashing de conteúdo para arquivos js é executado por Webpack, mas gatsby também pode fazer o mesmo para arquivos JSON de dados de página. isso pode economizar muitos pedidos de rede cdn

Os arquivos x em x.LONG_HASH pois o hash não é previsível. Com JS / CSS, carregar um manifesto é razoável, pois há tantos arquivos JS, mesmo em sites muito grandes. Mas com os dados da página, há um por página, então o manifesto pode crescer bastante. Costumávamos fazer isso e descobrimos em um site de 10k o manifesto já estava ~ 500k compactado. https://github.com/gatsbyjs/gatsby/pull/13004

Se você vir arquivos page-data.json baixados repetidamente - verifique se você não desabilitou o cache em seu devtools e verifique os cabeçalhos de cache com https://www.npmjs.com/package/check-gatsby-caching

@KyleAMathews , obrigado por esclarecer isso. Essa é uma abordagem muito sensata

@wardpeet é verdade que image-nextgen não suporta fadeIn="false" ou fadeIn="{false}"

Funciona muito melhor, passou de ~ 80 para ~ 95

@MelleNi não, não acho que seja necessário, mas ficamos felizes em considerar.

você pode dar uma olhada em https://github.com/gatsbyjs/gatsby/discussions/27950 para ver o que estamos enviando.

@wardpeet como alguém usaria @wardpeet/gatsby-image-nextgen com gatsby-remark-images ? É o caso de simplesmente apontar para ele como um plugin em gatsby-config.js , ou não é possível até que ele seja mesclado com o gatsby monorepo?

Vamos mover o comentário para este plugin também :)

@MelleNi não, não acho que seja necessário, mas ficamos felizes em considerar.

você pode dar uma olhada em # 27950 para ver o que estamos enviando.

@wardpeet como alguém usaria @wardpeet/gatsby-image-nextgen com gatsby-remark-images ? É o caso de simplesmente apontar para ele como um plugin em gatsby-config.js , ou não é possível até que ele seja mesclado com o gatsby monorepo?

Vamos mover o comentário para este plugin também :)

É ótimo ouvir sobre o comentário, pois vi uma grande melhora na velocidade.

No entanto, percebi que não conseguia obter 99-100 sem desativar o javascript de Gatsby (e reintegrar manualmente uma funcionalidade específica). Posso fazer com que a antiga imagem de Gatsby funcione sem javascript, usando fadeIn={false} , mas não image-nextgen. (Talvez eu esteja faltando alguma coisa, e é absolutamente possível?) Agora, sem javascript, eu nunca caio abaixo de 99 sem nextgen.

Eu entendo que desativar o javascript meio que anula a ideia de Gatsby, mas tudo bem.

Curiosamente, vi uma melhoria na pontuação de desempenho móvel (~ 70 a ~ 90) quando parei de usar fontes auto-hospedadas (fontsource) e mudei para fontes de "sistema".

@wardpeet Alguma chance de você compartilhar um exemplo de como construir um componente de imagem combinável com direção de arte? Estou no mesmo barco que @BenjaminSnoha & @davidpaulsson , e não me importo de criar o componente combinável em meu próprio projeto.

O maior problema que vejo é lidar com consultas de mídia e SSR. Bibliotecas como fresnel funcionam, mas sofrem no desempenho porque carregam todos os componentes e, em seguida, limpam o DOM depois que o componente window se torna disponível.

No meu site, parece que todas as páginas criadas com createPage têm o código-fonte (componentes markdown e markdown reage dentro do markdown) no javascript pesado da velocidade da página (Remover JavaScript não utilizado)

Acabei de lançar o Plaiceholder, que pode ser usado para criar marcadores de posição borrados CSS puros . Talvez isso seja do seu interesse? Mais do que feliz em conversar com qualquer um da equipe principal sobre as opções de encaminhamento

Eu fiz uma versão Next.js do Jamify Blog Starter que pontua bem com o Lighthouse 6.4.0 mais recente:

Você pode inspecionar o site de demonstração em next.jamify.org .

Estou postando isso aqui, NÃO para sugerir que você mude para Next.js. Em vez disso, para aprender como o mesmo pode ser alcançado com Gatsby. Acho que os principais fatores de sucesso são:

• imagens altamente otimizadas (em seguida, consegue isso com um otimizador lambda, mas isso também pode ser feito com gatsby-plugin-sharp).
• um simples placeholder svg (bons efeitos como desfoque irão desacelerar a página).
• uso de observador de interseção para mostrar imagens apenas quando em exibição (ver próximo / imagens).
• garantir o carregamento lento de imagens.
• tamanho pequeno do pacote.

Se você quiser discutir isso mais a fundo, pode me contatar no twitter .

@styxlab obtenho resultados ligeiramente inferiores em web.dev/measure

mas melhores nos resultados da postagem, definitivamente valores muito bons em qualquer caso e marcadamente diferentes da versão gatsby https://demo.jamify.org/

Também postarei que em um site mudei gatsby por 11ty e o desempenho melhorou, mas não drasticamente

(gatsby)

(design diferente, essencialmente o mesmo conteúdo, 11ty)

Ou em uma página semelhante, desta vez com uma imagem

(gatsby)

(design diferente, essencialmente o mesmo conteúdo, 11ty)

Eu direi que a experiência do desenvolvedor 11ty é muito boa (você também pode --usar experimentalmente jsx e styled-components ), mas qualquer js no lado do cliente está perdido (você pode inseri-lo e lutar com o webpack, naquele momento é onde você sente falta de gatsby)

Enquanto eu estava usando o 11ty, também estava pensando em como seria bom gatsby habilitar algum tipo de estratégia de renderização do 11ty para que se pudesse implementar páginas estáticas de reação mista e sem reação em uma estrutura ...

alguma atualização sobre isso? Não tenho nenhuma imagem e obtenho 76 no desempenho por causa do Tempo Total de Bloqueio