рекомендации по оптимизации работы интернет-ресурсов

Во-первых, при работе с HTTP не забывайте:
  • избегать HTTP запросы – чем меньше их, тем лучше;
  • использовать заголовки «Cache-control» или «Expires»;
  • забыть про редиректы (HTTP Redirect).
Во-вторых, скрипты Java требуют внимательности:
  • При написании документа в его начале обязательно указывайте ссылки на файлы с таблицами стилей (link href).а в конце прописывайте ссылку на файл JavaScript (script src);
  • Вставки CSS и JavaScript храните отдельными файлами;
  • При использовании CSS и JavaScript уменьшайте размеры файлов с помощью утилитов YUI compressor или JSMin. Они позволят разобраться с ненужными комментариями и лишними пробелами, а так же сократят переменные.
  • Проверяйте файлы скрипта на дублирование кодов, что заставляет догружать ставки и задерживать обновление страницы;
  • Избавьтесь от запросов Java к DOM хотя бы частично, выполнив кэширование, отбрасывающее повторяющиеся запросы;
  • Все блоки Java вместе с картинками оставляйте на загрузку в последнюю очередь;
  • При обработке событий в крайнем случае применяйте onresize, аудиты проводите с помощью YUI Event, а привычный «onload» замените на утилиту DOMContentLoaded.
В-третьих, при работе с Ajax запросами:
  • Кэшируйте их;
  • используйте метод GET, вмещающий все запросы в один пакет TCP.
В четвертых, CSS тоже можно оптимизировать:
  • Не засоряйте CSS вычислимыми выражениями (expression);
  • Обязательно сбросьте буфер еще при старте генерации страницы с помощью периодического вызова flush() в PHP, тогда пользователь быстрее загрузить CSS файлы;
  • Для загрузки CSS используйте в начале страницы не @import, а «link»;
  • забудьте про фильтры, они поддерживаются исключительно IE/ лучше возьмите в оборот PNG8.
В-пятых, будьте терпеливы и внимательны при написании сайта:
  • Все страницы перед отдачей сжимайте, например, через утилиту mod_gzip;
  • Для доставки контента используйте услугами таких сетей как Akamai;
  • В странице не прописывайте более трех ссылок на другие домены, будь то обращения к картинке или iframe, ибо сайту приходится дожидаться ответа чужих серверов;
  • При использовании iframe'ов, постарайтесь оставить только основные, а так же избавиться от ссылок на чужие ресурсы, иначе часть страницы может остаться заблокированной;
  • В Apache настройте ETags;
  • Рационально отбирайте те скрипты, которые понадобятся при первоначальной загрузке;
  • А весь контент делите равными долями по имеющимся доменам, тогда браузер подгрузит все необходимые данные одновременно;
  • Минимизируйте количество элементов в древе DOM, убирайте лишние тэги;
  • Банально, но следите, чтобы у вас не появлялась ошибка 404;
  • Урезайте размеры Cookie: сокращайте имена, определяйте продолжительность жизни, убирайте все лишнее;
  • Во вспомогательных страницах вместо Cookie используйте вынесение всех скриптов на static.domain.com;
  • Если решили добавить Flash, заранее определите crossdomain.xml.
В-шестых, обратите внимание на изображения:
  • Поработайте над используемыми изображениями (уменьшите размеры используемой палитры, заливайте картинки в формате *PNG с помощью утилитов optipng, pngoptimizer или pngcrush, удаляйте комментарии, а в случае *jpg оптимизируйте файлы через jpegtran);
  • Для создания фоновых картинок используйте CSS спрайты;
  • Проверяйте совпадения реального размера картинки с прописанными параметрами width и height (тогда не будет проблем с масштабированием).
  • Помните, что созданный favicon.ico должен не превышать 1 Кб и быть кешируемым, ибо поисковые системы используют его в каждом десятом запросе.
И, наконец, в-седьмых, при создании сайта, оптимизированного под мобильные устройства:
  • Не создавайте страницы, превышающие 25 Кб;
  • Используйте multipart блоки, что позволяет производить автоматическую упаковку всех дополнений в приложения.

Highload оптимизация

Зачастую, «бутылочным горлышком» вашего приложения является база данных, таким образом перво-наперво включаем slow query log и смотрим какой запрос у нас самый медленный, и думаем что с ним делать, если не можем вкурить проблему — зовём старших, пусть тоже повтыкают в EXPLAIN (хабр) вашего чудо-запроса.

Но, опять же ссылаясь к моему опыту, большинство проблем с БД решают правильные индексы. Легко запомнить, что индексировать следует внешние ключи, и всё что у вас в WHERE, ORDER BY, GROUP BY (список не полон, для начала – самое оно).

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

Поиск с использованием LIKE это плохо. Полнотекстовый с MyISAM уже лучше. Внешний аля Sphinx — рулит и бибикает для MySQL и PostgreSQL, инфа достоверная 100%.

Но это полбеды, проблем в БД может подкинуть и само приложение — обращение к БД в цикле/рекурсии или еще каким извращенным способом могут привносить удивительные поправки в результаты нагрузочного тестирования. Сделайте простой профайлер ваших запрос и проследите на каких страницах количество запросов начинает зашкаливать (особенно это касается типа-ORM и почти-Active Record, когда один объект = один запрос, или даже не один). Всем кто уповает на магию фреймворков, иль каких-нить gem-ов — не надейтесь, всё о чём я написал в равной степени относится к большинству языков web-программирования, г… код есть везде, он вездесущ.

Ну, а теперь о главном, нет о главной странице в 1,5 метра — дождется ли её загрузки пользователь со скоростью доступа в 256кбит? Клиентская оптимизация должна проводиться в обязательном порядке: YSlow да Page Speed вам в зубы. Да если погуглить, то даже небольшая правка htaccess для apache улучшит ситуацию:
# Enable ETag
FileETag MTime Size

# Enable Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript

<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 1 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 604800 seconds"
  ExpiresByType text/javascript "access plus 216000 seconds"
  ExpiresByType application/x-javascript "access plus 216000 seconds"
</ifModule>

Пожмите JavaScript и CSS, да переключите jQuery на Google CDN.

C чего начать оптимизацию блога?

C чего начать оптимизацию блога?
Сократите количество запросов к базе данных.

Имя блога
<title><?php bloginfo( 'name' ); ?></title>

Эта функция берет из базы данных название блога, которое вы ввели в настройках. Вы можете безболезненно избавиться от нее, заменив на название блога.
<title>Блог о Wordpress</title>


Ссылка на сайт
<?php bloginfo( 'url' ); ?>

Эта функция возвращает прямую ссылку на главную страницу сайта. Ее можно заменить на саму ссылку:
http://web.abcd.bz/

или даже на ее относительный вид, который автоматически трансформируется в текущий домен:
/


Папка, в которой находится style.css
Наверняка вы встречали подобную функцию:
<img src="<?php bloginfo( ‘stylesheet_directory’ ); ?>/images/myimage.jpg"/>

Она возвращает из базы данных абсолютный путь к папке, в которой находится файл стилей style.css. Эту функцию, как и в предыдущем случае, можно заменить на абсолютный, а лучше — на относительный путь к этой папке:
<img src="/wp-content/themes/mytheme/images/myimage.jpg"/>


Папка используемой темы
<?php bloginfo( 'template_directory' ); ?>/include/metabox.php ?>

Если вы не собираетесь менять тему и настройки, с ней связанные, то можете вместо функции, извлекающей из базы данных абсолютный путь к папке с текущей темой использовать относительный путь к этой папке:
/wp-content/themes/mytheme/include/metabox.php ?>


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

Изучив код всех файлов используемой темы и заменив в них подобные функции на прямые данные, можно сократить количество обращений к базе данных в несколько раз, что положительно скажется как на быстродействии (ведь блогу не нужно будет копаться в базе данных для получения нужных данных — вы предоставляете ему их в явном виде), так и на снижении нагрузки.