Aisamiery

Aisamiery
Рейтинг
319
Регистрация
12.04.2015
Перфекционист:
Так здесь тема другая.
Ускорение сайта на ВП. Плагины всякие и всё такое.

Мой способ ускоряет любой сайт по пейджспиду, без плагинов и всяко такого :D

Для того чтобы делать качественные проекты надо иметь голову, а не список каких плагинов надо поставить. Никакие плагины сайтовладельцев никогда не спасут.. только голова и рациональное мышление и самое главное умение разобраться в причине.

Перфекционист:
Aisamiery, вы на ВП?

нет конечно, но в выше описанной схеме не задействован даже php, по этому использовать такие схемы можно независимо от движка.

Оксиген:

На фига "на лету" генерировать картинки? Это нерационально, дорого и антинаучно! Кто-нибудь внятно может ответить, зачем одну и ту же работу выполнять более 1 раза? Никто на этот вопрос тут не ответит, все "знатоки" проигнорируют.

Очень интересно как вы генерируете, по крону что ли? Обычно это происходит так:

Пользователь запрашивает index.php, там есть какой нибудь getImage('imaghe.jpg', 200, 200), если картинки нет размером 200х200 то она генерируется "на лету" блокируя поток php, увеличивая время ожидания ответа сервера. Далее уже идет запрос без генерации так как она уже есть. Либо при загрузке картинки в систему, система генерирует несколько форматов, например 5.

Как у нас, запросы разруливает сам nginx, то есть юзер запрашивает реально картинку статики, nginx видит что картинки нет, у него в кешэ её нет (то есть еще не генерировалось), отправляет запрос на отдельную виртуалку, которая делает картинку нужного размера и nginx сохраняет её в кеше, далее идет работа с кешем. Когда товар уходит с продажи, картинку перестают запрашивать, nginx сам удаляет все её варианты с кэша.

Почему у нас генерируется на лету и размеры можно задать в урле, сделано это для того, что помимо разных вариантов разрешений на сайте, мы используем картинки на всевозможных планшетах и мобильных девайсов и каждый девайс может запросить нужный ему размер не напрягая сервер (а у нас больше 30к юзеров и под 300rps).

Ну и как минимум это удобно, верстка выглядит естественно и фронт делать просто, например адаптивные картинки можно прописывать просто так как нужно


<img srcset="elva-fairy.jpg@280 320w,
elva-fairy.jpg@440 480w,
elva-fairy.jpg@800 800w"
sizes="(max-width: 320px) 280px,
(max-width: 480px) 440px,
800px"
src="elva-fairy.jpg@800" alt="Elva dressed as a fairy">

А ну еще наш ресайзер позволяет менять качество на лету, например для прелоада он делает очень очень низкое качество, картинка расплывчатая и весит 1кб (грубо говоря), страница у юзера загружается моментально он видит очертания товара и js уже после загрузки подгружает только видимые в экране картинки в нормальном качестве... верстка не прыгает и все смотрится достаточно лаконично

Ради интереса, вот при наших нагрузках, нагрузка на эту виртуалку которая клепает собственно нужные нам размеры "на лету"

Лелуш Ламперуж:
Вдруг выльется что вроде айхора, к ним я уже точно не ногой.

делайте своевременно бэкапы в автоматическом режиме и научитесь их разворачивать за небольшое время и можете пользоваться хоть арендуя компы у соседей.

LEOnidUKG:
На лету? Вы работали с сайтами, у которых посещалка больше 100 "калек" в сутки? :)
Это вообще не вариант.

У нас больше 30к сутки, превью генерятся на лету (по параметрам в урле) сишными либами, хранятся в кеше nginx, ничего сверхъестественного не наблюдаем. Кэш ограничен, самое не используемое вытесняется само. А да, сами превью генерит отдельная достаточно слабая виртуалка, на неё nginx проксирует запрос если картинке в кэше нет. Максимум что может - это лечь виртуалка и пропадут превью которых в кэше нет, но за 2 с лишним года виртуалка ни разу не легла.

