Gutenberg: Desempenho: Melhore o tempo de carregamento inicial e a sensação de suavidade ao digitar blocos.

Relacionado: # 11770

Posso reproduzir isso, testei com o artigo mais longo do meu blog. Convertê-lo de um bloco clássico em blocos demora um pouco, mas funciona, mas a digitação tem um atraso de mais de um segundo - muito melhor (quase sem atraso na digitação) no editor antigo. Minha velocidade de internet é de 36,2 Mbit / s de download e 8,96 Mbit / s de upload. Testar com o conteúdo de @SchneiderSam funciona melhor. Se ajudar, aqui está o conteúdo da postagem em formato HTML (para que a conversão em blocos também possa ser testada): https://gist.github.com/florianbrinkmann/4e9e4d23eaefb8b23484badddd848196

Então, se eu inserir conteúdo @florianbrinkmann , nada funciona mais para mim. Isso é muito ruim, eu não posso fazer mais nada aqui. GBerg carrega e carrega ... escreva com atraso e o Wordpress desliga.

Carregar um artigo na página do editor com o conteúdo fornecido por @florianbrinkmann leva a uma tela em branco por 44 segundos e depois a outros 56 segundos de FOIT (usando Safari 12.0.1)

... e esse teste ocorreu em um ambiente de desenvolvimento local, a propósito.

Pode confirmar que 4.3 ainda leva cerca de um minuto para carregar:

Palavras: 3451
Títulos: 29
Parágrafos: 34
Blocos: 218

A postagem é uma lista de blocos de colunas com imagens e parágrafos em cada coluna.

Depois de carregado, a digitação é muito demorada / lenta.

4.3: sim, também estamos vendo o editor desacelerar massivamente em postagens longas. Os blocos de colunas parecem estar envolvidos.

Uma informação adicional que pode ser útil são quaisquer plug-ins ativos em um site, particularmente aqueles que podem ter sido atualizados recentemente para adicionar compatibilidade com o Gutenberg †.

_ † O pensamento aqui é eliminar a possibilidade de um plugin ser implementado de forma que possa afetar o desempenho do editor._

Para mim, o único plugin diretamente integrado ao Gutenberg é o Yoast SEO, mas desativá-lo não faz nenhuma diferença perceptível no tempo de carregamento ou na digitação do tempo de resposta.

Testado com 5.0-beta4-43896 e sem plug-ins. Mesmo resultado. Especialmente com o conteúdo de florian :-)

Há uma série de solicitações pull recentes (ainda não incluídas em um lançamento de plug-in) que buscam resolver algumas degradações de desempenho relacionadas a atualizações de interface em resposta a atualizações de bloco (por exemplo, escrever em um parágrafo):

• # 11845
• # 11844
• # 11843
• # 11842
• # 11841

Um culpado adicional que notei é que ao atualizar especificamente blocos em um contexto aninhado (por exemplo, Colunas), há alguma atualização desnecessária / desperdiçadora que ocorre com os ancestrais do bloco.

_ (O GIF acima usa o recurso "Realçar atualizações" do React DevTools) _

Existem referências para antes e depois desses PRs?

@aduth e @youknowriad - Testado com GB 4.4 e: ainda é lento. Continue, não faz sentido para mim, como autor, instalar o GB se não consigo escrever corretamente. Espero que isso seja corrigido antes do Wordpress 5.0.

Eu espero muito?

Eu espero muito?

Certamente não. Posso confirmar, no 4.4.0 minha amostra de conteúdo do mundo real ainda é incrivelmente lenta para editar.

Esperançosamente, os outros PR-s relacionados podem fazer algo, e não estamos lidando com um grande problema de arquitetura aqui.

Há uma série de solicitações pull recentes (ainda não incluídas em um lançamento de plug-in) que buscam resolver algumas degradações de desempenho relacionadas a atualizações de interface em resposta a atualizações de bloco (por exemplo, escrever em um parágrafo):

• # 11845
• # 11844
• # 11843
• # 11842
• # 11841

Todos os PRs mencionados foram corrigidos com 4.4 - é por isso que escrevi novamente. Isso me preocupa:

https://github.com/WordPress/gutenberg/pull/11811#issue -230464225

Mas bem, eu não quero depreciar ninguém aqui, mas eu só estou com dor de estômago: até agora eu era um grande fã do GB, mas não tem graça.

O trabalho para melhorar o desempenho continua. É por isso que essa questão permanece aberta.

Você pode estar interessado em observar o rótulo de desempenho para ficar por dentro das novidades: https://github.com/WordPress/gutenberg/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3APerformance+

Ok, obrigado por trabalhar tão duro. Por favor, mantenha o bom trabalho. Como eu disse, a preocupação só vem porque não faltam duas semanas para o lançamento.

Obrigado!!!

retestado com o gutenberg 4.4, o conteúdo é o longo artigo de @florianbrinkmann novamente e gutenberg é o único plugin instalado no 4.9.8 rodando localmente pelo volante. 35 segundos de tela branca e outros 33 segundos FOIT.

Ei pessoal! Depois de algum trabalho investigativo sobre isso, parece-me que grande parte do problema de a digitação tornar-se lenta à medida que o número de blocos aumenta é a forma como a árvore de estados é organizada.

As informações do bloco são armazenadas em state.editor.present.blocks , com as informações para cada bloco individual em state.editor.present.blocks.byClientId . Também há state.editor.present.blocks.order , que mantém o controle da ordem dos blocos no documento.

blocks: {
   byClientId: { [ clientId ] : { name, attributes, isValid ... } },
   order: [ ... ]
}

Quando um usuário digita no bloco de parágrafo atual, isso modifica state.editor.present.blocks.byClientId[id].attributes.content . Isso significa que qualquer seletor que dependa de state.editor.present.blocks ou state.editor.present.blocks.byClientId será invalidado a cada pressionamento de tecla, tornando-o um ramo caro da árvore de depender.

Agora, existem alguns seletores que são capazes de contornar isso dependendo de state.editor.present.blocks.order . No entanto, a única informação real lá é a ID do bloco, portanto, para seletores como getGlobalBlockCount que recebem um nome opcional para filtrar, não é uma opção válida. Isso significa que getGlobalBlockCount atualmente depende de state.editor.present.blocks.byClientId e, portanto, é invalidado a cada pressionamento de tecla. Existem vários outros seletores na mesma situação.

