Siteko — сайты, хостинг и ИИ

До конца октября у меня был неудобный путь. Покупатель на сайте зовёт менеджера, бот шлёт уведомление в телефон. Пока всё хорошо. А дальше я открывал кабинет во встроенном браузере, входил и только потом отвечал. С телефона это минуты. Покупатель всё это время смотрит на молчащий чат.

Я решил, что отвечать надо прямо на уведомление. Выложил 30 октября, для Telegram и MAX. Отвечаешь на него как на обычное сообщение: свайп или пункт «Ответить». Текст уходит покупателю в чат на сайте как реплика менеджера. Бот в этом разговоре замолкает. Если он уже готовил ответ, он его отменяет. Следующие реплики покупателя приходят новыми уведомлениями, и на них можно ответить так же.

Ограничений я оставил два:
• только текст, до 4 000 знаков. Фото и файлы покупателю не уходят;
• нужен именно ответ на уведомление. Обычное сообщение боту покупателю не уйдёт.

Покупатель может и уйти со страницы. Ждать он не обязан. Поэтому после ответа мне приходит одна строка о том, что стало с текстом:
• «Доставлено в чат» - покупатель на сайте;
• ответ ушёл на почту - он её оставлял, придёт письмо;
• увидит, когда вернётся - почты нет, значок на кнопке чата ждёт до двух часов.

Третий вариант самый слабый. Если покупатель оставлял телефон, я бы просто позвонил.

Свайп не показывает, что спрашивали раньше и какие товары показал бот. Для этого я сделал кнопку «Открыть разговор». История и поле ответа открываются прямо в мессенджере, без входа в кабинет. Обычная ссылка тут не годится, её можно переслать, а это переписка клиента. Поэтому мессенджер передаёт подписанные данные о том, кто нажал, и у меня проверяется право на разговор.

Покупатель видит подпись «Менеджер» и название сайта, без имени. Аватар бота над этим словом я не показываю. Как по мне, это был бы подлог. Человек должен понимать, кто с ним говорит.

Была у меня и своя ошибка. 7 октября поймал её на собственном сайте. Посетитель вечером позвал менеджера, ему ответили из кабинета. Наутро он задал ещё два вопроса, и никто не ответил. Разговор числился за менеджером, бот молчал, менеджера не было. Теперь разговор держится за человеком, только если тот писал в него за последние 30 минут. Покупатель пишет после паузы - разговор сам возвращается боту.

Ночью мне реплики в мессенджер не приходят, чтобы не будить из-за каждой. Исключение одно: я сам ответил в этом разговоре за последние 30 минут. Иначе ответ на мой ночной ответ я увидел бы только утром. Если менеджеров несколько, подключаешь группу. Отвечает тот, кто первый увидел, а в подтверждении стоит его имя.

Сколько покупателей дожидается ответа, я пока не знаю. Функция вышла 30 октября, считать ещё не на чем. Для себя вижу смысл простой: бот пообещал человека, и человек должен успеть. Откуда угодно. Если бот у вас не мой, я бы проверил с телефона, сколько занимает ответ. Написать боту «позовите менеджера» и засечь.

Полный разбор и что проверить в своём чат-боте:
https://blog.siteko.net/articles/otvetit-pokupatelyu-iz-telegram-ili-max

А вы как отвечаете покупателям с телефона? Сколько это занимает?

На днях проверял нашего ИИ-консультанта на живом магазине. Это сайт, который мы делали для клиента, в карте сайта 1 736 адресов. Демо прочитало 300 страниц за 2 минуты 43 секунды. Я задал боту семь вопросов, какие задал бы покупатель. Адрес, часы и график на праздники он назвал верно. Пока всё хорошо.

