Мой форум получает очень низкие оценки в категории производительности Lighthouse и получает штрафы от Google.
Интересует, есть ли способ улучшить эту скорость? На моём сайте около 2 тыс. участников, 100 тыс. сообщений и 5 тыс. тем. Я использую тарифный план с 4 ГБ ОЗУ от DigitalOcean.
В Discourse я использую только настройки по умолчанию (с включённым шаблоном Cloudflare).
Хотя у меня установлено довольно много плагинов.
Есть ли какие-либо советы по улучшению скорости моего форума?
Из-за этого? Я совершенно уверен, что это не так.
Согласно Google Search Console, в разделе «Производительность» указано, что время загрузки сайта велико. Я слышал, что PageRank учитывает это при ранжировании сайтов.
И всё же это не медленно, и Google вас не штрафует. В сети огромное количество дезинформации и недостоверных данных о PageRank, и это утверждение относится к той же категории.
В остальном оптимизация вопроса действительно проста. Сделать можно немного. На WordPress есть возможности благодаря PHP и особенностям работы сайтов, но в случае с приложением, таким как Discourse, аналогичных инструментов нет.
Конечно, вы можете начать искать более быстрый VPS и/или DNS, но на этом всё, и вы не получите реальной ценности за свои деньги.
Это не совсем верно. Скорость загрузки страницы уже довольно давно является фактором ранжирования в поиске, хотя и не самым значимым. Google использовал данные как со стороны своего краулера, так и из CrUX — не уверен, что это всё ещё так.
Да, но не на том уровне, который влиял бы на PageRank и настоящий/осмысленный SEO.
Да. Evaluating page experience for a better web | Google Search Central Blog | Google for Developers
В поисковую выдачу добавлены различные критерии пользовательского опыта, такие как скорость загрузки страниц и адаптивность для мобильных устройств, в качестве факторов ранжирования результатов.
Если у вас есть возможность проверить скорость работы со всеми отключёнными плагинами, это может дать полезную информацию. Сам по себе Discourse не является медленным — мой показатель в Lighthouse составляет 100.
Если возможно, измерение производительности с половиной включённых плагинов поможет сузить круг поиска и, возможно, выявить один конкретный плагин, вызывающий проблемы с производительностью. Однако проблема может заключаться не в одном плагине.
Привет 
Просто ещё один подход… У меня всегда были проблемы с серверами DO такого типа. Они работали медленно для активности моего сообщества. Поэтому я перенёс сервер на Vultr. Я считаю, что серверы Vultr High Frequency — лучшие в этой ценовой категории. Discourse гораздо предпочитает одноядерные быстрые процессоры многоядерным, но более медленным. Насколько я знаю, только Vultr предлагает vCPU с частотой 3 ГГц и выше в своей линейке HF. У меня никогда не было проблем со скоростью на этих серверах. Супер быстро и стабильно! 
Я использую конфигурацию 2 vCPU, 4 ГБ ОЗУ и NVMe SSD на 128 ГБ. Я использую серверы Vultr HF уже несколько лет. Определённо стоит попробовать, я настоятельно рекомендую их.
Спасибо за подсказку. Где-нибудь есть данные о производительности серверов Vultr?
По сравнению с DO у меня пока не получилось, но я планирую выполнить пересборку с таймером, как только смогу. Если я правильно помню, это обычно занимает около 5 минут, а также полезно проверить реальную производительность сервера. Я обновлю этот пост. 
Информация о процессоре:
Intel Core Processor (Skylake, IBRS)
cpu MHz: 3695.998
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel Core Processor (Skylake, IBRS)
stepping : 3
microcode : 0x1
cpu MHz : 3695.998
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
bogomips : 7391.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
---
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel Core Processor (Skylake, IBRS)
stepping : 3
microcode : 0x1
cpu MHz : 3695.998
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
bogomips : 7391.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Время пересборки с 13 плагинами, с использованием хранилища объектов S3 и включённым YJIT. Возможно, без них или с меньшим их количеством, а также на новой установке, процесс будет быстрее.
time ./launcher rebuild app
real 5m49.787s
Плагин «Кто онлайн» для Discourse может замедлить работу.
Я нашел этот сайт очень полезным при отладке
Он способен проверить страницу и просмотреть её так же, как это делает пользователь, и пытается диагностировать любые проблемы.
В частности, FCP и LCP — это именно те показатели, которые вам, вероятно, стоит оптимизировать. После того как я изолировал свои проблемы в некоторых кастомных плагинах, мне удалось снова ускорить работу и вернуть почти все мои страницы в категорию «хорошо».
Спасибо за все полезные советы, я обязательно попробую Vultr!
Насколько надежны эти метрики для приложений вроде Discourse? Они уже применялись для более традиционных веб-страниц. И как именно мы можем улучшить ситуацию, если у нас нет таких опций, как отложенная загрузка PHP и подобных?
Всё, что мы можем сделать, это:
Это было критически важно для выявления множества проблем на моем сайте. В частности, путем сравнения сайта с включенными и выключенными определенными компонентами темы или плагинами. Также этот инструмент хорошо помогает изолировать большие файлы и выявлять любые сдвиги контента.
Еще один полезный вариант, который я нашел, — это использование встроенного тестирования производительности в Chrome, доступного в панели разработчика.
У меня та же проблема. Я перешёл с диска SAS (300 IOPS с возможностью всплеска до 1000) на диск SSD (1500 IOPS с возможностью всплеска до 3000), и производительность выросла в десять раз. (Эти ограничения IOPS накладываются моим облачным провайдером)
Хотя и немного старые, но вот несколько тестов, которые я проводил некоторое время назад.
Тест выглядит интересно, но в нём мало говорится о бенчмарке Discourse на Vultr.
Мой лучший совет — Linode. Я проводил тесты скорости на всех этих серверах и обнаружил, что DO самый медленный, второе место занимает Vultr, а первое — Linode (от Akamai).
