Явное непонимание, как работают парсеры подобного рода (что NetPeak, что Screaming Frog, что Xenu).
99% времени уходит на выкачивание страниц и выбор ссылок с этих страниц для остроение очереди далее скачиваемых страниц - вот тут есть потери времени, т.к. логично делается проверка на уникальные адреса в очереди, чтобы по 10 раз один и тот же URL не скачивать - эти процессы на больших объемах затратны.
Все остальное извлекаемое - все те параметры, на обработке которых Вы думаете "съэкономить" - это статистически незначимые затраты времени.
Так что вопрос в принципе бессмысленный. Будучи выкаченной на компьютер, страница парсится почти моментально.
SeVlad: Глупость какая и сам вопрос и апать давно мертвый топик в котором уже всё обсудили.
Но у некоторых же некрофилия, а другие не смотрят на даты и не читают топики дальше заголовков.
Апплодисменты, самореализовался. Дальше первых строк поста не осилил? Да, дату не посмотрел. Но по сути написал. А Вы?
Глупость какая. Сайдбар визуально и сайдбар в коде могут располагаться относительно контента совершенно по разному.
Уже техник управления потоком документа существует вагон. И через флоаты, и через отрицательные марджины, и флексбоксом и еще...
А значит на десктопе сайдбар слева, в коде - после контента, на мобиле со своей стилевой таблицей - после контента...
Ну вот откуда такие вопросы... ну хоть немного учите вебтехнологии, а не просто тупо качайте шаблоны... нельзя юзать отвертку, не зная, зачем она...
---------- Добавлено 26.01.2019 в 12:20 ----------
По вопросу ТС
Думается, для инфосайтов сб должен быть условно под рабочую руку пользователя (правше - справа), без учета право-левостороннести письма (арабам и арамеям - все зеркально).
Потому что проще в голове, при поиске инфо навигация должна быть «под рукой»
При инструментальном интерфейсе сервиса, фильтры в каталогах - как минимум для правши слева, потому что тут работает паттерн операционной системы, что в Винде, что в Макос навигационный сайдбар традиционно слева.
SeVlad: а вот трёхметровую фоточку вполне можно (нужно!) ужать до 50-100 кб без заметной на глаз потери кач-ва.
При этом еще изменив ее размеры с 5000 на 5000 пикселей до приемлемых на экране десктопа ~1920 на 1920 максимум (а для теста пейджспида вообще до 1300 по моему) и до мобильных ~400 на 400
Ок, для ретины - все размеры в 2 раза больше (но через srcset и Гуглу не показывать)
Протестите на aseo.tech - увидите, что можно добиться руками или автоматикой.
pr-cy.ru
similarweb.com
semrush.com
serpstat.ru
Бесплатный анализ - можно попробовать посмотреть
Для подбора в бурже
есть https://ubersuggest.io
достаточно вменяемый
есть https://keywordtool.io/
тоже полезен
Русские кеи там подбирать не пробовал и смысла не вижу. Вордстата с Буквариксом вполне достаточно, через Кейколлектор опять же.
Собрать, сделать тестовую кампанию в Google Ads, покрутить неделю, посмотреть показы, выбросить шлак.
Явное непонимание, как работают парсеры подобного рода (что NetPeak, что Screaming Frog, что Xenu).
99% времени уходит на выкачивание страниц и выбор ссылок с этих страниц для остроение очереди далее скачиваемых страниц - вот тут есть потери времени, т.к. логично делается проверка на уникальные адреса в очереди, чтобы по 10 раз один и тот же URL не скачивать - эти процессы на больших объемах затратны.
Все остальное извлекаемое - все те параметры, на обработке которых Вы думаете "съэкономить" - это статистически незначимые затраты времени.
Так что вопрос в принципе бессмысленный. Будучи выкаченной на компьютер, страница парсится почти моментально.
Это не боты. Это поиск по картинкам, в котором при уточняющих кликах к запросу автоматом плюсуется альт-текст, и эти запросы попадают в статистику.
Недавно общал саппорт Директа, сознались, сказали, что разработчики уже работают над переделкой схемы уточняющего поиска.
Глупость какая и сам вопрос и апать давно мертвый топик в котором уже всё обсудили.
Но у некоторых же некрофилия, а другие не смотрят на даты и не читают топики дальше заголовков.
Апплодисменты, самореализовался. Дальше первых строк поста не осилил? Да, дату не посмотрел. Но по сути написал. А Вы?
Глупость какая. Сайдбар визуально и сайдбар в коде могут располагаться относительно контента совершенно по разному.
Уже техник управления потоком документа существует вагон. И через флоаты, и через отрицательные марджины, и флексбоксом и еще...
А значит на десктопе сайдбар слева, в коде - после контента, на мобиле со своей стилевой таблицей - после контента...
Ну вот откуда такие вопросы... ну хоть немного учите вебтехнологии, а не просто тупо качайте шаблоны... нельзя юзать отвертку, не зная, зачем она...
---------- Добавлено 26.01.2019 в 12:20 ----------
По вопросу ТС
Думается, для инфосайтов сб должен быть условно под рабочую руку пользователя (правше - справа), без учета право-левостороннести письма (арабам и арамеям - все зеркально).
Потому что проще в голове, при поиске инфо навигация должна быть «под рукой»
При инструментальном интерфейсе сервиса, фильтры в каталогах - как минимум для правши слева, потому что тут работает паттерн операционной системы, что в Винде, что в Макос навигационный сайдбар традиционно слева.
Ranksense.com
keywordtool.io
Ubersuggest.io
а вот трёхметровую фоточку вполне можно (нужно!) ужать до 50-100 кб без заметной на глаз потери кач-ва.
При этом еще изменив ее размеры с 5000 на 5000 пикселей до приемлемых на экране десктопа ~1920 на 1920 максимум (а для теста пейджспида вообще до 1300 по моему) и до мобильных ~400 на 400
Ок, для ретины - все размеры в 2 раза больше (но через srcset и Гуглу не показывать)