Pull to refresh

Comments 23

Жалко что о технических деталях реализации не сказано почти ни слова, а очень хотелось бы.


Очень большой Time to Interactive — на телефоне, после показа шапки, очень долго ничего не проихсодит. Я вижу секунд 5-10 просто шапку с логотипом и просто чистый лист. По ощущению, идет компиляция страницы для первоначального отображения. Причем нагрузка на трафик не сильная, а вот нагрузка на проц просто чудовищная. Такая же проблема хорошо заметна и на десктопе, если немного опустить скорость работы процессора.


Определенно стоит провести оптимизацию показа первого экрана. Мне кажется слишком много там сейчас выполняется фоновых действий, которые съедают ресурсы проца, откладывая первый показ.


По возможности отложить загрузку модулей, которые не нужны для первого показа. Например на главной не обязательно знать как рендерить конкретную новость, а в новости не обязательно знать как рендерить главную. Здесь лучше всего использовать модель загрузки lazy load module


Пред компиляции готовых HTML страниц нет — это конечно плохо.


Общий вывод:
Плиточный дизайн в стиле медузы конечно хорошо. Отсутствие пред компиляции страниц и очень тяжелые скрипты рендера приводят к большим задержкам первого показа. Сайт кажется очень тяжелым, но при этом ничего такого сверх тяжелого на нем я не вижу. Если выявить проблемы со скоростью рендера, то это, мне кажется, может существенно сократить время первого показа.

Спасибо за уделенное время, работу над оптимизацией конечно же ведем, жаль что не такими темпами, как хотелось бы, но все будет и пререндер и снижение Time to Interactive до вменяемых значений.

Почему не уговорили заказчика отказаться от бесконечной прокрутки?

Но этот вопрос обсуждался? Вы же сами говорите, что "… заказчики — классные профессионалы в медиа, но среди них нет ни одного технического специалиста". Вы пытались им объяcнить, что с точки зрения UX, бесконечный скролл — зло.
К примеру, я прокрутил 5-6 страниц вниз, открыл новость, потом вернулся назад, и я опять на первой странице, мне снова надо прокручивать 5-6 страниц вниз.

WordPress вам не мешал получить все эти возможности. Вообще не встречал ситуации, когда WordPress не справляется. Был опыт внедрения алгоритмической ленты, но и тут получилось удачно подружить python с php.
Жаль, что сообщение об опечатках оторвали и не вернули. Постоянно приходилось им пользоваться.
Эта задача есть у нас в backlog, мы обязательно вернем эту функциональность.
Технических деталей почти нет. Больше всего не понятно зачем бежали с WordPress, если он на самом деле не ограничивал ничего что нужно было.

  • Новая админка — делается на WP.
  • Быстрее дорабатывать — нет, WP знает больше людей и он документирован, если вашего программиста придётся заменить по болезни, то будет медленнее вводить в курс дела человека со стороны.
  • Новый бэкенд стабильнее работает — ????
  • Запросы теперь проще и работают быстрее, потому что идут к нашему серверу на Laravel и в специализированную БД, а не в универсальный WP. — ???? Вы смогли сделать таблицу ещё проще, чем в WP? Или в чём магия? Там и так минимум полей, часть из которых не задействована в выборках.

Такое ощущение что переделывали просто потому что не разобрались.
Это как в Linux — работать надо с тем ПО, в котором разбираешься.
Да, а я не разбираюсь ни в каком, поэтому Linux говно.
  • Новая админка делается не на WP, т. к. заказчику необходим удобный пайплайн подготовки статьи к публикации.
  • И все таки разрабатывать и дорабатывать SPA админку быстрее чем потрошить php страницы в WP перекраивая под наши нужды, но безусловно WP знает больше людей.
  • Новый бэкенд стабильно работает — Мы с командой уже год спим по ночам. А не играем в красноглазиков.
  • Все таки WP это универсальное решение с соответствующими плюсами и минусам, а универсальное всегда больше и сложнее кастомного и уж точно менее гибкое, поэтому мы для наших нужд сделали выбор в пользу кастомного решения.

1) не разобрались с WP REST
2) потрошить и не надо, это делается через API
3) WP тем и хорош, что стабильно работает
4) Утверждать о том что что-то так просто потому что вы так говорите — логическая ошибка.

А как вы выстраиваете очередность ленты, когда сначала 33-66% а потом 25-75%? Появляется новый пост — он должен дождаться брата по ширине экрана? Или поджимаем картинку предыдущего превью под формат?

Если правильно понял вопросы.
  1. создаются линии с указаными размерностями карточек т. е. каждая линия несет в себе определенные варианты карточек например 3x33, 2x50
  2. Нет никто никого не ждет, идет обычная ротация постов
  3. На каждую обложку материала сгенерировано несколько вариантов размеров этого изображения и зная базис карточки мы выбираем подходящую обложку.

Самый плохой тип цензуры — самоцензура.


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

Не совсем понял насчет wp, php и повышенной нагрузки. Все же можно кэшировать на уровне веб сервера.
Контент менеджеры обычно в шоке от самодельных cms. Как бы они не казались разработчикам удобными и надежными до wp drupal им далеко

Как раз наоборот админка «тюнится» под конкретные задачи редакции, так чтобы редакции в итоге стало удобно, укладываться в сроки, не пропускать задачи для фоторедактора, корректора и пр.

Что то мне подсказывает что конкретные задачи редакции не являются полностью уникальными и неповторимыми. И по озвученной Вами теме с флоу редактирования в wp даже беглый и поверхность ный почту дал результаты в виде плагинов.
Вторая часть проблематики которую я не озвучил еще это жизненный цикл системы. То что на ура пишется нужно будет в конце концов кому то поддерживать. И тут у самописных продуктов все не так хорошо. Нет документации, не устоявшаяся структура приложения,

Не проводили анализ того, что именно было боттлнеком на WP беке? Не рассматривали вариант headless WP с новым публичным фронтом? Тогда редакция могла бы продолжить пользоваться старой админкой.

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

А чего не на друпале? (типа, гибкий, мастшабируемый, одной ногой в симфони, композер, вот это фсё)

В большинстве случаем, кастомное решение конечно быстрее замутить снуля, чем подгонять тот же WP под нужны клиента. Обратная сторона этого подхода — клиенту придется и дальше переписывать все снуля, если он вдруг решит уйти от вас, так как другой разработчик явно не заходет возиться с кастомным решением и скорее всего сделает свое. В защиту WP можно сказать, что практически все можно реализовать плагинами. В результате, как ни крути, это будет стандартизированное решение, под которое и найти народ легче, чем под свой велосипед. По крайней мере, если смотреть со стороны и на базе собственного опыта. Аворам конечно же виднее, так как они больше в теме :)
Sign up to leave a comment.