Русский
Русский
English
Статистика
Реклама

Аудит сайта

SiteAnalyzer 2.2 бесплатный аудит сайта

16.09.2020 10:17:24 | Автор: admin

Всем привет! Представляю вашему вниманию новую версию программы SiteAnalyzer, предназначенную для технического аудита и SEO-анализа сайтов (бесплатный аналог Screaming Frog SEO Spider).


image


В новой версии SiteAnalyzer 2.2 мы постарались добавить несколько давно назревших функций, а также оптимизировать и сделать более удобными некоторые из уже существующих инструментов. Ниже расскажем обо всем поподробнее.


Основные изменения


1). Добавлен модуль настраиваемых фильтров для поиска контента на страницах сайта во время сканирования.


image


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


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


image


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


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


2). Добавлен график распределения внутренних ссылок на страницах сайта.


image


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


Слева отображено число страниц, справа число ссылок. Внизу процентные квантили по страницам. При составлении графика дубликаты ссылок отбрасываются (если со страницы А на страницу Б ведет 3 ссылки, то мы их считаем за одну).


Например, исходя из скриншота выше, для сайта из порядка 70 страниц:


  • 1% страниц имеют ~68 входящих ссылок.
  • 10% страниц имеют ~66 входящих ссылок.
  • 20% страниц имеют ~15 входящих ссылок.
  • 30% страниц имеют ~8 входящих ссылок.
  • 40% страниц имеют ~7 входящих ссылок.
  • 50% страниц имеют ~6 входящих ссылок.
  • 60% страниц имеют ~5 входящих ссылок.
  • 70% страниц имеют ~5 входящих ссылок.
  • 80% страниц имеют ~3 входящих ссылок.
  • 90% страниц имеют ~2 входящих ссылок.

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


На общей практике, страницы, имеющие менее 10 внутренних ссылок хуже краулятся поисковыми роботами, в частности, ботами Google.


Поэтому, если вы видите сайт, у которого нормально залинкованных всего 20-30% страниц от общего числа страниц на сайте, то имеет смысл углубиться в настройку перелинковки либо подумать, как поступить с этими 80-70% слабо залинкованных страниц (удалить, скрыть от индексации, поставить редиректы).


Пример слабо залинкованного сайта:


image


Пример хорошо залинкованного сайта:


image


Более подробно с описанием работы графика распределения внутренних ссылок можно ознакомиться в разделе Документация.


3). Оптимизирована работа с графом визуализации.


image


  • При перетаскивании узлов графа добавлен пропорциональный перенос дочерних элементов.

image


  • При выборе узла на графе, входящие и исходящие ссылки стали окрашиваться разными цветами для большей наглядности.
  • Добавлена интерактивность в блок легенды графа визуализации: при клике на элементы легенды, на графе выделяются соответствующие узлы.

image


4). Добавлен учет заголовка "X-Robots Tag" при сканировании сайтов.


image


Появилась возможность отключать либо включать учет параметра "X-Robots Tag" в настройках программы при сканировании сайта, так как ранее он лишь отображался в статистике.


Примечание: заголовок X-Robots-Tag входит в HTTP-ответ для определенного URL. В заголовках X-Robots-Tag поддерживаются те же директивы, что и в мета-тегах robots. Любая директива, которая может использоваться в мета-теге robots, может быть указана в X-Robots-Tag.


Прочие изменения


  • Оптимизирован парсинг заголовков H1-H6, использующих классы.
  • Устранено зависание программы в конце сканирования на больших проектах.
  • В разделе дубликатов Description исправлено некорректное отображение статистики.
  • Исправлено некорректное отображение статистики страниц с кодом ответа 404.
  • Для страниц, заблокированных в Robots.txt, теперь отдается код ответа 600.
  • Параметр "Время отклика" стал рассчитываться более корректно.
  • Исправлена не всегда корректная верстка карты сайта Sitemap.xml.
  • Редиректы стали отображаться более корректно.
  • Сортировка по URL стала более логичной.

ПС. Буду рад любым замечаниям и предложениям по улучшению функционала программы.

Подробнее..

SiteAnalyzer 2.3 Динамика загрузки страниц

19.10.2020 10:13:52 | Автор: admin

Всем привет! Продолжаем выкладывать обзоры новых версий программы SiteAnalyzer, предназначенной для технического аудита и SEO-анализа сайтов. В новой версии SiteAnalyzer мы продолжили курс по планомерному развитию программы, в результате чего добавили несколько нововведений и исправили пару багов. Расскажем обо всем поподробнее.


SiteAnalyzer 2.3


Основные изменения


1. Добавлен график, отображающий динамику загрузки страниц.


Динамика скорости загрузки страниц

В раздел меню "Визуализация" добавлен новый пункт "График скорости загрузки страниц", позволяющий оценить быстродействие сайта. Для наглядности, страницы распределены по группам и временным интервалам с шагом в 100 миллисекунд.


Таким образом, исходя из графика можно определить, какая доля страниц сайта грузится быстро (в пределах 0-100 миллисекунд), какая со средней скоростью (100-200 миллисекунд) и какие страницы загружаются достаточно долго (400 миллисекунд и более).


Примечание: указанное время является временем загрузки исходного кода HTML, а не временем полной загрузки страниц (рендеринг страницы, а также подгрузка элементов страницы, таких как, например, изображения и стили, не учитывается).


2. Добавлена вкладка "Контент", отображающая статистику распределения контента по числу знаков и слов на странице.



Новая вкладка Контент

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


