Есть у нас на поддержке сайты, причём на разных CMS, и некоторые из них лагают. Google pagespeed, помимо прочего, ругается на длительный ответ сервера. Следовательно надо разобраться в каком месте код тупит. Подскажите, господа разработчики, кто какими пользуется средствами для выявления слабых мест PHP скрипта и, возможно, длительных запросов к базе? Мне в голову приходит написать собственный анализатор для index.php, который будет измерять время от начала до конца выполнения всего кода, и память, а потом сохранять это где-нибудь в файл или базу вместе с $_SERVER['REQUEST_URI']. Может есть уже готовые инструменты? Лагающие сайты есть на 3-х CMS. Bitrix, wordpress и joomla. Если есть ссылки на доки по их оптимизации прошу так же скинуть под кат.
Долго мучиться придётся. Возьмём, к примеру, "наименьшее зло" среди этих фикалий - Bitrix. Проверим его родной сайт. Результат очевиден, т.к. если лепить из говна пулю, то по форме пуля получится, а по содержанию останется говно. --- Добавлено --- Сорри за выражопывания, это на меня плохо влияет @MouseZver
@romach, всё равно, 12/100 и 54/100 - разница ощутима. С другой стороны, PageSpeed - это только рекомендации, к которым можно прислушаться, а можно забить на них. Фанатики пытаются сделать 100 из 100, но это всего лишь понты и не больше.
это SPA. Ему можно. Зато потом ничего не мигает. Если не хочешь SPA - там есть в настройках упрощеный вид. --- Добавлено --- если страница на локалке грузится больше 1 секунды, то CMS гавно)
@IvanRsn В битрикс вполне достаточно встроенных инструментов для анализа производительности и поиска причин тормозов. На основании которых уже можно работать с кодом и настройками. Вот, если администрация не прибъет ссылку, небольшая статья по этому поводу. --- Добавлено --- Т.е. администратор сервера и разработчик по умолчанию офигительно грамотные чуваки?
Наилучшее на сегодняшний день решение для APM-мониторинга и отладки это NewRelic. Если по какой-то загадочной причине ваш девопс до сих пор не обязал вас его использовать, то стоит начать.
Не заражайся этой ерундой от дебилов ) Большинство сайтов, в т.ч. с большой посещаемостью таки работают на той или иной CMS, в т.ч. и вордпресс и битрикс. Просто потому что в большинстве случаев большего и не нужно, а тормоза - следствие криворукости тех кто "натягивал" шаблон. Нет. SPA уже умеют SSR, загружаться частями и даже плеваться в браузер "чистым" html.
я согласен с тем, что если можно склепать сайт на CMS, то нужно сделать именно так на начальном этапе. а потом, если проект взлетит, то написать нормальный сайт на уже поднятые деньги. инвестировать, так сказать, в комфорт пользователей. но сам с CMS работать не хочу. Хочу писать код) А по поводу SPA - думаю, что уже сегодня стоит задуматься о том, чтобы писать серьезные проекты именно по этому принципу.
Всяческие админки и закрытые приложения, куда не ходят поисковики именно так нынче писать и нужно. Хотя бы потому, что если разобраться - это быстрее и удобнее, чем традиционный подход. С тем как все это в действительности индексируют поисковики, честно сказать, не знаю пока. Если у кого есть реальный опыт - с удовольствием бы послушал. мб @Zuldek --- Добавлено --- Вот с этим не могу не согласиться ))
А разве CMS означает уход от написания кода? CMS просто забирает на себя рутину. Ну 1 проект напишете, 10, 50..... Надоест делать одно и то же... Предположим веяния времени потребуют некий тривиальный функционал (например сейчас необходимо согласие на обработку данных или работу с онлайн-кассами). Ни чего интересного в этом нет - просто рутина. В случае CMS просто обновляюсь и все (иногда настройки). А тут самому писать, хотя все "обычно и понятно". Между тем полно проектов, где требуется написать нечто действительно интересное либо просто "не как у всех".... Я именно поэтому похоронил свою CMS - надоело заниматься рутиной.
а разве со временем не обрастаешь наработками, которые можно копипастить при необходимости? --- Добавлено --- @romach делаешь через History API. Где-то читал про подход, при котором браузеры не поддерживающие history API - реально переходят по ссылкам. Браузеры же поддерживающие эту технологию - обрабатывают ссылки так, как тебе надо (перезагружают только часть страницы) Т е все ссылки в коде остаются и поисковые боты по ним ходят.
обрастаешь. но появляется необходимость в функционале, который, в принципе тривиален, и тебе его надо делать, иногда даже не "когда нибудь как будет время", а "вчера". И чем больше становится система (или набор наработок)тем больше становится мелочей которые делать скучно. А сниппетами обрастаешь всегда, у меня для битрикс тоже куча всякой всячины. Естественно это мой субъективный взгляд, может мне так везет, что интересных задач и без того хватает. Но главное в этих задачах - они разные.. А не один и тот же код пилить годами.
Это да, но проблема в том что SPA по большей части рисуются браузером на месте, подгружая по необходимости нужные данные. Гугл умеет смотреть на страницу как браузер, Яндекс - нет, он увидит лишь набор из шаблонов и скриптов. SSR позволяет делать приложение которое одновременно и страница понятная боту (т.е. нажал на ссылку, получил html) и SPA (рисуются на клиенте), но при этом повышает нагрузку на сервер. Дык вот, гугл меня не волнует, они там знают как делать и даже SSR им не нужен. Но мы живем в России, тут в приоритете Яндекс и он до сих пор застрял в web1.0 ) В принципе, все это решаемо, страницу можно отрисовать на сервере, ссылки выглядят как обычные ссылки, короче все как обычно... Просто я не делал ещё SPA которое должно хорошо проиндексироваться поиском, а инфы и тем более реального опыта по этому вопросу не много. То что есть - бред seoшников к реальности отношения не имеющий.
В корне утопический подход. Ибо если проект взлетит, то в этом случае тут же обнулится. Проект сразу должен быть масштабируемым, причем с минимальной временной задержкой. Это не направление моих интересов. Но нынешние реалии с башни разработчика и управления разработкой всяких веб-проектов показывают: всё SEO сдувает в сторону маркетинга и работы над качественным контентом, что свидетельствует о том, что нужно больше думать о пользователе и его удобстве, а не об оптимизации под роботов, ибо их алгоритмы всё больше и больше нацелены на учет реальных поведенческих факторов, приоритетно над ссылочной массой и прочими факторами. Если кто-то видел доказательство обратного на мало-мальски крупных проектах (не фермах под биржи ссылок), то буду рад почитать об опыте. Я же на личном опыте наблюдал последние годы лишь потери многомиллионных бюджетов по глупости вливаемых в старые подходы продвижения, вместо развития контента. То есть количество и качестве визитов пользователей приоритетно определяет позиции в поисковой выдаче, а не то SPA это на Reactе или нет. Только я бы не воспринимал это как рекомендацию немедленно переписывать действующие сайты на SPA. Статьи на хабре, где люди теряли 30% трафика и позиции в выдаче тоже видел. Все они были не однозначные с тестированием результатов через неделю после перехода на SPA и т.п. С такой же просадкой сталкивались мы при неумелом переходе на новую версию дизайна без SPA... . В общем подход не уникальный: работает - не трож, а новые сложные интерфейсы в особенности для "личных кабинетов" вполне себе годны для реализации в формате SPA.