А дальше пошли косяки. Спрашиваю: «А на 1000 руб заказать можно?». Бот отвечает, что в прайсе много позиций дешевле 1 000 ₽, так что заказ вполне реален. На странице «О нас» при этом прямо написано: «Заказы до 10 тыс. рублей не принимаются». Мимо ушли ещё доставка по России и вопрос, есть ли на сайте страница «О нас». Сама страница прочитана. Первая мысль у меня была невесёлая: так мы будем чинить бота под каждый сайт.

Я разобрался, и оказалось, что так ломается любой магазин с каталогом. Бот не держит сайт в голове. Он режет страницы на фрагменты и на каждый вопрос ищет подходящие. Ищет по смыслу. Сотни карточек с ценами в рублях похожи на вопрос про заказ сильнее, чем одна фраза на «О нас». Нужный фрагмент оказался на 200-400-м месте из 833. До бота он просто не дошёл.

По ходу я нашёл ещё две проблемы, уже наши. 304 фрагмента из 833 были мусором: обработчики Alpine.js вида @click="… => …" ломали разбор HTML, и код с классами оформления уходил в текст. Больше трети базы - мусор. А демо брало страницы «сначала короткие адреса», и 172 карточки ушли на один раздел. Из нескольких крупных разделов не попало ни одной страницы.

Потом я посмотрел на сайты, где бот отвечает хорошо. У них заполнены два поля в кабинете: «О компании» и «Правила компании». Бот держит их в каждом разговоре, без поиска. У демо и у только что подключённого сайта они пустые. Вся надежда на поиск, а он на каталоге промахивается.

Что я поменял в движке, сразу для всех сайтов:
• рядом с поиском по смыслу теперь поиск по словам вопроса, до трёх фрагментов. Число из вопроса весит меньше слова: «1000» - сумма покупателя, а на сайте таких чисел сотня в ценах;
• после первого чтения модель сама выписывает условия с главной, «О нас», доставки, оплаты и контактов. Только в пустые поля, кабинет просит проверить. Цены в правила не идут. Они меняются;
• атрибуты Alpine, Vue и Livewire снимаются до разбора;
• демо читает разделы по очереди, а не подряд из одного.

Замер я гонял на пяти сайтах, по три прогона. Было 54 верных ответа из 69, стало 64. Разница заметная. Один поиск по словам дал всего плюс один ответ, но именно он починил минимальный заказ и доставку. Остальное дали условия в полях. На том магазине медиана времени ответа упала с 11,3 до 5,4 секунды.

Часть проблем бот не исправит. Это дело сайта: страницы разделов без текста, битые адреса в карте сайта, один <title> на все карточки. Если у вас магазин, я бы проверил так:
• условия написаны текстом и словами покупателя, на отдельной странице, а не на баннере;
• в sitemap.xml нет 404 и одинаковых заголовков;
• боту заданы 5-7 базовых вопросов до запуска;
• главное вписано в настройки бота руками, если у сервиса есть такое поле.

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

Полный разбор и что проверить на своём сайте:
https://blog.siteko.net/articles/chat-bot-ne-nahodit-otvet-na-sajte

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

В ошибке сервер писал про 18 писем в час, и клиент попросил поднять хотя бы до 30. Лимит у него был 5. Я поднял до 60 на ящик. Месяц всё работало.

28 октября он пришёл снова. Попросил 200 писем в час и спросил, насколько вообще можно поднять. Они собираются сделать вход по одноразовым кодам, и писем станет намного больше. Я снял ограничение совсем. Лимит нужен против спама, а коды тут запрашивают сами пользователи. В этой истории собраны почти все грабли почты с хостинга, так что расскажу по порядку.

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

Замков два:
• разрешение на отправку из скриптов, то есть PHP mail() и sendmail;
• лимит писем в час на каждый ящик-отправитель, и для SMTP, и для mail().
Поле с лимитом в панели клиенту не видно, хотя документация ispmanager уверяет, что оно в карточке ящика. Мой бот поддержки в сентябре на этом тоже споткнулся.

Отдельно про текст ошибки. Выглядит он так: Sender rate overlimit - 18.5 / 1h. 18.5 - это не лимит, а скорость отправки, которую намерил сервер. Дробная часть как раз и выдаёт. Клиент решил, что ему можно 18 в час, а можно было 5. На его месте я бы подумал так же. Отклонённые письма сами не уйдут. Человек нажмёт «отправить ещё раз», и это ещё одно письмо.

Хуже, что об отказе часто никто не узнаёт. При отправке через mail() отказ приходит письмом на адрес отправителя. Если это no-reply@, туда никто не смотрит. Если адрес внешний, отказ уходит со служебного адреса моего сервера.

Тут косяк мой. SPF-запись у этого адреса появилась только 4 октября. Gmail с тех пор такие уведомления принимает, Яндекс нет. Ему нужна DKIM-подпись, её я пока не сделал. Поэтому я советую слать с настоящего ящика на своём домене и заглядывать в него. А лучше по SMTP, тогда сайт узнает об отказе сразу.

Теперь про вход по коду. Здесь письмо уходит при каждом входе и каждом повторном запросе. Я бы считал пиковый час, а не сутки. Допустим, 1 000 входов в сутки. В среднем 42 в час, вроде и 60 хватит. Но если вечером за час приходит десятая часть, это уже 100 писем. Плюс повторы, регистрации, сбросы пароля и уведомления с того же ящика. Лимит у ящика один на всех.

И боты. Для них форма входа по коду - удобная цель. Каждый запрос - письмо, и бот за несколько минут съест весь лимит. Живые люди в этот час останутся без кода. Поэтому я бы сделал форме свой предел, ниже почтового:
• паузу перед повторной отправкой;
• несколько кодов на адрес в час, не больше;
• ограничение с одного IP и капчу, когда запросов подозрительно много;
• при входе код только на адрес, который есть в базе.
И сделал бы это до того, как просить лимит побольше. Снятый лимит хорош, пока сайт не взломали.

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

Полный разбор с ошибками, расчётом и защитой формы:
https://blog.siteko.net/articles/kody-podtverzhdeniya-ne-prihodyat-limit-otpravki-pisem

А у вас коды приходят по почте или уже по SMS? Считали, сколько их уходит в пиковый час?

Рассказываю, как я на днях нашёл у себя косяк на клиенте, которому нужна была одна A-запись. Человек купил у нас только домен, DNS-серверы оставил наши, а сайт держит на своём VPS. В поддержку он пришёл с короткой просьбой: помогите добавить A-запись. Домен при этом не открывался совсем. Браузер просто не находил сервер.

Причина оказалась банальной: у домена не было зоны. В реестре записаны ns1 и ns2.siteko.net, а они на запросы по домену отвечали REFUSED. Регистрация зону не создаёт. У нас она появлялась, только когда домен добавляли сайтом на хостинг, а хостинга у клиента нет. Google, Cloudflare и Яндекс отвечали SERVFAIL, то есть для интернета домена не было. Ни сайта, ни почты, ни подтверждения в Вебмастере.

Неприятнее другое: кабинет всё это время писал «DNS обновляется» и обещал письмо, когда обновится. Обновиться было нечему. Наша проверка спрашивала публичные резолверы и считала SERVFAIL признаком «ещё не распространилось». Через 48 часов она молча останавливалась, а статус оставался прежним. Когда я полез разбираться, нашёл 29 таких доменов, 25 из них старые. При этом каждый четвёртый заказ у нас только домен, 15 из 65. Так что случай далеко не редкий.

Зону клиенту я завёл руками через полчаса после обращения. Google, Cloudflare, Яндекс и Quad9 отдали адрес почти сразу. Остальное переделали в тот же день:
• проверка смотрит в реестр и на наши DNS-серверы, а не в кэш резолверов;
• вместо вечного «обновляется» статус «Не подключён» и кнопки, что делать дальше;
• на странице домена вкладка «DNS-записи», первая запись сама заводит зону;
• домен без зоны получает заглушку с HTTPS, а не мёртвый адрес.
Заглушку включили 28 октября в 17:24, и сразу припарковалось 27 доменов.

Проверить свой домен можно за минуту. Сначала я смотрю, какие DNS-серверы записаны в реестре: whois example.com. Потом спрашиваю один из них напрямую: dig @ns1.siteko.net example.com A. Если в ответе status: REFUSED, зоны нет и ждать бесполезно. Если NOERROR и нужный IP, с DNS всё в порядке. Дальше curl -I http://example.com покажет, отвечает ли сам сервер.

Кстати, у клиента на этом всё не кончилось. DNS заработал, а сайт нет. По http сервер молчал, по https отдавал ошибку сертификата. Это уже настройка самого VPS. Мне отсюда вывод простой: домен, DNS и сервер - три разных места, и проверять их надо по очереди. Иначе можно долго ждать «распространения» того, чего нет.

Ошибка у нас была глупая, но поучительная. Теперь такой домен хотя бы открывается.

Полный разбор с командами и тем, куда вписывать A-запись:
https://blog.siteko.net/articles/kupili-tolko-domen-kak-napravit-na-svoj-server

А вы проверяете DNS-серверы домена напрямую или ждёте, пока «обновится»?

Резервный сервер для интернет-магазина — полный разбор

Рассказываю, как на прошлой неделе у меня пропал сервер интернет-магазина, который мы ведём. 21 октября утром он перестал отвечать целиком. Ни сайт, ни SSH. Когда машина вернётся, никто сказать не мог. Я поднял копию магазина на другом своём сервере, около 11:20 сайт работал там. Минут через 25 основной сервер ожил, и я вернул домен на него. Новых заказов за это время не было, сводить ничего не пришлось.

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

Второй - у записи домена стоял TTL 3600. То есть даже с готовой копией сайта часть посетителей ещё час ходила бы на мёртвый адрес. Хотя про снижение TTL у нас в блоге целая глава. У себя вот проглядел.

После этого сделали магазину резервный сервер в другом дата-центре. Допустимый простой с заказчиком договорились считать 5-10 минут. Ночью я за это время не проснусь, так что переключаться сайт должен уметь сам. Отмечу, как всё устроено:
• база реплицируется на резерв через закрытый туннель, отставание в секундах;
• картинки, около 39 ГБ, раз в минуту уходят в облачное хранилище, резерв отдаёт их оттуда;
• код выкладывается на оба сервера одной командой, а фоновые задачи работают только на основном, иначе покупатель получит два одинаковых письма;
• переключение - одна команда на резерве. Он сам меняет адрес домена в DNS, TTL теперь 60.

Дольше всего я провозился с балансировщиком. Сначала перевёл домен на облачный балансировщик провайдера. На учениях сайт при переключении лежал 13 секунд. Задача вроде как решена. Со всех наших серверов балансировщик отвечал. А утром у заказчика сайт не открылся. Проверил через ping-admin.com: не достучались Москва, Томск, Рига, Копенгаген и Нидерланды. Вернул домен на сервер напрямую, переключение переделал на DNS. Поддержка провайдера за четыре дня причину не нашла. От услуги отказались.

Вывод для меня очевидный: проверять доступность надо из чужих сетей, а не со своих серверов. Мои серверы стоят в нормальных дата-центрах, и то, что они видят сайт, ничего не говорит о покупателе с домашним интернетом. Кстати, при удалении балансировщика не забудьте убрать доверие к его IP в nginx. Иначе новый владелец адреса сможет подставлять серверу «настоящий IP» посетителя.

Автоматическое переключение у меня пока в теневом режиме. Арбитр со свидетелями в других дата-центрах только пишет в журнал, что переключил бы. И уже нашёл случай, где в бою дал бы ложную тревогу: режим обслуживания во время выкладки. Включать буду, когда разберу все его сомнения. Так спокойнее.

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

А у вас есть резерв для сайта? И давно вы проверяли, что лежит в бэкапе?

PHP2Shell — полный разбор

Что проверить на своём сервере или VDS:

• обновить PHP до исправленной версии или поставить пакет дистрибутива, вышедший после 21 октября. На Debian и Ubuntu обычно хватает apt update && apt upgrade;
• перезапустить PHP-FPM или веб-сервер, иначе старый код останется в памяти процессов;
• найти остальной PHP на сервере: панель, веб-почта, phpMyAdmin, контейнеры, иногда внутри самого приложения;
• если обновиться сразу нельзя, выключить session.upload_progress.enabled в php.ini каждой версии;
• если сайт на PHP 8.1 или старше, планировать переход на новую ветку;
• проверить папки сайтов на незнакомые .php-файлы, особенно в uploads, images и cache.

Подробная хронология и технические детали — в полном разборе по ссылке в начале поста.

А вы уже обновились? И сколько мест с PHP у вас нашлось на сервере?

PHP2Shell: как мы закрывали уязвимости PHP

21 октября PHP выпустил исправления сразу для двух критических уязвимостей, CVE-2026-109618 и CVE-2026-109619. Исследователи назвали их PHP2Shell. Суть простая: отправляешь сайту специально собранный запрос и выполняешь свой код на сервере. Затронуты все версии, начиная с PHP 5.4 из 2012 года. Рассказываю, как мы закрывали это на хостинге и о чём при этом легко забыть.

Обе ошибки сидят в механизме прогресса загрузки файлов, session upload progress. Он включён по умолчанию, так что уязвима самая обычная установка. Оценка опасности 9.2 из 10. По данным Sansec, публичные эксплойты на стандартной установке пока не срабатывают, им нужна ещё ошибка в самом сайте или точно подобранная сборка PHP. Но код уже в открытом доступе. Ждать, пока его доработают, я бы не стал.

Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для 8.1 и старше официальных релизов не будет, ветки не поддерживаются. Патчи в исходниках выложили для 7.4, 8.0 и 8.1, а дальше всё зависит от того, кто вам собирает PHP. Временная мера, которую советовали все, кто разбирал уязвимость:

session.upload_progress.enabled = Off

Она закрывает основной путь атаки, но не единственный. Обновляться всё равно надо.

По срокам вышло так. 17 октября Amazon увидел первую попытку атаки. 21 октября в 10:43 Cloudflare сообщил о первых атаках, патча ещё не было. В 17:00 вышли исправления. 22 октября в 18:32 у нас были обновлены все версии PHP на сервере хостинга. А официальное уведомление пришло через дата-центр, когда всё уже было закрыто. Это не упрёк, рассылка идёт по цепочке. Но вывод я для себя сделал простой: если ждать письма, окажешься позади тех, кто читает новости по безопасности.

На хостинге у каждого сайта своя версия PHP, от 5.2 до 8.5. Старый сайт на 5.6 уязвим так же, как новый на 8.4. Нас выручил CloudLinux: разработчики перенесли исправление во все свои сборки, включая давно не поддерживаемые. Клиенты ничего не заметили, версия та же, перезагружать ничего не пришлось.

Тут есть нюанс, на котором легко запутаться. После обновления phpinfo() показывает, например, 8.4.26, хотя исправлено в 8.4.27. Так и задумано: патч вносят в ту же сборку без смены номера. То же самое делают Debian, Ubuntu и другие дистрибутивы. Так что сканер, который ругается на «PHP 8.4.26», ещё не повод паниковать. Но и успокаиваться по номеру версии нельзя. Проверять нужно по changelog пакета:

# rpm -q --changelog alt-php84-cli | grep 109618

