Что значит «хороший программист»?

Я уже неоднократно в своих статьях упоминал о той огромной важности, которой обладает скорость загрузки сайта интернет-магазина. Стоит скорость загрузки страниц уменьшить с 0.5 до 3-4 секунд, то конверсия падает в РАЗЫ. Вы осознаете это? Вдумайтесь очень внимательно! Это значит, что если страницы грузятся более 4 секунд, то ваш доход будет в 3-8 раз ниже. А это разница, которая может поставить крест практически на любом бизнесе.

Посмотрите на график ниже. Это зависимость уровня конверсии от скорости загрузки страниц в крупном ИМ (Walmart.com). По ней четко видно, что граница 1-2 секунды, это тот предел, при котором вы будете впереди планеты всей, а как только время загрузки зашкалит за 3 секунды, вы превращаетесь в унылую серую массу.


Согласно онлайн опросам факты такие:

• 60% пользователей ожидают, что страница загрузится в течение 3с
• Около 75% пользователей смартфонов покинут мобильную страницу, если она будет загружаться дольше 5с
• Те, кто ушел с сайта из-за низкой скорости, скорее всего покинут его, если зайдут другим путем.

Как правило, скорость работы зависит от выбранной системы управления и от «наворотов» сайта», количества товаров и программиста, который реализует функционал.

Знаете, как обычно в веб студиях рождается пункт в перечне достоинств, что «Сайт полностью оптимизирован для SEO»? Очень просто! Просто берут и добавляют этот пункт в перечень достоинств CMS, на основе которой создается сайт. Еще бы, ведь это утверждают создатели CMS.

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

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

1) Программист оптимизирует БД

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

Приведу конкретный пример. Как-то ко мне попал в руки интернет-магазин, у товаров которого было 45 различных свойств: материал, страна производства, оптовые и розничные цены, вес, размеры, количества на разных складах, наличие специальных атрибутов и куча других… Под все эти свойства по умолчанию резервировалась строка в 256 текстовых символов. Время загрузки страницы, которое по куче параметров (по фильтру), выдергивало нужные товары, составляло около 20 секунд. Товаров было более 50тысяч, свойств много, код ужасен. В результате время загрузки было такое, что пользоваться сайтом было нельзя.

После оптимизации одной ресурсов одной только БД, время загрузки упало до 11-12 секунд. В два раза!
Этим обычно никто не заморачивается. А надо.

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

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

Оптимизация этих процессов в нашем примере сократила время загрузки страницы до 3 секунд

3) Программист должен ломать голову, что из «якобы» нужных динамически обрабатываемых вещей можно убрать в статику и не трогать.

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

4) Программист должен кешировать все, что возможно.

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

Те страницы, которые грузились за 1.2-1.3 секунды, при повторном обращении к ним, выдавались частично из кэша и скорость формирования страниц составляла 0.3-0.6с.

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

Стоит ли говорить, что разница в конверсии, не заставила себя ждать?

Так вот. Хорошие программисты – это редкость. И если вы найдете таких, которые сами радеют за то, чтобы сайт работал как можно быстрее, держитесь за них. Это будет значить очень хорошую инвестицию в проект.
То, что разработчиков и программистов, которые борятся за каждые 10мс загрузки не так много, это одновременно проклятье и огромный позитив.

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

Кейс с анализом быстродействия реального сайта с выдачей рекомендаций

Рекомендации по увеличению скорости работы сайта medafarm.ru

 Примечания

1.       В качестве тестового инструмента используется сервис компании Google developers.google.com/speed/pagespeed/insights

2.       Рекомендации, данные ниже не желательны, а обязательны к исполнению для успешной работы по продвиженю.

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

Перечень слабых мест, описание проблемных зон, причин этих проблем и способы решения
В общем виде, для устранения всех проблем со скоростью, необходимо дать разработчикам ссылку на эту страницу https://developers.google.com/speed/pagespeed/insights/?utm_source=pubinsights&filter_third_party_resources=true&hl=ru&url=medafarm.ru&tab=desktop

и попросить довести показатели теста до зеленой зоны – 85 баллов.

Скорость работы сайта на сегодняшний день имеет очень большое значение в том плане, что если она удовлетворительная, то мы можем бороться за высококонкурентные/высокопосещаемые запросы. В случае неудовлетворительных показателей, сайт получает очень тяжелый балласт, который не дает всплыть в ТОП. Если использовать простое для понимание сравнение, то наличие медленно работающего сайта для подъема по высококонкурентным запросам в ТОП аналогично попытке хорошего пловца выиграть олимпийские игры в заплыве с другими сильными спортсменами, только на него наденут чугунные плавки.