3. На вкладке Custom Filters добавлен новый узел "Ссылки", содержащий статистику по страницам с большим числом исходящих ссылок и малым числом входящих.


Новый узел Ссылки

За счет данных фильтров станет удобнее анализировать страницы с большим числом исходящих ссылок (>100) и малым числом входящих (<5).


Дополнительно к этому, график распределения ссылок стал интерактивным и теперь он связан с отчетом "Мало входящих" раздела Custom Filters: при клике на график стало возможным перейти на список страниц, содержащих малое число внутренних ссылок.


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


3. Добавлена возможность генерации Sitemap для изображений.


Генерация Sitemap для изображений

Добавили по многочисленным просьбам пользователей ;)


Прочие изменения


  • Исправлено аварийное завершение программы при сканировании сайтов со "сложными" редиректами.
  • В пустой программе (без проектов) исправлена реакция кнопки Старт на изменения в поле URL.
  • Исправлено не всегда корректное отображение подзаголовков H1-H6.


Буду рад любым замечаниям и предложениям по улучшению функционала программы.

Подробнее..

Recovery mode Как ускорить сайт в 4 раза, просто перенастроив сервер

02.06.2021 12:04:43 | Автор: admin

Если вы работаете с сайтом, который постепенно растет, - увеличивается количество товаров, трафик с рекламы - то рано или поздно придется перейти в режим работы highload, высоких нагрузок на сервер. Но что делать, если ваш сайт не растет, а сервер все чаще не выдерживает, и происходит блокировка данных? Именно с этой проблемой мы столкнулись, дорабатывая сайт для интернет-магазина светового оборудования с ассортиментом более чем 100 000 товаров.

Исходная ситуация

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

Поиск проблемы

Мы провели аудит настроек сервера и сайта, разделив работы на два этапа: анализ back-end и front-end, и обнаружили низкую скорость загрузки страниц на back-ende - порядка 80 секунд на самых посещаемых страницах, что в итоге приводило к существенному снижению конверсии.

Мы выяснили, что основная проблема заключалась в неправильно настроенном кэше и настройке базы данных.

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

Решение

Шаг 1. Настройка баз данных

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

Шаг 2. Смена типа хранения на InnoDB

Почему мы выбрали InnoDB?

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

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

Также была произведена оптимизация работы самой базы данных InnoDB. Например, были оптимизированы параметры:

# InnoDB parameters

innodb_file_per_table

innodb_flush_log_at_trx_commit

innodb_flush_method

innodb_buffer_pool_size

innodb_log_file_size

innodb_buffer_pool_instances

innodb_file_format

innodb_locks_unsafe_for_binlog

innodb_autoinc_lock_mode

transaction-isolation

innodb-data-file-path

innodb_log_buffer_size

innodb_io_capacity

innodb_io_capacity_max

innodb_checksum_algorithm

innodb_read_io_threads

innodb_write_io_threads

Промежуточные результаты

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

Это в свою очередь привело к уменьшению потребляемой оперативной памяти.

Шаг 3. Перенастройка Nginx и установка модулей кэширования brotli, pagespeed, proxy_buffering

Nginx позиционируется как простой, быстрый и надежный сервер, неперегруженный функциями. Уже длительное время Nginx обслуживает серверы многих высоконагруженных российских сайтов, например, Яндекс, Mail.Ru, ВКонтакте и Рамблер. Для улучшения производительности при использовании дополнительных серверов, Nginx поддерживает буферизацию (proxy_buffering) и кеширование (proxy_cache), чем мы и воспользовались.

Не обошлось и без курьезов настроек Nginx. У клиента был обычный интернет-магазин с товарами, тогда как настройки буферизации, которые мы обнаружили во время аудита, позволяли ему быть чуть ли ни стриминговым сервисом. Мы существенно уменьшили значения в параметре client_max_body_size, что в совокупности с перенастройкой Nginx еще больше снизило потребление памяти.

Шаг 4. Оптимизация настроек PHP-FPM и Memcache и отключение Apache

PHP-FPM нередко используется в паре с веб-сервером Nginx. Последний обрабатывает статические данные, а обработку скриптов отдает PHP-FPM. Такая реализация работает быстрее, чем распространенная модель Nginx + Apache.

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

Необходимым шагом стал перевод работы PHP-FPM на unix socket. Зачем это понадобилось? Nginx сам по себе довольно быстрый веб-сервер, однако самостоятельно он не может обрабатывать скрипты. Для этого необходим бэкенд в виде PHP-FPM. Чтобы вся эта связка работала без потери скорости, мы использовали unix socket способ подключения к PHP-FPM, позволяющий избегать сетевые запросы и дающий значительный прирост в скорости работы сайта.

Результаты работ

1. Время отклика главной страницы уменьшилось с 24 секунд до чуть более 3 секунд, внутренних до 5-8 сек.

2. Уменьшилось потребление серверных ресурсов.

3. Стабилизировалось поведение сервера - он перестал зависать.

4. Глубина просмотров увеличилась на 30%, и как следствие, это дало улучшение в SЕО, а также последующих продаж: растут поведенческие показатели => растут позиции сайта в выдаче => растет трафик => растут продажи.

5. Клиенту были даны рекомендации по оптимизации front-end части сайта для ускорения работы сайта. Например:

  • оптимизировать графики и настройку выдачи изображений в формате webp;

  • настроить lazyload-загрузки данных;

  • вынести все некритические для отображения страницы скрипты в конец страницы.

Вывод

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru