Nadejda, вы хоть пишите на трезвую что ли, а то совсем какой то бессознательный поток мыслей, который очень сложно воспринимать.---------- Добавлено 02.03.2020 в 10:32 ----------
Вы поймите, чтобы понять что оптимизировать, надо понять что тормозит. Вот у меня есть блог на ВП (пока ещё на ВП), он у меня не тормозит, вот от слова совсем не тормозит, там установлено всего 3 плагина: акисмет, суперкэш и контакт форм и какая то тема с раздела тем официальная без изменений.... ну вот не тормозит и хоть ты тресни.
А в вашем случае непонятно что оптимизировать на бэкенде. Кривые плагины где в цикле идет 100500 запросов к БД? да не будет панацеи в виде какого то набора плагинов, который устраняет косяки вашего кривого набора плагинов и темы... точнее панацея только одна - пишите свой функционал сами, правильно, согласно канонам и не допускайте утечек памяти и лишних ненужных операций в коде. А если и оптимизировать, то конкретного "пациента", поставив профайлер и посмотрев где что и сколько выполняется, найти "узкое горлышко" и посмотреть что там можно поправить, скорее всего там будет какая то банальная фигня... и да в 90% случаев тормозит работа с БД, так как это первое во что упирается нагрузка как правило. А конкретно в данном случае (ТС просил) по pagespeed, а вот как раз это фронт и очень важно чтобы картинки были ровно тех размеров (исходник), который рендерится на странице, чтоб он был оптимизирован, ужат и приходил с заголовком кеширования, тогда и вырастут там попугаи.
Давайте головой лучше подумаете вы.
Вот специально для вас поднял пример:
Исходная картинка
http://49.12.2.183/img/39120040-example-grunge-retro-red-isolated-ribbon-stamp.jpg
Картинка в 200 px шириной
Картинка в 400 px шириной
Картинка в 300x100
Картинка в 100 px по высоте
Уменьшение качества на лету
Ну и конвертация в webp у кого появится тоже на лету
Там можете поиграться самостоятельно с окончанием урла и посмотреть что будет.
А оптимизация заключается в том, что вам не нужно грузить картинки размеров, которые устройство все равно не воспроизведёт.
PS. Через пару дней снесу виртуалку, надеюсь вы успеете посмотреть пример
PPS. Кстати webp почти на 20% меньше весит чем его jpeg версия
Подгружается по ajax, url меняется при помощи history api. Как вам помочь не совсем понятно, так как реальзаций может быть миллион и маленькая тележка.
Мой способ ускоряет любой сайт по пейджспиду, без плагинов и всяко такого :D
Для того чтобы делать качественные проекты надо иметь голову, а не список каких плагинов надо поставить. Никакие плагины сайтовладельцев никогда не спасут.. только голова и рациональное мышление и самое главное умение разобраться в причине.
нет конечно, но в выше описанной схеме не задействован даже php, по этому использовать такие схемы можно независимо от движка.
Очень интересно как вы генерируете, по крону что ли? Обычно это происходит так:
Пользователь запрашивает index.php, там есть какой нибудь getImage('imaghe.jpg', 200, 200), если картинки нет размером 200х200 то она генерируется "на лету" блокируя поток php, увеличивая время ожидания ответа сервера. Далее уже идет запрос без генерации так как она уже есть. Либо при загрузке картинки в систему, система генерирует несколько форматов, например 5.
Как у нас, запросы разруливает сам nginx, то есть юзер запрашивает реально картинку статики, nginx видит что картинки нет, у него в кешэ её нет (то есть еще не генерировалось), отправляет запрос на отдельную виртуалку, которая делает картинку нужного размера и nginx сохраняет её в кеше, далее идет работа с кешем. Когда товар уходит с продажи, картинку перестают запрашивать, nginx сам удаляет все её варианты с кэша.
Почему у нас генерируется на лету и размеры можно задать в урле, сделано это для того, что помимо разных вариантов разрешений на сайте, мы используем картинки на всевозможных планшетах и мобильных девайсов и каждый девайс может запросить нужный ему размер не напрягая сервер (а у нас больше 30к юзеров и под 300rps).
Ну и как минимум это удобно, верстка выглядит естественно и фронт делать просто, например адаптивные картинки можно прописывать просто так как нужно
А ну еще наш ресайзер позволяет менять качество на лету, например для прелоада он делает очень очень низкое качество, картинка расплывчатая и весит 1кб (грубо говоря), страница у юзера загружается моментально он видит очертания товара и js уже после загрузки подгружает только видимые в экране картинки в нормальном качестве... верстка не прыгает и все смотрится достаточно лаконично
Ради интереса, вот при наших нагрузках, нагрузка на эту виртуалку которая клепает собственно нужные нам размеры "на лету"
делайте своевременно бэкапы в автоматическом режиме и научитесь их разворачивать за небольшое время и можете пользоваться хоть арендуя компы у соседей.
У нас больше 30к сутки, превью генерятся на лету (по параметрам в урле) сишными либами, хранятся в кеше nginx, ничего сверхъестественного не наблюдаем. Кэш ограничен, самое не используемое вытесняется само. А да, сами превью генерит отдельная достаточно слабая виртуалка, на неё nginx проксирует запрос если картинке в кэше нет. Максимум что может - это лечь виртуалка и пропадут превью которых в кэше нет, но за 2 с лишним года виртуалка ни разу не легла.
Да, сейчас сильно развиваются SSR решения, тот же next.js и nuxt.js.
Если исключить (а рано или поздно поисковики наконец их исключат) кучу ГС с килотоннами рерайта сделанными не для людей а для РСЯ и адвордс, то для всех остальных сайтов технология достаточно хорошая.
Читсый бэк и фронт - разработчики сосредоточены на архитектуре, достаточно просто внедрять микросервисы. Не нужно искать того невиданного специалиста, который умеет профессионально в бэк и фронт. Соответственно задачи реально можно разбить и найти сильного бэк, который делает апи и чистый фронт - который делает клиента. Плюс можно найти любого фронта, например iOS и сделать на том же бэке клиента под iOS. Так же тут достаточно сложно наговнокодить, то есть не будет той страницы где в темплейте в цикле юзается SQL запросы к бд.
Грузится действительно быстрее, так как ресурсы подгружаются только на первом хите, а браузер рендерит не всю страницу каждый раз, а только её отдельные элементы.
На самом деле большинство технологий приносит пользу, раньше мало юзали SPA из за проблем с поисковиками, было сложно внедрять версию для поисковых систем. С развитием SSR (рендер на сервере) все сильно изменилось.
А так, во фронте сейчас уже начинает набирать популярность такие штуки как svelte
Что такое медленный пинг и при чем тут канал вообще? Пинг на одном и том же оборудование будет по сути одинаковым пи 1мб/с или 1Гб/с, ширина канала на это никак не влияет, грубо говоря влияет оборудование и кол-во промежуточных точек, чем их меньше тем пинг ниже (ну и плюс используемая технология, оборудование и расстояние).
