Оптимизация загрузки сайта (ступор)

2.5 секунды это не нормально, да и 1.9 секунды тоже. Вообще больше 0.5 секунды это уже повод для паники для обычных страниц (особенно главной).

Что касается счетчиков и других "внешних" факторов - именно их загрузку Вы никак не оптимизируете, потому что они внешние. А загрузку Вашей страницы они очевидно не задерживают, иначе она грузилась бы не 2.5 секунды, а значительно больше.

Сие пробовали?

Все тяжелые вещи перенесите на конец страницы: жабоскрипты, статистику, баннеры, счетчики, чтобы они загружались в последнюю очередь, уже после контента.

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

http://www.whitehouse.gov/ - это на Друпале, если что.

Вы говорите "CMS отдать контент" очевидно подразумевая контент генерящейся страницы (раз речь про цмс и то что она генерит), без статики и времени загрузки (отдает-то его уже апач или нгникс)?

Если так, за тысячные секунды - вряд ли, за сотые - реально хотя не всегда нужно, а вот за десятые доли секунды - это норма. Мы как бы оптимизацией php/mysql уже далеко не первый год занимаемся, и если сайт изначально не спроектирован как черт знает что и на странице не используется raw поиск по гигантской базе, то пока еще ни одного сайта не видели, который за разумное время адекватными методами нельзя было бы в 0.5 секунды максимум утоптать. А "бытовуху" типа форумов на 300-500к сообщений или магазинов на 30-50к товаров - можно и в сотыми секунды измерять, при условии конечно что это будет не вирт.хостинг за 2 бакса, а хотя бы сервер от хетзнера за 50 евро.

0.35 секунды если что. При том что друпел в общем-то считается достаточно тяжелой цмс-кой. Есть и другие примеры под рукой - хабр - 0.47, сёрч - 0.39. И даже у "серьезных" цмс типа битрикса http://www.softkey.ru/?show_page_exec_time=Y - 0.79 секунды. Наш 6-летний клон нюки 0.016с:) Да ни у кого время загрузки секундами не измеряется...

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

Вот по этому поводу точно помним был солюшен на хабре (к сожалению ссылку сейчас не найти), и поиск по drupal.org ( nginx + imagecache ) дает сообразное количество результатов. Вроде популярная проблема, но лично не сталкивались.

edogs, любопытно...

Я сейчас, пока общаюсь, как раз мучаю конфиг связки Apache2 + nginx фронтэндом. Под Drupal7.

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

у меня стабильно 0.6. при том что это не хостинг, а сервис Akamai.

Это какая например? Не сможет.

Таблицы по 200 к записей

некоторые запросы с группировками

И по моему предыдущему опыту (работы сайтов с таблицами по 1-5 кк записей), для меня предел 0.0150 - обычно укладываюсь в 0.013, на обычном хостинге без программных кеширований.

Играйте с индексами, настройте память сервера под работу с базами (увеличьте кеш индексов мускула)

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

Посмотрите долгие запросы в логах базы

Такое время как у вас бывает при работе с внешними АПИ долгими какиминить (яндекс поиск отдает апи за 1-2 сек максимум)

AlexVenga добавил 03.11.2011 в 03:29

По внешним рекламным системам есть такой прикол (может и бредовый, но в голову сейчас пришло только это)

Делаете контент страницы вверху ХТМЛ документа и выплевываете его на экран флушем, затем выплевываете оставшиеся дивы, в которых реклама и прочая счетчиково-яваскриптная бредятина, затем они ЦССом расставляются на необходимых местах.

По идее тогда 100% сначала покажется юзеру документ, а потом неторопливо будет JS подгружаться

neznaika, эх, да всё про него, про Drupal.