Расскажу еще один способ увеличить скорость загрузки странички. Пожалуй, этот способ является самым простым.

Все современные браузеры умеют распаковывать заархивированные html страницы. А проверенная статистика говорит, что 80-90% всех страничек передаются в сжатом виде. Значит - давайте отсылать пользователю заархивированные html-ки.

+ Из-за многочисленного повторения тегов, страничка отлично сжимается. В средем в 10 раз! Меньше размер - быстрее загрумся. Все просто

- Требуется чуть больше ресурсов сервера (собственно для архивации)

Мое личное мнение: сжатие в 10 раз компенсирует незначительную нагрузку на сервер. Так что я всегда применяю этот метод.

А как архивировать?

Есть 2 способа.

1й способ. Архивация самим скриптом. Дописываем ко всем своим css и js файлам расширение php (или еще какое нибудь, мне просто проще сделать пример с php) и вставляем след кусок кода:

 

//gzip me

if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) {

ob_start("ob_gzhandler"); 

} else { 

ob_start();

}

2й способ. Заставляем веб сервер архивировать посылаемый компоненты

Второй способ более красивый и правильный. Как его реализовать - спросите у гугла, слишком много и долго писать. И еще, архивировать картинки, mp3, и прочие медиа нет смысла. Они уже заархивированы.

 Кто знает, что такое Firebug? Кто знает, что такое YSlow? Если читатель не знает, то советую покопать интернет в поисках. С помощью этих инструментов я добился увеличения скорости загрузки своей самой тяжелой страницы с 7 - 10 секунд до 2 – 4.

Как подсказал мне YSlow, на моей страничке слишком много css-компонентов, попросту говоря картиночек. Проблема не в размере картинки, а в их количестве. Дело в том, что к каждой картинке браузер посылает отдельный http запрос на сервер. Например, такой:

 

GET /site/images/button.gif HTTP/1.1

Host: localhost

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6

Accept: image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://localhost/site/style.css

Cookie: WRUID=0; show_filter=true; PHPSESSID=feb80f629f434419493967285c7967cb1

If-Modified-Since: Fri, 13 Nov 2009 07:40:38 GMT

If-None-Match: "2107f-2fe-4783bc6a5c980"

Cache-Control: max-age=0

Firebug показал, что мой сервер одновременно обрабатывает 5-7 запросов на картинки. Остальные ждут(!) в очереди.

Выход нашелся быстро. Использование css спрайтов. Что это такое? Спросите у гугла.

 И настал тот день, когда Ваше творение увидят конечные пользователи. Наступил день, когда Вам так радостно и немного страшно. Даже если Вы матерый и опытный, проводили ежедневно всевозможные автоматические и ручные тесты, Вы уверены, что система работает на 5+ по пятибальной шкале – не было испытания живыми пользователемя в реальных полевых условиях. Нестоит недооценивать клинического идиотизма пользователей. Они найдут слабые места. Нестоит недооценивать юных хакеров, ведь искать уязвимости – модно.

Как минимизировать свои страхи по поводу живого испытания? Предлагаю пару инструментов:

• Обратная связь в виде “Я нашел проблему на сайте!”, “Хочу предложить фичу!”.

• Всегда держать под рукой телефон, лептоп, и выход в инет.

• Если есть сомнения в каком-то элементе – не спешите с релизом. Отговаривайте заказчика, невключайте этот элемент.

• Представте себя в роли атакующего сайт. Проведите конкурс среди своих друзей или сотрудников “Кто быстрее поломает систему”.

У меня в проекте уже полгода присутствует возможность генерировать отчеты в pdf. Идея такова: выбирабтся данные из БД, потом эти данные группируются в php и все это сохраняется в XML с помощью DOM. Далее включается механизм превращения xml в pdf. XML нужен для кеширования и расширяемости в будущем (pdfа мне будет мало и добавятся новые форматы).

Сегодня колчиество данных стремительно растет и отчетики мои стали очень долго генерироваться. Полез оптимизировать:
SQL запросы выполняются быстро
DOM строится медленно. Полез туда. Выяснил, что надо аккуратно пользоваться strtotime() и лучше все вычисления с датами производить в timestamp.

Производительность выросла на 50-70%!

 Вот это вот new! должны быть красным цветом и можно жирным шрифтом, если надпись большая. Где-то так:

New! Мы добавили автоподсказки к окну поиска.

О чем это я? У всех хотя бы раз в жизни обновлялся софт. Часто или редко, такое встречается. А в скольких случаях, пользователь замечает разницу до и после обновления? Лично из моего опыта: 1% (это мой google chrome под linux, чуть ли не каждый день обновляется и новые фичи как правило заметны).

Вот к чему я веду. Сделали, что то новое - сфокуcируйте внимание пользователя. Тогда он подумает:

• Вау, да этот новый поиск весьма удобен.
• Эти новая панель гораздо круче смотрится.
• Разработчики не зря свой хлеб едят, а где powered by? Ага, надо с ними связаться, у меня есть пару идей.
• Хм, этот сайт стремительно развивается, может с ними сотрудничать?

Ну ведь правда? Надпись прилепить 5 минут делов, а так приятно.

Даже на этапе разработки, когда нет пользователей. Есть один заказчик - он и есть первый и главный пользователь. Его внимание нужно фокусировать на свеженьком. И не только из-за пунктов перечисленных выше. Заказчик должен видеть над чем Вы работаете. Иначе он будет думать, что Вы бездельничаете. Увы. Но так часто бывает. И ничего не поделать.

 

Домашнее задание: как доказать заказчику, что нужен рефакторинг?

Вы поняли, что от Вас требует заказчик. Послушались, потрудились и вуаля - нате, проверяйте. Заказчик посмотрел - все ништяк, всем доволен. Вы с чистой совестью идете домой.

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

Первое незамедлительное действие (и вполне логичное) спросить его: "А что ты, заказчик, такого сделал с системой?". Ведь надо найти источник ошибки. Вы же к этому функционалу не прикасались уже больше месяца. Может это последние редактирование, может изначально что-то не так и тд. Заказчик отвечает, сделал А, а оно Б. Вы пытаетесь в тех же полевых условиях сделать А - Быстро найти ошибку!получили В (предположим, что это правильно, система и должна была выдать на событие А выход В). Что делать?

- проверять на кроссбраузерность
- проверять на кроссплатформенность
- и в том же духе

Проверили. Нифига. После А идет В. Хоть убей. Посещают мысли о клиническом идиотизме заказчика.

- задать вопросы в виде "Что делал, только подробно? Что ожидал увидеть? Что увидел?"

Такая штука должна помочь. Такая формулировка позволяет максимально точно определить баг.

В моей практике был случай, когда и магические вопросы не помогли. Я был злой. Вообще все были злые. Проделав все выше указанные способы, я решил трассировать все SQL запросы в лог файл, а запросы с ошибкой в отдельный файл. На добавление этой фичи у меня ушло меньше 20 минут. Залил на сервер. Попросил заказчика покликать А. Просмотрел лог. Нашел fail (за 2 минуты). Пофиксил баг - 0.1 минуты. Заказчик начал жаловаться 3(!) дня назад.

Выводы делайте сами. Все очевидно.

Обожаю вебдевелопмент и все что с этим связано. Об этом и буду писать: как граммотно кодить, как правильно управлять и планировать