Больше всего времени ушло на PHP, который живёт не в сайтах. Веб-почта крутится в своём контейнере со своей версией, её обновили отдельно 23 октября, с 8.3.15 на 8.3.36. У панели управления тоже свой PHP, через него работает Roundcube. Исправленной сборки от разработчиков панели на тот момент не было, поэтому закрыли временной мерой через session.upload_progress.enabled = Off. Выйдет обновление - поставим и уберём заплатку.

Ну и неприятная находка. Пока проверяли файлы, нашли веб-шеллы на трёх сайтах клиентов. К PHP2Shell они отношения не имели: появились раньше, в июле и 18 октября, через дыры в плагинах CMS. Сайты приостановили, владельцам написали. Вывод для меня очевидный: свежий PHP не лечит сайт, который взломали раньше.

Ниже — список проверок для своего сервера или VDS.

Получить 60 дней бесплатного хостинга

Подписчикам канала

🔧 Плановые работы и сбои

Здесь первым делом пишу о плановых работах и сбоях на хостинге и серверах Siteko.

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

🎁 Клиентам — 150 ₽ на баланс

Бонус за подписку начисляется один раз.

Как получить:
1. Подключите бота уведомлений в личном кабинете, в разделе «Настройки».
2. Нажмите «Проверить подписку» — в боте или на главной странице кабинета.

🚀 Новым клиентам — 60 дней вместо 30

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

Как выбрать чат-бота для сайта — полный разбор

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

Чат с живым оператором может всё: договориться о скидке, разобраться в нестандартной задаче. Как по мне, он хорош там, где вопросов мало, они сложные и каждый может стать крупной сделкой. Слабое место - время. Если вопрос пришёл в 22:40, чат превращается в форму обратной связи. А на «сколько доставка» человек отвечает по 20 раз в день.

Бот на сценариях - это кнопки и дерево шагов. Для записи на приём или статуса заказа по номеру он подходит хорошо и лишнего не скажет. Но на «а если у меня дача без электричества, ваш насос подойдёт?» он ответит «Выберите пункт меню».

ИИ-консультант - языковая модель, которой дали материалы сайта: страницы, каталог, условия. Посетитель пишет как хочет, бот отвечает своими словами. Слабое место - уверенный ответ не по делу. Поэтому я бы смотрел не на то, насколько умная нейросеть, а на ограничения. Отвечает ли он только по вашим материалам, что делает без ответа, откуда берёт цены и наличие.

Перед выбором я бы ответил себе на пять вопросов:
какая доля вопросов повторяется. Если 70 % про доставку, сроки и наличие, оператор тратит время впустую;
кто ответит вечером. У многих сайтов заметная часть трафика после 19:00 и в выходные;
сколько у вас товаров. 10 услуг закроют кнопки, 2000 товаров уже нет;
что важнее, ответ или контакт;
кто будет бота поддерживать.

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

Перед установкой задайте любому боту 10 проверочных вопросов. Вопрос, ответа на который нет нигде. Цена конкретного товара. Товар не в наличии и товар, которого у вас нет вообще. «Дайте скидку». «Хочу поговорить с человеком». И с опечатками: «скока стоит доставка до питера». Если бот хоть раз уверенно выдумал цену или условие, это не мелочь. На сайте такой ответ прочитают как обещание компании.

В полном разборе по ссылке выше — сравнение трёх видов, список того, что выяснить у сервиса, и все 10 вопросов.

А у вас на сайте что стоит: оператор, кнопки или уже ИИ?

Проверить скорость сайта

Сайт тормозит? Начните с проверки

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

Turbo от Siteko — бесплатно и без регистрации.

Вставьте адрес страницы, чтобы получить:
• замер скорости через Google PageSpeed Insights;
• рекомендации с учётом платформы сайта;
• список того, что можно исправить самому или поручить разработчику.

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

Хотите разобрать результат? Пришлите адрес страницы и описание проблемы через сайт Siteko.

#СкоростьСайта