Да, сейчас сильно развиваются SSR решения, тот же next.js и nuxt.js.

Если исключить (а рано или поздно поисковики наконец их исключат) кучу ГС с килотоннами рерайта сделанными не для людей а для РСЯ и адвордс, то для всех остальных сайтов технология достаточно хорошая.

Читсый бэк и фронт - разработчики сосредоточены на архитектуре, достаточно просто внедрять микросервисы. Не нужно искать того невиданного специалиста, который умеет профессионально в бэк и фронт. Соответственно задачи реально можно разбить и найти сильного бэк, который делает апи и чистый фронт - который делает клиента. Плюс можно найти любого фронта, например iOS и сделать на том же бэке клиента под iOS. Так же тут достаточно сложно наговнокодить, то есть не будет той страницы где в темплейте в цикле юзается SQL запросы к бд.

Грузится действительно быстрее, так как ресурсы подгружаются только на первом хите, а браузер рендерит не всю страницу каждый раз, а только её отдельные элементы.

На самом деле большинство технологий приносит пользу, раньше мало юзали SPA из за проблем с поисковиками, было сложно внедрять версию для поисковых систем. С развитием SSR (рендер на сервере) все сильно изменилось.

А так, во фронте сейчас уже начинает набирать популярность такие штуки как svelte

Stek:
Ок, я понял вашу логику. Если у медленного пинга 70% времени затрачено на доставку по локальному каналу, а 30% по внешнему - то в медлительности виноват внешний канал.

Что такое медленный пинг и при чем тут канал вообще? Пинг на одном и том же оборудование будет по сути одинаковым пи 1мб/с или 1Гб/с, ширина канала на это никак не влияет, грубо говоря влияет оборудование и кол-во промежуточных точек, чем их меньше тем пинг ниже (ну и плюс используемая технология, оборудование и расстояние).

Safaa:
Из вариантов, которые более менее умею - XenForo , Вордпресс + WPAdverts (бесплатный тут писали, я загрузила на пробу, а там куча платных нужных дополнений, в итоге дорого выходит) , osclass (простая доска объявлений, но говорят, что при большой нагрузке летит)

У вас еще проекта нет, а вы уже про большую нагрузку задумались. Любые части систем, в особенности "бутылочные горлышки" на самом деле не сложно переписываются, по этому не заморачивайтесь думая о нагрузке, когда она придёт (если придёт), методов оптимизации вагон и маленькая тележка.

Если вам нужно подешевле и сами будете делать, то делайте на том, на чём умеете, иначе выбирайте не технологию, а специалиста который будет делать на том, на чём ему удобнее выполнить ваше ТЗ

timo-71:

Никто не сказал, что кмс22 фуфло, кроме тайтлов и дескипшенов в едином шаблоне ничего не умеет, а чтобы на разные категории, разные шаблоны мета сделать нужно . А кмс222 это умеет и еще 304, грамотно, в зависимости от времени изменения компонент отдаст и все остальное на уровне.
Ну и остальные пункты ТЗ ТС.

У вас там ТЗ прям под битрикс написано по сео, всё есть в коробке, расходимся =)))

SeVlad:
Ключевое слово - целесообразность.
Это "я только что узнал что это мегакруто" пихают всякое везде.

Как раз докер это целесообразнее, чем всякие LAMP в виде денверов, опен серверов и чего там еще есть. Никто не говорит пихать докер на сам хост или внутри докера крутить продакшен, докер даже очень просто поднимает дэв окружение, можно за пару секунд поставить себе все что угодно, от php до редиса или тарантула с кафкой, в докер сейчас завернуты всякие тестовые сервисы в виде фейкового мейлера с возможность дэбага и прочих вещей. И самое главное это все ставится без плясок с бубном (в основном) буквально в пару команд. И так же в пару команд можно почистить всю машину от всего этого ПО.

В докере нет "вау" или "мегакруто" - докер это "виртуализация для чайников", то что использует под капотом в докере существует уже лет 20 минимум, если не больше, но популярным стало только с докером, потому что именно докер все это упростил до пары команд и вся магия под капотом.

Всего: 4110