А еще одно дело 300 000 тестов и 10 000 заболевших и 3 000 000 тестов и 100 000 заболевших, да?
Медицине не до этого - это раз.Во-вторых, шел со стволом, есть не нулевая вероятность, что это все для сми и сделано, надо же осваивать бюджет на "рекламную компанию" по вакцинации: экс вояка, переделанный пугач, гос учереждение, бравый лейтенант тут как тут, а по камере определили что он "антиваксер".
PS Цирк что то поднадоедает этот если честно
Антиваксеры это
https://www.business-gazeta.ru/article/532189
А теракты в стране устраиваю террористы, да мы знаем.
вы его указываете как display:none, он отрисован не будет, а значит занимаемое им место не будет рассчитано и когда вы ему поставите display: block|inline он отодвинет все остальное, это видимо надо родителю указать размеры тогда... но это гемор, проще картинку размыть до состояния 1кб но тех же размеров и подставить её а после загрузки подменить на нужнуюЭто можно даже сделать "изкаропки"
Чтобы на первом экране быстро подгружались фон и основные картинки, есть Небольшой лайфхак:
надо в коде их прописать, как можно выше (до загрузки стилей и скриптов) в виде:
<img src="" style="display:none;">
так я у себя эту проблему закрыл с фоном, который грузился спустя секунду, мне очень не нравилось как выглядит недогруженная страница. Правда это поможет при статичном хедере, ну и применять получиться только на нескольких страницах т.к. придется вручную все прописывать.
Прыгать страница будет, есть интересное решение с сильным размытием картинок или подстановкой скелетона, но что то таких же размеров должно быть на странице
В этом и есть проблема плагинов и такой разработки. Ваша задача, если контент подбирается на основе того, что сейчас читает пользователь не требует работы на хите, такую работу можно вынести на крон, если же у вас подбор именно по интересам текущего пользователя, то в целом тут уже можно подумать, например относить юзера к каким то группам а для этих групп уже на кроне подбирать нужный материал, и пользователям отдавать заранее просчитанный результат, тогда кешировать прям всю страницу не будет какой то такой необходимости. В общем кейсы надо разбивать на таски и смотреть как сделать эти таски эффективными. У меня на основном проекте сейчас много млн пользователей, приходится учитывать много нюансов при написании каждой строки кода, так как любое неосторожное действие положит даже самый жирный продакшен.
Кеширование, как бы вам сказать, оно в целом не для всего и не везде нужно. Например возьмем блог, для выборки 10 категорий и там 10 постов на странице не требуется кэш, БД отработает эти простые запросы практически моментально. Если брать CMS то ей надо пробежаться по всем плагинам и опросить по всем событиям, которые вообще могут не участвовать в загрузке этой страницы, они в этот момент могут даже куда то на внешние сервера что то отправлять. Вот когда таких операций становится много, тогда и нужно кеширование, но это оверхэд для блога, особенно для личного блога. Когда у вас например интернет магазин и товар собирается по частям, то вам кэш поможет не грузить лишний раз систему однотипными операциями и кеширование тут крайне желательно.
Кэш на самом деле это не плагин, это достаточно большой раздел в бэкенд разработки с кучей нюансов, кэш не панацея и бывает как полезным так и вредным, например банально выборка с БД может быть быстрее, чем открытие файла кеша для каждой карточки, которых 30, так как к БД подключаемся 1 раз, а кэш файлов надо открыть 30. Короче там все очень тонко и надо понимать что и для чего делаешь.
оно будет работать быстрее, но в пределах погрешности, вы не получите 2х производительности, при 2х частоте. Вы можете даже бэнчмарки процессоров разных посмотреть, там в процентном соотношении не очень высокие приросты, а с учетом того, что процессор обычно ждет I/O, то в целом на глаз вообще может быть не заметно разницы. Диски тоже как вам сказать, linux считает что свободная оперативка должна быть только на полках в магазинах, по этому по факту если у вас хватает оперативки то линукс в неё начнет складывать файловую. Ну а память и так была быстрая, и сервера нормально работали и на ddr1 и на ddr2 и так далее.
PS. Если вас интересует именно производительность, то вам совет научится работать с профилировщиками, например xhprof или xdebug и вы поймете где именно проседает у вас производительность. Есть так же очень клевый сервис https://www.blackfire.io/
согласен, цифры оставим занудам, я как простой пользователь вижу как медленно рендерится страница, это бросается в глаза и это не приятно.
Сейчас проверил в edge со всеми обновлениями, немного стало быстрее, но все равно медленно и много белого пространства, ощущение недоделанности, со смартфона так же.
Я считаю очень поздно подгружаются всевозможные изображения, а без них на сайте лишь белый фон и капелька текста, вот если вся графика не будет грузиться в последний момент, сайт сразу станет более весёлым.
Если вы посмотрите по загрузке, то картинки это отложенная загрузка (грузятся после всей загрузки), какой то плагин поставленный сеошниками чтобы "угодить гуглу", у меня задача в бэклоге есть, я перепишу ленивую загрузку изображений, как руки дойдут, так там картинки webp и на самом деле они подгружаются моментально без этого js плагина.
