Технический прогресс опережает социальный. Если посмотреть внимательно, то примерно лет на 100. Итогом 21 века станет большой скачок именно в социальном и интеллектуальном плане. И сегодняшние дни наши потомки будут воспринимать с теми же эмоциями, с какими мы воспринимаем средневековье.
Если не претворится в жизнь один из других равновероятных сценариев, основа которых опять же в дисбалансе социального и технического развития…
Предложение оптимизировать доставку единственного на весь сайт CSS-файла, 3.5 КБ в сжатом виде, выглядит странно.
Разбивать ассет и встраивать стили в документ, во-первых, глупо, потому как раздувается объем html (а на соседних страницах вы же сами даете советы по сокращению объема кода html), а во-вторых, статика — это как раз тот случай, когда яйца лучше хранить в одной корзине, особенно когда их немного.
Опять же, вы сами пишете: «если файл CSS слишком велик, после его встраивания PageSpeed Insights может вас предупредить, что верхняя часть страницы имеет слишком большой объем». В случае, например, с главной страницей Яндекса «42,8 КБ ответа необходимо для отображения верхней части страницы», но это убивает меньше попугаев, чем 10КБ внешнего css-файла.
Вопрос: учитывает ли ваш инструмент при оценке скорости события load и DOMContentLoaded? Я не нашел упоминания.
В целом инструмент хорош, но как и всегда, лучше использовать его вместе с другими подобнымиинструментами.
Теперь осталось решить задачу с профилями. Вроде есть id.tmtm.ru, а точка входа в каждый из ваших проектов разная. Сплошной копипастинг и надругание над DRY с точки зрения пользователя.
Если расширить понятие «товар» и рассматривать еще и услуги, то анализ целевой аудитории, методов продвижения товаров и услуг, а также потребительских свойств самих товаров и услуг приведет нас к некоему «рецепту» хорошей продажи, который больше всего похож на список смертных грехов, причем список этот хоть и варьируется от конфессии к конфессии, суть его одна для всех людей.
Единственное важное замечание — к этому списку я бы добавил еще 2: страх и глупость. Хотя глупость — скорее производная страха и лени.
Многие вещи, которые вы вокруг себя видите — это пирожки из одних и тех же ингридиентов, смешанных в разных пропорциях, направленные на удовлетворение ваших слабостей. Вся прелесть в том, что те, кто эти пирожки лепит, тоже имеют слабости и также удовлетворяют их такими же, в сущности, пирожками. Получается замкнутый круг.
А еще один мудрый дядя как-то сказал: «И что ты смотришь на сучок в глазе брата твоего, а бревна в твоем глазе не чувствуешь?»
между прочим, интересное дело.
Компания, которая занимается обучением в сфере веб-технологий, для аватарок 60х60 использует полноразмерные фотки и вообще не блещет.
Или я всё проспал и клиентская оптимизация сегодня никому не нужна?!
прошу прощения, не понял предыдущего оратора…
Вообще, чтобы понять, что происходит в этих странных сложениях и почему получаются такие результаты, нужно знать несколько моментов.
Первый: в js можно складывать только числа и строки. При сложении других типов данных происходит попытка конвертировать переменные или в число, или в строку.
Таким образом, сумма двух массивов — это конкатенация двух пустых строк, и это логично:
Третье и четвертое сложения вводят в заблуждение. Казалось бы, от перемены мест слагаемых сумма не меняется, и мы пытаемся снова сложить объект с массивом, но интерпретатор js воспринимает первую пару фигурных скобок, как Code Block, и игнорирует его.
Остается +[]. Плюс в данном случае является унарным оператором и ведет себя эквивалентно Number([]).
Как ниже описал cyberface, получается, что 3-е и 4-е сложения эквивалентны соответственно:
Если не претворится в жизнь один из других равновероятных сценариев, основа которых опять же в дисбалансе социального и технического развития…
Разбивать ассет и встраивать стили в документ, во-первых, глупо, потому как раздувается объем html (а на соседних страницах вы же сами даете советы по сокращению объема кода html), а во-вторых, статика — это как раз тот случай, когда яйца лучше хранить в одной корзине, особенно когда их немного.
Опять же, вы сами пишете: «если файл CSS слишком велик, после его встраивания PageSpeed Insights может вас предупредить, что верхняя часть страницы имеет слишком большой объем». В случае, например, с главной страницей Яндекса «42,8 КБ ответа необходимо для отображения верхней части страницы», но это убивает меньше попугаев, чем 10КБ внешнего css-файла.
Вопрос: учитывает ли ваш инструмент при оценке скорости события load и DOMContentLoaded? Я не нашел упоминания.
В целом инструмент хорош, но как и всегда, лучше использовать его вместе с другими подобными инструментами.
Вкратце, используется алгоритм минимакс с альфа-бета отсечением.
Исходный код — github.com/ov3y/2048-AI
Подробное объяснение работы от автора — stackoverflow.com/a/22389702/1056032
Единственное важное замечание — к этому списку я бы добавил еще 2: страх и глупость. Хотя глупость — скорее производная страха и лени.
Многие вещи, которые вы вокруг себя видите — это пирожки из одних и тех же ингридиентов, смешанных в разных пропорциях, направленные на удовлетворение ваших слабостей. Вся прелесть в том, что те, кто эти пирожки лепит, тоже имеют слабости и также удовлетворяют их такими же, в сущности, пирожками. Получается замкнутый круг.
А еще один мудрый дядя как-то сказал: «И что ты смотришь на сучок в глазе брата твоего, а бревна в твоем глазе не чувствуешь?»
Компания, которая занимается обучением в сфере веб-технологий, для аватарок 60х60 использует полноразмерные фотки и вообще не блещет.
Или я всё проспал и клиентская оптимизация сегодня никому не нужна?!
Вообще, чтобы понять, что происходит в этих странных сложениях и почему получаются такие результаты, нужно знать несколько моментов.
Первый: в js можно складывать только числа и строки. При сложении других типов данных происходит попытка конвертировать переменные или в число, или в строку.
Таким образом, сумма двух массивов — это конкатенация двух пустых строк, и это логично:
Второе сложение действует аналогичным образом:
Третье и четвертое сложения вводят в заблуждение. Казалось бы, от перемены мест слагаемых сумма не меняется, и мы пытаемся снова сложить объект с массивом, но интерпретатор js воспринимает первую пару фигурных скобок, как Code Block, и игнорирует его.
Остается
+[]. Плюс в данном случае является унарным оператором и ведет себя эквивалентноNumber([]).Как ниже описал cyberface, получается, что 3-е и 4-е сложения эквивалентны соответственно:
и