dollar

function enoughTime() { // Возвращает true, если прошло больше 2 секунд
  let now = (new Date()).getTime();
  if (!enoughTime.save) enoughTime.save = now/2;
  if (now - enoughTime.save < 2000) return false;
  enoughTime.save = now;
  return true;
}

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

Такой и есть: a.pr-cy.ru

Причина может быть, в чём угодно. Но даже если вы её выясните, и эта информация решит вашу проблему, то, скорее всего, решение будет временным. Ведь Инстаграмм заинтересован в том, чтобы филтровать ботов, а значит:
а) им не выгодно раскрывать карты и объяснять, как они вычисляют ботов.
б) механизм отсева постоянно будет совершенствоваться.

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

Навскидку могу назвать способ детекта ботов, который бы я сделал, если бы меня эта тема волновала - это отслеживание движений мыши. Ведь User Agent и ip давно не показатель. Но мышь - это только начало. Даже обфусцированный скрипт хакер при желании расковыряет. Так что я бы не только проверял движения мыши на наличие, а записывал бы траекторию движения и отправлял на сервер, а там уже хитрый алгоритм анализировал бы форму движений и выдавал своё экспертное заключение. Дальше война (пули и брони) развернулась бы в плоскости психологии кисти руки, если её можно так назвать. Это касается десктопов. В мобайле, соответственно, - координаты тапов, характер скролла, тайминги между действиями и всякое такое. Конечно, это всё не в ущерб юзер экспириенсу. А так можно просто капчу выводить при малейшем подозрении.

По сути ваш вопрос касается только одной темы - маркетинга.

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

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

Так что однозначных рецептов дать нельзя. Смотреть нужно в сторону маркетинга и просто здравого смысла. Например, A/B тестирование - это технология именно маркетинга, а не дизайна или программирования (и порой она даёт очень необычные результаты).

Вспоминая прошлое, могу сказать, что в начале 2000х была мода делать всякие свисто-перделки на своих сайтах, всякие анимации, выезжающие меню, выпрыгивающих персонажей, падающий снег и т.д. Авторы таких творений почему-то думали, что это безумно круто и должно нравиться всем. По факту это нравилось только авторам этих поделок. Большинству же важно наполнение сайта контентом, удобство восприятия контента. А всякие типа вау-эффекты на самом деле только отвлекают и на них вырабатывается аналог рекламной слепоты (но не у всех, некоторых просто бесит). Так что если лендинг посвящен, скажем, пылесосам, то сделайте ознакомление удобным - например, обзор продукта в 3D. Это будет лучший вау-эффект в данной конкретной тематике.

Были времена, когда процессоры без охлаждения сначала нагревались, потом дымились, но продолжали работать до тех пор, пока не сгорят. Но это было очень-очень давно. В наши дни практически все системы снабжены защитой от этого, так что можете не переживать и делать любые стресс-тесты. Изнашиваются, в первую очередь, вентиляторы системы охлаждения, но 3-4 часа погоды точно не сделают.

А вы откройте свойства папки и посмотрите.

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


P.S. Странно, что вас при этом не интересует износ диска и все хитрости под капотом с этим связанные.

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

Ещё есть тонкость, что на NTFS дисках минимум 12% места желательно держать свободными, это тоже влияет на скорость. А в случае SSD лучше ещё больше места оставлять незанятым.

Я делаю все вопросы в отдельной структуре.

А на экране показываю одновременно только один вопрос и кнопку "Дальше". То есть DOM формируется динамически. Причем, при показе вопроса варианты ответов перемешиваются (кроме вариантов "ничего из вышеперечисленного" и "всё вышеперечисленное", которые добавляются в конец).

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

К слову, тест знаний делать на js - так себе идея. Ведь шпаргалка открывается в два клика (или комбинацией Ctrl+U) и читается без навыков программирования. По уму вопросы и ответы должны перемешиваться на сервере, id ответов должны быть каждый раз произвольные типа fGx9PeL7, подсказки ответа в js коде не должно быть вообще (проверка ответа только на сервере), вопросы должны отдаваться не все сразу, а порциями через ajax, ну и на каждый вопрос должно отводиться ограниченное время. А если лимита времени нет, то придется физически стоять над душой респондента и смотреть, чтобы он не лез в Гугл за подсказками. Ведь тест знаний должен проверять знания в предметной области, а не хакерские способности или скорость гугления.

Тогда что-то вроде этого. Без названия. Просто кабель 8-пин.
Там на оф. сайте ещё есть варианты.

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

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