Карта «Коды Стран Мира» отображает 245 доменов верхнего уровня, включая все страны ООН и многочисленные острова и территории.

Ни для кого не секрет, что работа с базой данных занимает большую часть работы практически любого сайта. И именно работа с БД чаще всего является узким местом веб-приложений.
В этой статье хотелось бы дать практические советы использования MySQL.
Сразу оговорюсь:

• данная статья написана про MySQL, хотя общие вещи скорее всего справедливы для любой СУБД.
• все написанное в статье является моей личной точкой зрения, и не является истиной в последней инстанции.
• советы не претендуют на новизну и являются результатом обобщения прочтенной литературы и личного опыта.
  
• в рамках данной статьи я не буду касаться вопросов конфигурирования MySQL.

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Ниже перевод статьи «Optimizing Page Load Time», в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.

Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.

Что влияет на загрузку страницы?

Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.

читать дальше на webo.in →

В моем проекте очень много классов взаимодействуют на клиентской части. Каждый класс лежит в отдельном файле для удобства разработки. Хорошей практикой для увеличения скорости загрузки страницы, является уменьшение количества запросов к серверу. Поэтому чем меньше файлов и рисунков включать в страницу тем быстрее она загрузится. В случае с рисунками – СSS спрайты помогут уменьшить количество запросов. А в случае с js и css файлами – это конкатенация файлов и сжатие. Об этом и поговорим.

Очень удобный инструмент с открытым исходным кодом js-builder



Отличный инструмент для того чтоб сформировать в правильном порядке конкатенацию файлов. Работает с любыми расширениями, которые задаешь. Также сжимает js.
В моем проекте я использую библиотеку prototype.js. Билдер при сжатии прототайпа выдает эксепшн. Поэтому я скачал исходники и перебилдил так чтоб билдер занимался только конкатенацией без сжатия. Пересобранную длл, можно скачать тут
Билдер также содержит консольное приложение. А это то что нужно для билда.
Далее необходимо сделать компрессию файлов которые сгенерирует билдер.
Для этой цели я использовал YUI Compressor. Отличная библиотека с высокой степенью сжатия.
Осталось только как то автоматизировать процесс сборки. Для этого я написал batch файл (я в виндовс работаю).
Выглядит он (build.bat) примерно так
set path1=D:\Projects \build\

%path1%JSBuilder\JSBuildConsole.exe /path=%path1%MyHeritageBuild.jsb

java -jar %path1%yuicompressor-2.3.1\build\yuicompressor-2.3.1.jar
%path1%build\output_file_from_js_builder.js -o %path1%target-min.js

java -jar %path1%yuicompressor-2.3.1\build\yuicompressor-2.3.1.jar
%path1%build\style-all.css -o %path1%style-all-min.css


В моем случае джс билдер на выходе дает 2 файла — css и js, а компрессор их сжимает.
Надеюсь это поможет вам создать удобный процесс сборки файлов.

Эту статью я взял из своего техноблога на сайте www.kigorw.com

Примечание: ниже перевод статьи Julien Lecomte «The Problem With innerHTML», в которой автор рассматривает проблемы при использовании метода innerHTML в современных браузерах и предлагает ряд советов, как ее можно избежать. Мои комментарии далее курсивом

Свойство innerHTML крайне популярно среди веб-разработчиков в силу своей простоты и удобства, поскольку оно совершено элементарно позволяет заменить HTML-содержание у конкретного тега. Можно также воспользоваться DOM Level 2 API (removeChild, createElement, appendChild), но использование innerHTML гораздо более простой и эффективный способ для модификации DOM-дерева. Однако, есть ряд проблем при использовании innerHTML, которых следует избегать:

• Неправильная обработка свойства innerHTML может привести к атакам, связанным со script-инъекциями (XSS) в Internet Explorer, когда HTML-строка содержит вызов <script>, помеченного как отложенный: <script defer>...</script>
• Выставление свойства innerHTML уничтожит все текущие вложенные HTML-элементы со всеми обработчиками событий, что потенциально может вызвать утечки памяти в некоторых браузерах.

Есть и еще несколько более мелких недостатков, которые тоже стоит упомянуть:

• Нельзя получить ссылку на только что созданные элементы, вам приходится добавлять код для получения ссылки на них вручную (используя DOM API).
• Вы не можете выставить innerHTML для всех HTML-элементов во всех браузерах (к примеру, Internet Explorer не позволяет выставить innerHTML для строки таблицы (tr)).

Многие наверняка сталкивались с проблемой, когда какой-нибудь текст нужно выводить в одну строку. При этом текст может быть весьма длинным, а ширина блока, в котором этот текст находится, обычно ограничена, хотя бы тем же размером окна браузера. На эти случаи придумано свойство text-overflow, которое внесено в рекомендацию CSS3, а впервые было реализовано в IE6, очень давно. В случае использования этого свойства для блока, если его текст больше по ширине чем сам блок, то текст обрезается и в конце ставится многоточие. Хотя тут не все так просто, но вернемся к этому чуть позже.
С Internet Explorer'ом все понятно, что же относительно других браузеров? И хотя в настоящий момент из спецификации CSS3 свойство text-overflow исключено, Safari его поддерживает (по крайней мере, в 3-й версии), Opera тоже (с 9-й версии, правда называется свойство -o-overflow-text). А Firefox — нет, не поддерживает, и даже в 3-й версии не будет. Печально, но факт. Но может можно что-то сделать?

Юзабилити и практичность, а не визуальный дизайн, определяют успех или провал любого веб-сайта. Так как именно пользователь — единственный, кто кликает мышкой и, таким образом, принимает все решения, то одним из стандартных подходов для создания успешных и прибыльных веб-дизайнов стал «дизайн, ориентированный на пользователя» (user-centric design). В конце концов, если пользователь не умеет пользоваться той или иной функцией, ею можно легко пренебречь.

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

INTRO

Все мы знаем что PHP предназначен для быстрого создания динамических Web страниц. Во всяком случае именно это написано на официальном сайте разработчиков PHP. Однако почему бы не попробовать найти PHP «немного» иное применение, например, попробовать создать полноценное приложение для Windows? Заинтересовал? Тогда понеслась!

Примерно три недели назад стартовал проект, посвященный методам оптимизации времени загрузки веб-страницы на клиенте.

Почему оптимизация?

На мой взгляд, на текущий момент веб-разработчики очень мало уделяют внимания доступности (accessibility) и удобству пользования (usability) проектов, над которыми работают. Для них сайт — это килобайты кода и пара картинок, которые нужно как-то показать клиенту. О пользователе никто при этом не думает, в лучшем случае, прикрываясь такими выражениями, как: «у меня отсюда и так все быстро грузится» или «каналы сейчас не те, что 10 лет назад».

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

Почему клиентской части?

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

Естественно, это совсем не так. Загрузка страницы это не только HTML. Существует множество инструментов, которые позволяют в этом убедиться, проанализировать процесс целиком и найти в нем слабые места. Но именно такой анализ, который находится, фактически, на стороне пользователя и должен быть проведен в первую очередь при оценке доступности веб-сайта, зачастую вообще не проводят либо делают быстро и некачественно. А ведь он может позволить уменьшить время загрузки страниц на порядок.

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

Далее перевод :-)