Разгоняемся под SEO

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

Давайте попробуем выделить основные направления, по которым надо работать для достижения максимального ускорения.

группы факторов

• Объем трафика
• Скорость рендеринга страниц
• Скорость выполнения скриптов
• Скорость работы БД

Первые два пункта критичны как статичным HTML сайтам, так и «контент-контроллерам» на базе серверных скриптов (CMS). Два последних больше характерны для CMS.

Объем трафика

Что я здесь подразумеваю под объёмом трафика: в первую очередь, конечно, все те килобайты, которые летят по проводам от сервера, на котором расположен сайт, к клиентской машине посетителя. Это код каркаса сайта, элементы графики дизайна, css таблицы стилей, java скрипты, бинарники flash и т.д.

Что делать?

• стараться делать код шаблона максимально компактным
• использовать минимум графики
• анализировать css и javascript на предмет комментариев и вытягивать всё в одну строку
• использовать gzip сжатие

Никогда не использовать элементы графики, таблицы стилей и скрипты, расположенные на других ресурсах! Google называет это лишними DNS преобразованиями. Нередки случаи, когда подвисший счётчик посещений одним баннером изображением загоняет в ступор браузер, когда не может подгрузить картинку.

Вы же не можете быть уверены в качестве работы и доступности чужих ресурсов.

Скорость обработки страницы браузером или рендеринг

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

Что делать?

Стараться избегать ресурсоёмких приложений на JavaScript и Flash, оптимизировать графику сайта.

Скорость выполнения скриптов

Фишка применения content management систем в том, что рутинная работа по созданию и управлению контентом, поддержкой пользователей и т.д. сводится к автоматизации, которую обеспечивает сервер.

В данном случае мы, как правило, имеем обобщённую модель для построения страничек и документов на лету. Обеспечивается модель серверными скриптами, например php. В отличие от статики на чистом html, странички «билдятся»("build" — от английского «строить», читается «билд») на лету при обращении к какому либо ресурсу.

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

Например, шаблонизатор SMARTY — великолепный инструмент для отделения логики от отображения. На выходе получается две стопки кэш-шаблонов. Первая — обработанные в нативный php код участки логики, вторая — скомпилированные шаблоны с вкраплением вызовов кода из первой стопки.

Работа БД

Поскольку применение CMS подразумевает хранение информации в базе данных, а не в самих файлах вперемешку с каркасом, то как бы быстро не работали ваши скрипты, при медленной БД результат других оптимизаций может не дать никакого эффекта.

Что такое БД сайта? В примитивном представлении — это структурированный на таблицы файл из которого по запросу извлекаются нужные данные и передаются обработчику. Именно по этому важно следить за состоянием БД.

Самое главное, что тут можно отметить, — это важность следить за фрагментацией БД. Старайтесь время от времени производить оптимизацию таблиц.

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

Движков много и не всегда всё, что будет хорошо, к примеру, для MediaWiki, будет также хорошо для Data Life Engine. Анализируйте и сопоставляйте зависимости, если нет возможности подогнать критерии платформы под движок, то всегда есть возможность подогнать движок под критерии платформы.

Думки над публичным

Думки над публичным — это отдельная песня. Если Ваш ресурс подразумевает пользовательскую активность и возможность регистрации, имеет смысл не перекрывать всё, что можно в robots.txt, а просто не отдавать это гостям.

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

Анализируйте какие вещи могут оказаться бесполезными для SEO, старайтесь не прятать их, а просто не отдавать. Здесь стоит заметить, что подача сайта для поисковика в оптимизированном виде может стать причиной штрафа за клоакинг. Правило такое: отдаёте поисковику то же, что и посетителю.

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