1.      Изображения

На главной странице используются изображения, размер которых можно сократить на 300 кБ. Проблема в том, что большинство людей сидят в Интернет не из дома с высокой скоростью, а из офисов, где подключен сверхдорогой тариф на 0,5-2 Мбит/с на всех в офисе. Для них дополнительные 300 кБ – это до 4-5 дополнительных секунд к загрузке.

Как устранить?

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

Речь идет как о картинках в шаблоне, так и обо всех остальных фото на сайте.

2.      Используйте кэш браузера

Чтобы данные не грузились каждый раз, а загружались только 1 раз, а далее использовался кеш, можно указать непосредственно в заголовках страниц. Как это сделать, описано на страничке помощи Google — https://developers.google.com/speed/docs/insights/LeverageBrowserCaching

3.      Включите сжатие gzip на сервере

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

4.      Необходимо сократить время ответа сервера

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

·         в криво настроенной cms;

·         в дохлом хостинге, который не тянет cms/посещаемость сайта;

·         в неоптимизированной БД

 

На текущий момент, анализатор выдает время ответа сервера 0,78 с. Это катастрофически много. Нормальным временем ответа формирования ответа – 0,2 с. Дайте задание разработчиком поработать над временем ответа сервера.

Сразу оговорюсь, что предложение переехать на супер мощный сервер поможет. Но это будет временная мера, т.к. сейчас посещаемость сайта не очень большая (около 3000 человек в сутки) и на тарифе хостинга со средней стоимостью 600-800 р/мес, хостинг должен справляться с 10-15К посетителей в сутки.

5.      Сократите код HTML, CSS, JS

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

Выводы и комментарии

Подчеркну еще раз. Выполнение рекомендаций 1..4 критично важно. Именно их выполнение сможет позволить повысить быстродействие сайта и попасть в зеленую зону по оценке Google.

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

Единственной адекватной причиной случившегося падения, может быть именно сильное замедление работы сайта. Если до этого был самописный движок, то формирование страниц должно было быть куда быстрее. Что касается серверного сжатия, сжатия изображений и т.п., то все это могло и тогда присутствовать. Но ответ сервера должен был быть значительно ниже.

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

[contact-form-7 id=»3895″ title=»Контактная форма 1″]

Еще по быстродействию сайта – никудышняя структура БД

Еще по быстродействию сайта – никудышняя структура БД

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

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

Нормальная таблица со свойствами для N товаров должна выглядеть примерно так:
Товар 1| id |свойство 1 | свойство 2 |свойство 3| … |свойство m
Товар 2| id | свойство 1| свойство 2 |свойство 3 |… |свойство m

Товар N| id |свойство 1 |свойство 2 | свойство 3 |… | свойство m

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

Такая структура таблицы имеет количество записей по количеству товаров – N. И выделить из нее товары по любому набору свойств можно одним и очень быстрым sql запросом.

Теперь посмотрим, как хранятся данные в том же битрикс.

Там данные разбиты в несколько таблиц.

Одна таблица содержит название свойств. Например:
id_svoistva|name_svoistva
1|цвет
2|размер
..
M|материал

В другой таблице сами значения свойств хранятся в таком виде:
id|id_tovara|id_svoistva|znachenie_svoistva
1|1|1|зеленый
2|1|2|30x34x120

M|1|M|кожа
M+1|2|1|красный
M+2|2|2|30x22x110

2xM|2|M|кожзам

Суть в том, что в таблице со свойствами все данные содержатся последовательно. В результате в этой таблице строчек будет уже не совпадать с числом товаров, а будет умножено на количество свойств. Например, если у вас 10000 товаров и 12 свойств, то число записей в этой таблице будет 120 тысяч против 10 тысяч из первого, нормального варианта.

Но это на самом деле еще пол-беды. Настоящая беда начинается, когда надо выделить из этой таблицы товары по набору нескольких свойств. Если надо выделить только по одному свойству, то ОК, разница во времени будет определяться только числом строк и в общем виде не будет значительной.
НО!!!
Если вам надо выделить из базы товары по 2 и более свойствам, то такая структура может отдать данные только при использовании нескольких запросов. Т.е. одним запросом выделяется таблица с товарами по одному свойству, следующим запросом выделяются товары из первой таблицей по другому и т.д. по количеству свойств, которые надо выделить. Если написать sql запрос, который это делает, то он будет очень сложным и громоздким. Но самое главное, он сильно нагружает SQL сервер и требует очень много времени на выполнение.

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

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