A solução que estou procurando, por sugestão de @youknowriad , é remover os atributos de sua localização atual na estrutura da árvore e colocá-los em state.editor.present.blocks.attributesByClientId . Isso dividiria a estrutura da árvore em um ramo barato que só é atualizado quando blocos são adicionados / removidos, ou quando o tipo de bloco muda para um bloco ( byClientId ); e um branch caro que é atualizado a cada pressionamento de tecla ( attributesByClientId ).

blocks: {
   byClientId: { [ clientId ] : { name, isValid, ... } },  // Cheap
   attributesByClientId: { [ clientId ] : attributes },    // Expensive
   order: [ ... ]
}

Os seletores podem então ser modificados para depender de byClientId , attributesByClientId ou ambos, dependendo do que precisam.

Isso deve reduzir a quantidade de trabalho desnecessário em andamento, mas é difícil estimar exatamente quais serão os ganhos de desempenho. No entanto, há um tempo significativo sendo gasto no Redux com cada tecla pressionada no momento, então parece que isso pode levar a algum lugar.

Isso parece positivo. Já existe uma direção de marcha? Isso será corrigido antes do 5.0?

Estou pensando no comentário de matt:

Algumas boas medidas de sucesso para Gutenberg:

....
Eles podem criar coisas que não eram capazes de criar antes?

Acho isso uma declaração interessante. Isso é definitivamente algo que Gutenberg não pode fazer e tem falhas consideráveis. Para autores e profissionais de marketing on-line, isso é fundamental, caso contrário, posso fazer completamente sem GB.

Testei o mesmo post com o RC. 27 segundos de tela branca e 7 segundos FOIT. Ainda longe de um desempenho aceitável. : / ... e em uma nota lateral, até agora eu só tentei carregar o post com gutenberg agora na primeira vez que tentei digitar algo nele. desde a digitação de uma frase de 40 caracteres até que essa frase aparecesse de uma vez no bloco em que a digitei, levou 19 segundos.

Espero que isso seja corrigido em breve. Somos escritores e tradutores de romances. Nossos editores estão cansados ​​da baixa velocidade de digitação do GB que eles copiam no Word, editam e colocam de volta. Infelizmente, mudamos para GB em nossos sites de planos gratuitos para manter a compatibilidade ...

Não temos uma quantidade absurda de parágrafos em cada postagem, talvez cerca de 60-80 e 2 blocos separadores. Cerca de 7 a 8 páginas de conteúdo. Mesmo assim, a digitação ou exclusão ocorre com um atraso perceptível.

Todos nós temos conexões de 15-50 Mbps.

@brazenvoid Obrigado por compartilhar. Isso deve ser consertado em qualquer caso. Eu não posso trabalhar assim.

Nenhum bug de rótulo?

Não é um bug?

Gutenberg 4.5.1, WP 4.9.8

Eu testei com Gutenberg 4.5.1, WordPress 4.9.8 (nenhum outro plug-in). Com o Texto de @florianbrinkmann , inseri o HTML no editor clássico (visualização de texto), salvei, converti em blocos de Gutenberg. A conversão teve duração de 12 segundos. Agora, quando eu digito um bloco, cada letra precisa de mais de 1 segundo.

versão de desenvolvimento (5.0-RC1-43944)

--- nada mais instalado do que o plug-in de testador beta ---
Novo post, bloquear clássico -> editar como HTML -> inserir HTML copiado de Florian, publicar. Converte em blocos (12 segundos), digite um bloco, cada letra precisa de mais de 1 segundo.

Não sei se isso tem alguma relevância:
MySQL versão 5.7.19
Versão PHP 7.2.11-2+0~20181015120510.9+jessie~1.gbp8105e0
PHP max_execution_time 360
Tempo de execução máximo do PHP testado 260 segundos
Limite de memória PHP relatado 2048M (local) / 2048M (mestre)
Limite de memória PHP testado 1716 MB
Tamanho máximo de upload de arquivo PHP (relatado pelo servidor) 50 MB
Tamanho máximo da postagem: 50M
Max Input Vars: 1000

Minha velocidade de internet é 150 Mbit / s para download e 10 Mbit / s para upload

Eu também tentei alguns dos meus artigos mais longos, com mais de 2500 palavras, com 10 a 15 imagens, uma ou mais tabelas. A conversão para Gutenberg leva mais de 15 segundos para cada artigo. A digitação posterior é lenta para o mais curto dos artigos 2550 palavras e inutilizável para um artigo com 4121 palavras (mais de um segundo para cada letra), Chrome (e o mesmo no Firefox, ambas as versões mais recentes), o uso de memória aumenta rapidamente e o uso de CPU vai perto de 50%. Tudo isso é feito com uma instalação limpa do WP 5.0 RC, tema padrão e nenhum outro plug-in, no laptop Lenovo com CPU i5 8gen e 8GB de RAM. Eu não estava entrando em detalhes sobre o que o console do Chrome mostra, mas isso é inutilizável.

Isso deve ser marcado como um bug e deve ser resolvido antes que você possa pensar que o editor de Gutenberg está em qualquer lugar perto de utilizável. Se permanecer no 5.0, você pode usar Gutenberg com textos com até 1000 e um número moderado de blocos. Percebi lentidão em qualquer texto que tentei e que fica um pouco mais longo.

Duvido que qualquer desenvolvedor que esteja trabalhando nele tenha testado Gutenberg no ano passado com um texto maior do que o texto de demonstração. Eu sei que textos com mais de 3.000 palavras não são comuns, mas isso afetará não apenas textos longos, mas layouts complexos com blocos aninhados. Não consigo nem imaginar que tipo de caos começará quando blocos de terceiros forem adicionados. Ou imagine, se você tentar fazer alguma edição casual em algum laptop ou tablet mais antigo, isso será muito frustrante.

Não sei por que todos estão postando suas velocidades de internet, mas postar as informações do seu navegador pode fornecer mais informações sobre o problema em questão. O editor é executado em seu navegador. Saber por que seu navegador pode estar ficando lento seria mais útil.

Estou usando o Firefox Nightly, atualmente a versão 65.0a1 (25/11/2018) (64 bits) (no Windows 10).

Não sei por que todos estão postando suas velocidades de internet

As pessoas não entendem os detalhes técnicos aqui sempre, então provavelmente postando apenas no caso de uma perspectiva geral "lenta".

Mas, independentemente, acho que a equipe de desenvolvimento já conhece o problema arquitetônico subjacente aqui. Espero que funcione.

Também deve ser observado que todo o editor é lento, não apenas os elementos RichText. A atualização do slug do permalink (nas configurações do documento) ou qualquer outra coisa que receba entrada é lenta.

Existem 3 áreas de melhoria, tanto quanto eu vejo:

• Análise inicial e tempo de renderização - tempo para a primeira interação.
• Digitando / interagindo com blocos (# 12312)
• Interagindo com o resto do editor

@spencerfinnell O PR # 12312 deve ter um impacto no segundo e terceiro pontos.

Eu testei hoje com o conteúdo fornecido por @SchneiderSam e o problema persiste para mim. Eu testei com o Firefox no RC atual, bem como com o plugin nightly build e wp 4.9.8. Eu também testei com o Chrome. Lá ele fica um pouco lento também, mas não tão ruim quanto no Firefox.

Aqui está um screencast com meu xp: https://www.youtube.com/watch?v=yIV6REWM5tE

Ubuntu 14.04
Informações do navegador:
Nomeie Firefox
Versão 63.0.3
Build-ID 20181116161301
Agente do usuário Mozilla / 5.0 (X11; Ubuntu; Linux x86_64; rv: 63.0) Gecko / 20100101 Firefox / 63.0
Sistema operacional Linux 4.4.0-139-genérico

provavelmente não há muitas informações novas como eu vejo, a discussão sobre este tópico evoluiu bastante, queria deixá-lo de qualquer maneira.

Isso acontece mesmo sem inserir artigos com muitas palavras. A versão atual de Gutenberg fica horrivelmente suspensa, não importa o que você faça. Você pode reiniciar o navegador e esperar que ele funcione perfeitamente por cerca de meia hora.

Tenho 16 GB de RAM. Eu tenho um TI 1080. Eu tenho um processador Haswell i7. Eu nunca deveria estar experimentando QUALQUER LAG EM UM EDITOR DE TEXTO.

RC2 testado novamente com Safari 12.0.1 com Local por Flywheel e Florian Brinkmanns artigo de amostra (nenhum plug-in instalado, exceto o plug-in de testador wordpress beta e o plug-in de editor clássico, mas o último foi desativado durante o primeiro teste).

Tela branca por 68 segundos
FOIT por mais 35 segundos

após reativar o editor clássico e recarregar o artigo:

Nenhum conteúdo na metacaixa do corpo 12 segundos
FOIT por mais 2 segundos

Sente que as coisas continuaram ruins ou ficaram ainda piores ao carregar o artigo com gutenberg.

Testei com meu conteúdo + 4.6 e o ​​desempenho não mudou. Do jeito que parece, não está resolvido com o 5.0. Que pena, mas ok, você está trabalhando nisso. Muito obrigado!

Testado novamente com RC3 no Safari 12.0.1 com o artigo de amostra Local by Flywheel e Florian Brinkmanns (nenhum plug-in instalado, exceto o plug-in do testador beta do wordpress e o plug-in do editor clássico, mas o último foi desativado durante o primeiro teste).

Tela branca por 41 segundos
FOIT por 52 segundos

Em contexto com a nova data de lançamento em dois dias, em qualquer lugar perto do desempenho pronto para produção.

Em contexto com a nova data de lançamento em dois dias, em qualquer lugar perto do desempenho pronto para produção.

Sim. Não tenho certeza do que exatamente @m significa em seu artigo https://ma.tt/2018/11/a-gutenberg-faq/ onde ele escreve:

Tivemos um RC1 estável, que significa primeiro candidato a lançamento, e prestes a fazer o segundo. Atualmente, há apenas um bloqueador conhecido e é cosmético.

Me faz, por exemplo, pensar:

Enquanto este ponto nº 12312 não for resolvido, aguardarei a atualização. Isso simplesmente não faz sentido para mim.

@sgomes e co: por favor, continuem com o bom trabalho. Posso imaginar que você recebe pressão de todos os lugares. Obrigado por trabalhar nisso! Infelizmente, só posso ajudar com minhas palavras! Você está fazendo um ótimo trabalho !!!

Há uma série de otimizações de desempenho adicionais que foram mescladas ou aprovadas para mesclagem, mas ainda não incluídas em um lançamento, pois perderam o prazo para o congelamento do código RC. Eles estão programados para serem incluídos em uma versão de patch 5.0.1 a seguir logo após a 5.0.0.

• # 11851
• # 11899
• # 12356
• # 12379
• # 12384
• # 12386
• # 12402
• # 12460
• # 12477
• # 12480
• # 11602
• # 12521
• # 12542

@aduth ótimo. Você é ótimo. É muito bom ver que você leva em consideração os desejos da Comunidade e os leva a sério. Por favor, não deixe os muitos comentários negativos desmotivar você. Nós, como comunidade, também temos a responsabilidade de apoiar os desenvolvedores. Isso é um pouco curto no momento e eu tenho que colocar meu próprio nariz nisso.

Portanto: todos os polegares para cima !!!! Você é ótimo!

Ainda estou tendo esses problemas de carregamento muito lento também. Estive procurando soluções na semana passada. Eu uso a versão mais atualizada: Gutenberg versão 4.6.1 e Wordpress 4.9.8.

Eu criei minhas primeiras 20 ou mais postagens com o editor do Gutenberg, o que foi ótimo, com exceção de carregamentos lentos em postagens mais longas, que é a maioria das minhas postagens. Geralmente são longos com muitos blocos e imagens. Em seguida, baixei o YoastSEO e ele bloqueou meu site completamente. Meu site já estava lento e com o modo de solução de problemas percebi que era Gutenberg e piorou quando combinado com YoastSEO.

Agora eu tenho que usar o Editor Clássico e muitos dos meus links não estão mais embutidos com uma boa visualização que 'Gutenberg tem e o espaçamento está todo diferente de quando eu usei a plataforma Gutenberg.

Então, neste ponto, eu também

1. Use Gutenberg e lide com a velocidade lenta, esperando por atualizações futuras e, em seguida, exclua Yoast e descubra outra solução para seo e meta descrições.
2. Ou descubra um editor melhor que imite Gutenberg sem prejudicar a velocidade de carregamento.

Qualquer ideia aqui seria muito apreciada sobre a melhor forma de proceder. @aduth @SchneiderSam

Não cheguei a lugar nenhum com o meu tópico aqui:
https://github.com/WordPress/gutenberg/issues/12508#issuecomment -443919417

@aduth , você testou uma compilação com esses patches aplicados contra o carregamento de uma postagem com o conteúdo do artigo de Florian Brinkmann (https://github.com/WordPress/gutenberg/issues/11782#issuecomment-438213916)? Está no mesmo nível do TinyMCE agora? E agora é possível digitar e editar nesse artigo em tempo real? E por curiosidade, por que esses patches não chegaram ao 5.0?

Ainda estou tendo esses problemas de carregamento muito lento também. Estive procurando soluções na semana passada. Eu uso a versão mais atualizada: Gutenberg versão 4.6.1 e Wordpress 4.9.8.

Eu criei minhas primeiras 20 ou mais postagens com o editor do Gutenberg, o que foi ótimo, com exceção de carregamentos lentos em postagens mais longas, que é a maioria das minhas postagens. Geralmente são longos com muitos blocos e imagens. Em seguida, baixei o YoastSEO e ele bloqueou meu site completamente. Meu site já estava lento e com o modo de solução de problemas percebi que era Gutenberg e piorou quando combinado com YoastSEO.

Agora eu tenho que usar o Editor Clássico e muitos dos meus links não estão mais embutidos com uma boa visualização que 'Gutenberg tem e o espaçamento está todo diferente de quando eu usei a plataforma Gutenberg.

Então, neste ponto, eu também

1. Use Gutenberg e lide com a velocidade lenta, esperando por atualizações futuras e, em seguida, exclua Yoast e descubra outra solução para seo e meta descrições.
2. Ou descubra um editor melhor que imite Gutenberg sem prejudicar a velocidade de carregamento.

Qualquer ideia aqui seria muito apreciada sobre a melhor forma de proceder. @aduth @SchneiderSam

Não cheguei a lugar nenhum com o meu tópico aqui:
# 12508 (comentário)

Oi,

então vejo que os desenvolvedores estão trabalhando nisso. Dê uma olhada neste artigo . Com as próximas atualizações 4.7 e 4.8, isso deve ser resolvido. Eu te entendo completamente. No momento, estou apenas escrevendo artigos curtos porque não é divertido. A única coisa que estou fazendo agora é ser paciente e motivar os desenvolvedores com feedback.

A propósito: não sou um desenvolvedor, sou apenas um pequeno autor como você ;-)

Marcando alta prioridade e atribuindo à próxima versão secundária.

O trabalho listado por @aduth em https://github.com/WordPress/gutenberg/issues/11782#issuecomment -444144278 melhora o desempenho de digitação em mais de 340% e será enviado como parte do WordPress 5.0.1.

Não está claro qual ação precisa ser tomada para que esse problema seja considerado resolvido. O trabalho de performance nunca está realmente "acabado". Por enquanto, estou movendo este problema para 5.0.2 para que possamos acompanhar as melhorias de desempenho aqui.

@noisysocks que é fácil de avaliar. Use o artigo de Florian Brinkmann. Assim que o carregamento do artigo com cache desabilitado for igual ou mais rápido do que com TinyMCE e a digitação for sem atrasos e interrupções em tempo real em par com TinyMCE, então eu consideraria o problema resolvido.

Testando com 5.0 nos últimos dias, e não tenho nenhum problema de desempenho. Eu testei com o texto que tem mais de 300 blocos, mais de 15.000 palavras, mais de 50 imagens, não há atrasos perceptíveis na digitação ou no uso do editor. Mas, o uso de RAM do navegador cresce perto de 2 GB, com CPU usando cerca de 15%, e considerando quanto o editor de conteúdo lida, não é um problema tão grande. Testado em laptop Lenovo com 2 CPUs Core i5 (com Hyperthreading, Gen7) e 8 GB de RAM. Os problemas que tive com Beta e RC1 foram resolvidos para mim.

Testando com 5.0 nos últimos dias, e não tenho nenhum problema de desempenho.

Não posso confirmar isso. 5.0 é lento. Aguarde 5.0.1

Não posso confirmar isso. 5.0 é lento. Aguarde 5.0.1

Acredito que existam influências externas que fazem com que alguns usuários funcionem bem e alguns tenham problemas de desempenho, o que não é nada surpreendente, considerando que é principalmente JavaScript e React o alimentando. Quando visito qualquer página do Facebook, meu laptop fica lento, como se fosse uma máquina de 10 anos. E estou surpreso que o Gutenberg 5.0 funcione bem para mim, mas não estou surpreso que esteja quebrado para tantos outros usuários.

Eu realmente espero que os problemas de desempenho do Gutenberg possam ser resolvidos para todos os usuários, mas neste ponto, não estou tão certo disso. Se o sistema pode ser quebrado pela influência de uma extensão ou duas, talvez alguns plugins, é fundamentalmente um projeto ruim com defeito.

Mesmo assim, ainda não atualizei meus sites, também optei por esperar pelo 5.0.1.

Nenhum teste de desempenho deve ser feito sem o plug-in Yoast instalado e o complemento do navegador Grammarly habilitado, pois esse é um cenário de caso de uso normal. Se funcionar perfeitamente bem sem nenhum deles, mas no segundo que você instalar um deles se tornar totalmente impraticável, então a coisa toda será impraticável.

E, honestamente, não consigo acreditar que alguém esteja tendo um bom desempenho em qualquer configuração, mesmo sem eles instalados. Acho que seus padrões são incrivelmente baixos. Quase garanto que, se tentasse digitar no seu computador com o Gutenberg, ficaria totalmente consternado.

Gutenberg não funciona para edição de texto em meu laptop i3, meu iMac i5 ou meu desktop i7 / 1080 Ti, com ou sem plug-ins. Sem plugins, o desempenho é insuportavelmente ruim, com eles é completamente inútil, estamos falando de um frame por 5 segundos aqui.

O que eu realmente não entendo é, por que QUALQUER lag está sendo tratado como aceitável ?? Isso não acontece quando você simplesmente cria um. Nunca há atraso, nunca, ponto final. Se um frontend JS não pode corresponder ao desempenho de uma textarea, ele não deve ser usado. Esse problema deve ser marcado como resolvido apenas se o atraso realmente tiver acabado, o que eu não acho que vá acontecer, então, na verdade, esse problema nunca pode ser marcado como resolvido legitimamente.

Eu uso gramática, mas nunca uso o plugin Yoast. Até agora, Grammarly não me causou problemas. E meus padrões estão longe de serem baixos, longe disso. Tenho testado o Gutenberg desde a primeira versão em que foi lançado e escrevi sobre ele várias vezes este ano, com longas listas de reclamações sobre ele.

Estou genuinamente surpreso que o 5.0 funcione para mim, mas não estou surpreso que não funcione para outros usuários. Usar JavaScript e React como peça central do editor é uma má ideia, e venho dizendo isso desde o início, mas aqui estamos.

Uma hora atrás, eu atualizei o site de um cliente para 5.0 (ele insistiu), ele usou o plugin Yoast Pro e na maior parte, funciona bem. Mas, assim que tentei converter um dos posts mais longos que ele tem (algum tutorial com cerca de 4000 palavras), o editor se equilibrou durante os processos de conversão. Depois de algumas tentativas, consegue finalizar a conversão, mas a edição é muito lenta e dificilmente utilizável. Uma vez que o plugin Yoast é desabilitado, ele funciona como esperado. Não tenho certeza de quem é a culpa, provavelmente tanto Gutenberg quanto Yoast (pelo que entendi sobre como o Yoast funciona, ele tem que se conectar a cada parte do conteúdo do editor), independentemente, quanto mais plug-ins começarem a aparecer para Gutenberg , as coisas só podem piorar.

Qualquer atraso no editor é inaceitável e não estou aqui para defender Gutenberg. Por uma questão de conversa e depuração do problema, relatei problemas que tive antes e o que aconteceu depois. Eu realmente espero que o 5.0.1 resolva isso para todos.

Conforme mencionado por @noisysocks em https://github.com/WordPress/gutenberg/issues/11782#issuecomment -445691324, há uma série de alterações de desempenho pendentes agendadas para 5.0.1. Eles agora também estão disponíveis para testes iniciais no plug-in Gutenberg v4.7.0-rc.1, disponível para download ( download direto ).

Em relação ao Yoast especificamente, isso também inclui # 12161 e # 12741 (# 12186), que abordam uma degradação de desempenho crítica específica para o pacote @wordpress/annotations que não é usado atualmente em uma instalação de estoque, mas aproveitado pelo Yoast por sua legibilidade análise.

Acabei de instalar o candidato a lançamento. O grau em que melhora o desempenho não pode ser exagerado. Eu realmente não achei que uma melhoria como essa fosse acontecer. Estou ainda mais descrente de que o lançamento final não foi adiado para essas correções, mas também estou em um estado de alívio extremo por estar errado sobre as falhas serem fundamentais e impossíveis de corrigir.

Muito, muito obrigado a todos os responsáveis ​​por essa atualização.

Eu também instalei o rc .... WOW! Bom trabalho. Tenho um post de 3550 palavras no qual estou trabalhando atualmente. Eu tenho o Yoast instalado e ativo. Digitar com o novo 4.7.0-rc1 vai muito bem, mas se você usar o backspace, parece que há um atraso um pouco maior antes que o personagem seja removido. Farei mais testes nos próximos dias,

Não posso confirmar isso. Tanto com o meu quanto com o conteúdo de florianbrinkmann, apenas lentamente. O back-end está até congelado.

Teste com o neww RC 4.7 RC-1. Verifique isto: http://recordit.co/k5qszezoFQ

Estou tão preocupado com este tópico que agora fiz mais testes. Eu realmente quero ajudar a otimizar GB e, portanto, quero publicar meus testes:

Primeiro testei uma versão completamente nova do WP 5.0 + 4.7.0-rc-1.

• Resultado com meu conteúdo: Muito bom. Então, escrever é divertido de novo!
• O resultado com conteúdo de florianbrinkmann: a conversão em blocos leva uma eternidade.
• Mudar com o mouse dentro dos blocos: um desastre.
• O back-end está congelado. Você não consegue escrever de jeito nenhum.

Então testei uma versão existente do WP 5.0 + 4.7.0-rc-1 + 27 plug-ins.

• Resultado com meu conteúdo: atrasos de 5-10 segundos por pressionamento de tecla. Escrever é extremamente desagradável.
• O resultado com conteúdo de florianbrinkmann: a conversão em blocos leva uma eternidade.
• Mudar com o mouse dentro dos blocos: um desastre.
• O back-end está congelado. Você não consegue escrever de jeito nenhum.

Até aqui, a questão que se coloca para mim: por que posso escrever muito bem com uma instalação nova, mas não com meu site em anexo. Portanto, devem ser os plug-ins.

Desativei um plugin após o outro. Meu resultado: wpSEO é o problema.
_Configuração: WP 5.0 versão + 4.7.0-rc-1 + 26 plugin ativado + wpSEO desativado._

Mas: se eu instalar uma nova versão do WP 5.0 + 4.7.0-rc-1 + wpSEO, ele funciona novamente e posso escrever normalmente. E aí chego aos meus limites: como pode ser isso?

Se eu ativar tudo, exceto wpSEO, durante a nova instalação: maravilhoso. O problema é wpSEO.
Se eu apenas ativar uma nova versão do WP 5.0 + 4.7.0-rc-1 + wpSEO: maravilhoso

O resultado final é: os plug-ins de SEO são responsáveis ​​pelo desempenho ruim. Mas também nem sempre. Vou testar e relatar outros plug-ins de SEO como o SEO Framework e o YOAST. GB ainda tem problemas com o desempenho, especialmente com o conteúdo de florianbrinkmann.

_edit: SEO Framework funciona bem! Mesmo com esta configuração: WP 5.0 versão + 4.7.0-rc-1 + 26 plugin ativado + SEO Framework. Onde wpSEO deve ser desativado._

Belo diagnóstico @SchneiderSam . Eu não iria tão longe para dizer que afeta amplamente os plug-ins de SEO; é provavelmente mais sutil para a integração específica de um plugin com Gutenberg. Os plug-ins de SEO podem estar mais inclinados a aproveitar as vantagens do módulo "anotações", mas como isso deve ser amplamente aprimorado pelo 4.7.0, pode ser outra coisa se ainda for problemático quando testado com o candidato a lançamento.

Infelizmente, wpSEO não disponibiliza seu código (pelo menos seu JavaScript) gratuitamente para investigação posterior. Dito isso, em seu código reduzido, identifiquei um pequeno código problemático:

wp.data.subscribe(function(){var a={postContent:wp.data.select("core/editor").getEditedPostContent()};wpseo_inspect(a)})

É provável que isso não tenha um bom desempenho, pois forçará cada bloco a computar seu resultado salvo em qualquer alteração que ocorra no editor. Seria melhor para eles (a) operar nos próprios objetos de bloco e (b) somente se os blocos realmente mudarem. Farei uma observação para enviar uma solicitação de suporte por meio do site deles direcionando-os a esse problema.

_ Editar (12-12-2018): O pessoal de suporte respondeu com uma observação de que uma nova versão do plugin está planejada para ser lançada em breve._

4.7 é uma grande melhoria - mas adoraria ver este problema em aberto, pois ainda acho que não é exatamente um 1: 1 do editor clássico.

Ótimo trabalho! Ele passou de basicamente inutilizável para muito responsivo.

@SchneiderSam se um plugin de SEO atrasa a experiência de edição, principalmente porque existem alguns problemas subjacentes que, felizmente, já estão definidos. 4.7 já é realmente uma GRANDE melhoria no desempenho.

Testado o artigo de Florian Brinkmann com WordPress 5.0.1 e Gutenberg 4.7 com Local do Flywheel novamente. Sem plug-ins sem nada instalado à parte. Apenas abri um novo contêiner e tentei carregar o artigo no Safari 12.0.2

Tela branca: 41 segundos carregando o artigo
FOIT: 0 segundos (Noto não foi usado, pode ser o motivo de não haver FOIT)

A rolagem é lenta e a digitação ainda apresenta atrasos. O problema não está nem perto de ser corrigido. Ainda não é um produto utilizável. E eu tenho que fechar o editor agora de novo porque meus ouvidos estão doendo com o barulho que os ventiladores do notebook estão fazendo, que estão constantemente funcionando a toda velocidade depois que o post começou a carregar.

Atualizar:
Tive que refazer o teste. Percebi que esqueci de manter meus devtools abertos para tomar cuidado para que nenhum cache esteja sendo usado. Agora os resultados são muito piores em relação ao teste anterior e o FOIT está de volta.

Tela branca: 86 segundos carregando o artigo
FOIT: 59 segundos

Edit (12-12-2018): O pessoal de suporte respondeu com uma observação que uma nova versão do plugin está planejada para ser lançada em breve.

Então wpSEO 4.5.3 acabou de testar com GB 4.7 (meu conteúdo): muuuito mais rápido. É assim que tem que ser. Muito obrigado a todos vocês!

Também testei o agora famoso "Artigo de Florian Brinkmann". Desistiu após 15 segundos de tempo de carregamento. Nenhum editor deve carregar mais do que ... digamos 5 segundos? Mais tempo de carregamento?
Isso não é viável para uma experiência de edição!
FF 64, Ubuntu

Também estou tendo esse problema com artigos com mais de 2.000 palavras ou mais, testando em ambas as instalações locais em meu Macbook com Mojave, começando meu teste há vários meses com o plug-in Gutenberg e, mais recentemente, nos últimos dias em sites que executam WP 5.0. 1

Aqui estão as coisas específicas que observo quando começa a atrasar:
A digitação é atrasada em pelo menos 5 a 7 pressionamentos de tecla
É doloroso tentar rolar do topo da postagem para o final do editor
Há um atraso ao tentar adicionar novos blocos
Há um atraso ao tentar alterar a formatação do parágrafo para uma lista ou título
Salvar e sair da postagem não corrige o tempo de atraso - também leva um tempo visivelmente maior para a postagem recarregar na tela de postagens

Minha teoria atual é que quanto mais tempo gasto no editor, maior o tamanho da postagem e quanto maior o número de revisões, mais lenta ela fica.

Não tenho certeza se esta é uma teoria precisa, mas em meus testes descobri que se você apenas copiar / colar 7.000 palavras de texto em markdown com títulos, links, listas, etc., você poderá salvar e publicar sem problemas . O Safari é notavelmente mais rápido do que o Chrome, mas ambos ainda são viáveis.

No entanto, depois de colar seu artigo e passar mais de 20 minutos no editor formatando texto ou fotos, você começará a ver as coisas ficarem cada vez mais lentas.

Esse problema fica pior se você tiver outras distrações que desviem sua atenção do editor, como ter filhos, pais, animais de estimação, colegas de casa, um telefone, mensagens instantâneas, um cônjuge, um vizinho ou quando "vai basta levar um minuto "a pesquisa ou busca por uma foto de banco de dados leva mais do que apenas um minuto.

Percebi que também pode haver uma correlação entre os tempos de atraso lentos e o número / frequência de início das revisões automáticas de postagem. Isso pode estar relacionado às revisões de salvamento automático discutidas em # 7502.

Em cerca de 20 minutos com a janela do editor aberta, eu tenho 7 revisões de postagem e meu artigo de 7.000 palavras torna-se dolorosamente lento para rolar e editar. Depois de limpar manualmente as revisões e reiniciar o Chrome / Safari, sou capaz de editar e trabalhar conforme o esperado novamente - mas apenas por um período limitado de tempo antes que comece a atrasar mais uma vez e haja mais revisões automáticas de postagem.

Vou tentar editar o wp-config para ajustar as configurações de revisão e testar isso para ver se pelo menos por agora irá fornecer uma solução alternativa em sites que estão ativos e executando o WP 5.0.1. Se houver mais alguma coisa que eu possa fazer para testar ou fornecer informações, diga-me quais informações ou testes eu posso fornecer comentários que podem ser úteis.

Houve uma discussão informal no último dia do contribuidor do WordCamp US que pode estar relacionada ao que você está experimentando @chellestein , especificamente em como Gutenberg gerencia o histórico de Desfazer / Refazer como um conjunto acumulado de instantâneos.

A implementação original em # 415 explorou a inclusão de um limite no número de entradas rastreadas no histórico, mas isso foi descartado posteriormente. Atualmente, o editor se lembrará de todas as suas alterações em uma sessão do editor. Acho que pode ser argumentado de qualquer maneira, mas há alguma legitimidade em querer uma história de desfazer ilimitada. Falando por mim mesmo, em um processador de texto ou IDE não é incomum para mim segurar Cmd + Z e restaurar de volta a um ponto centenas de entradas de histórico anteriores.

A discussão específica no WordCamp US foi até esse ponto se os instantâneos acumulados poderiam prejudicar o desempenho por ocupar muita memória no navegador. A discussão havia concluído com alguma esperança de que a implementação interna de um mecanismo de navegador reutilizaria alocações de memória de valores imutáveis ​​(blocos), onde cada entrada de histórico serviria amplamente como um ponteiro para um único objeto compartilhado na memória.

Isso pode ou não ser verdade, e suas experiências podem servir como uma anedota de que ainda é problemático (supondo que _é_ o histórico de Desfazer / Refazer causando a queda no desempenho). Eu acho que isso merece um olhar mais atento, e talvez em paralelo, um repensar sobre como a história é gerenciada em geral para uma implementação mais eficiente (por exemplo, uma baseada em diffs, ajustando a granularidade dos níveis de desfazer). E, é claro, é importante observar que essa é apenas uma parte do tópico maior de desempenho geral.

Enquanto isso, embora certamente não seja um fluxo de trabalho de usuário ideal, você pode descobrir que recarregar a página de vez em quando ajudará.

Uma maneira de restringir se o "número de revisões" é um fator é se uma postagem com muitas revisões não apresenta desempenho imediato quando o editor carrega pela primeira vez. Suspeito que isso pode não ter um grande papel no desempenho do editor.

As limitações de memória do navegador definitivamente podem ser um possível fator que contribui para o @aduth , especialmente quando você considera que muitas pessoas enquanto trabalham no WordPress podem ter várias guias do navegador abertas e outros sites abertos. Isso também poderia explicar por que o que observo no "modo de teste" tende a ser inconsistente com o que acontece quando realmente tento publicar em sites ativos, onde o fluxo de trabalho certamente varia.

Não tenho certeza se isso ajuda, mas há uma coisa que percebi enquanto trabalhava em uma longa postagem no meu blog. Ele travava o mySQL, então eu loguei no meu VPS (é o menor no DO) e executei top .

Percebi que sempre que edito o post, ele abre simultaneamente um grande número de processos php que eu suspeito que provavelmente mataram o mySQL.

Eu testei isso no Chrome e no Firefox no Mojave. Meu servidor executa o Ubuntu 16.04 com php 7.0 - testei isso com php7.1 e 7.2 com os mesmos problemas.

Um problema que observei é que com postagens especialmente grandes, a inicialização dos dados da postagem com o carregamento da página torna-se um gargalo, principalmente quando se considera a redundância de dados enviados ao cliente entre as variações de conteúdo "renderizado" e "bruto" de uma postagem ( sendo esses os campos padrão fornecidos por meio da API REST ).

Quando o editor de bloco é carregado, vários endpoints da API REST são executados preventivamente no lado do servidor e seus resultados são fornecidos a Gutenberg. Isso inclui os dados da postagem:

https://github.com/WordPress/gutenberg/blob/6d5a5374a0d2c42e18f113a5c056d4cfa1481290/lib/client-assets.php#L1085

Na verdade, a intenção é _melhorar_ a experiência de carregamento, evitando um atraso entre a página exibida e o conteúdo editado se tornar conhecido.

No entanto, para uma postagem grande, o resultado do endpoint das postagens é significativo. Além disso, Gutenberg apenas considera o content.raw , não o resultado rendered , que é problemático porque:

1. Estamos executando o filtro the_content em uma sequência de conteúdo substancial
2. Os bytes adicionais transferidos contribuem para um carregamento atrasado do servidor e para a interpretação da análise do navegador da marcação da página

Considerando isso, pode valer a pena explorar as opções:

• O controlador REST API poderia ser aprimorado para permitir a omissão opcional de um ou outro de raw e rendered por algum parâmetro de consulta?
  
  
  
  • Semelhante à filtragem _fields , mas na propriedade content aninhada
  
  
  • Gutenberg poderia então comunicar explicitamente sua intenção de usar apenas raw
  
  
• Gutenberg deve evitar o bootstrap do posto?
  
  
  
  • Não está claro para mim se isso teria algum impacto. Pode ser negativo, na verdade. Por outro lado, pode permitir um tempo mais rápido para a primeira pintura do painel, dando pelo menos uma percepção de desempenho melhor, mesmo se de fato a postagem ainda não tiver sido carregada.
  
  
• Gutenberg deve inicializar com um formato de objeto personalizado que evite explicitamente as propriedades aninhadas duplas content ?
  
  
  
  • Isso pode ter um impacto negativo na adição de inconsistência em como a postagem é referenciada ou redundância se Gutenberg / outro plugin solicitar separadamente a entidade de postagem da API REST.
  
  

Editar: Relacionado # core-restapi Discussão no Slack (o link requer registro )

Houve uma discussão anterior sobre a extensão de _fields para especificar campos aninhados, consulte o tíquete principal do trac # 42094 - se bem me lembro, não fizemos progresso porque houve desacordo em torno da sintaxe a ser usada para especificar a inclusão de propriedade filha. Eu propus a sintaxe de parent.child dot, @danielbachhuber sugeriu parent[child] , JMESPath teve alguma tração com base no uso do plugin relacionado. Podemos continuar essa parte da discussão naquele tíquete, adoraria nos ver economizando na análise de conteúdo sempre que possível!

Atualize aqui, 4.9 foi um grande lançamento em termos de desempenho. Os principais problemas para postagens longas foram corrigidos. Ainda há melhorias que podem ser feitas aqui e ali, mas acho que devemos encerrar esse problema em breve.

Você já experimentou o infame "Artigo de Florian Brinkmann". para teste?

Os textos que escrevo assim (1000-2000 palavras) agora podem ser editados muito bem. Muito obrigado e um ótimo trabalho! Obrigado aos desenvolvedores!

Ainda há problemas de desempenho quando formato textos longos em blocos ou se movo os blocos para frente e para trás, mas o problema desse problema foi resolvido. De novo: muito obrigado!

De _me_ pode-se fechar este problema.

@wpaustria sim, tudo bem para mim.

Ruhig, brauner!
Ainda assim, nada funciona! Brandnew dev insta em VPS de desempenho quase ilimitado.
Tentei copiar texto com CMD + C e CMD + V e que adicional com menu de contexto.
Ainda nada funciona!

Dê uma olhada no meu screencast:
https://youtu.be/lttL0TxPFbU

Desisti de esperar. Agora se passaram 10 minutos desde que fiz o screencast e nada aparece. Nenhum conteúdo é mostrado do "artigo de Florian Brinkmann".

Funciona muito bem para mim em navegadores diferentes, você deve ter um problema em algum lugar, um plugin ou outra coisa.

sim! 4 claro que deve ser meu dev insta ...

O sistema de teste é um VPS de € 100, o insta é totalmente novo.
Agora desativei todos os plug-ins - como você pode ver no vídeo do screen cast que acabei de fazer

https://youtu.be/HwFnG77QOvk

Ainda nada funciona ..
Com certeza é minha culpa.

Lamento que não funcione para você. Não estou dizendo que é sua culpa, só estou tentando descobrir o que está errado. Se você quiser que eu grave um screencast para mostrar que funciona para mim, eu posso.

Se nada for exibido, talvez haja um erro de JS em algum lugar, qual navegador você está usando?

Recém-instalado (*) FF 64 com origem uBlock habilitada.
Nada extravagante aqui.

(*) porque comprei um novo laptop - e posso recomendá-lo vivamente - é um Acer Swift 5 SF515; DD

@wpaustria você precisa instalar e ativar o plugin Gutenberg para testar a versão mais recente, eu acho.

Acabei de testar meu artigo com o Gutenberg 4.9 e ele está muito melhor agora (ainda tem um pequeno atraso (mas longe de um atraso de tipo que pode ser medido em segundos), e converter de um bloco clássico para blocos únicos ainda leva algum tempo e O Firefox pergunta se a página deve ser interrompida).

Acho que encontrei o problema.

TypeError: O argumento 1 de Node.removeChild não é um objeto.

É isso que você vê no console? Acho que provavelmente há um erro de javascript em algum lugar bloqueando a colagem totalmente, mas nada relacionado ao desempenho. Vamos abrir uma edição separada para isso.

Tentei em um Chromium recém-instalado:

https://youtu.be/gTMHEAs68Mc

E considerando a proposta de @florianbrinkmann , instalei o plugin Gutenberg e tentei novamente ..
Veja a tentativa que não resultou na cópia do texto:

https://youtu.be/W-X6hPB4OfY

Há um problema de JS como você pode ver no console ...

Obrigado pelos testes @wpaustria tenho o mesmo erro ao colar. Se você quiser testar o desempenho, pode tentar colar no editor de html e depois converter em blocos.

Estou fechando isso por agora.

Aqui está o problema do bug JS https://github.com/WordPress/gutenberg/issues/13527

@vocêsaber com qual versão ou número de compilação você considera este problema corrigido? Tentei novamente depois de ver o problema ser considerado como corrigido com a versão mais recente do plugin 4.9.0 e testado novamente com o artigo de florian brinkmann. Tela branca de 40 segundos e mais 64 segundos FOIT com um teste local instalado no Local pelo Flywheel. ainda em qualquer lugar perto de fixo para o imho de carga inicial. o desempenho da digitação não está mais parando e congelando, mas ainda está longe de uma experiência de digitação em tempo real. parece lento.

@youknowriad você viu minha pergunta 18 dias atrás ?!

Tentei testar novamente, percebo que o tempo de carregamento inicial ainda precisa ser melhorado, concordo. Ainda acho que os grandes problemas de desempenho foram corrigidos. O trabalho no desempenho não está parando.

então quais são os seus tempos de carregamento no seu computador com o artigo de florian brinkmann? e os tempos de carregamento com gutenberg são iguais aos tempos de carregamento com tinymce com o artigo de florian brinkmann? então eu consideraria os tempos de carregamento como fixos. mas no momento do meu lado eu ainda tenho 40 segundos de tela branca e 64 segundos foit com gutenberg em comparação com cerca de 12 segundos no geral com tinymce se bem me lembro.

Os tempos de carregamento para mim são 15 segundos para Gutenberg e 6 segundos para o editor clássico.

Mas ainda 2,5 vezes mais lento que o TinyMCE. Mas a parte muito mais preocupante é o seu tempo de carregamento com 15 segundos em comparação com o meu com 104 segundos (a propósito, você limpou os caches antecipadamente?). Não sei qual computador e configuração local você está usando, mas meus testes foram executados em um MBP 13 "no início de 2011 com 8 GB de RAM em execução no Local do Flywheel. Acho que o computador e o dispositivo também devem ser levados em consideração ao lidar com com tempos de carregamento e desempenho. Portanto, concordo que o trabalho de desempenho nunca para, mas o benchmark de desempenho deve ser computadores mais antigos menos potentes e dispositivos não os mais recentes mais potentes. Eu consideraria o tíquete corrigido e pronto para melhorias e iterações posteriores assim que como Gutenberg está a par com os tempos de carregamento do TinyMCE em máquinas e dispositivos mais antigos e menos potentes com o artigo de Florian Brinkmann com caches limpos antecipadamente. Até então, considero o problema não corrigido e manteria o problema aberto.

@youknowriad ok tentou novamente com 5.1 agora. MBP início de 2011 com 10.13.6 e Local do Flywheel. Com o WordPress 5.1 nenhum outro plug-in instalado. Usei o artigo Florian Brinkmann e limpei caches antecipadamente no Safari 12.0.3.

Com Gutenberg:
Tela branca de 59,2 segundos
78 segundos FOIT
137,2 segundos no geral

Instalou o Classic Editor 1.4 posteriormente (também limpou os caches antecipadamente)
11,78 segundos de tempo de carregamento geral

Gutenberg ainda precisa cortar pelo menos 125,42 segundos para que este bilhete possa ser considerado como imho fixo.

@rpkoller Você pode criar um problema separado sobre o tempo de carregamento inicial. Concordo que ainda há algum trabalho que devemos fazer lá. Esta edição é muito longa e difícil de entender para os colaboradores no momento, então acho que uma nova edição é melhor.