• Работа распределённой команды в условиях самоизоляции: как мы почти не заметили разницы
    +1

    Тут есть несколько моментов. Возможно, каждому дома удобно, но вот всей команде вместе может быть не так удобно от того, что все дома, и работа замедляется. Есть люди, которые действительно страдают без офиса. Да, среди работников IT есть экстраверты.


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


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

  • Системный подход к скорости: онлайн-измерения на фронтенде
    +1

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


    Для критерия Манна-Уитни используем функцию mannwhitneyu из scipy, никак её не кастомизируем.

  • Системный подход к скорости: онлайн-измерения на фронтенде
    +1

    Спасибо!


    По поводу шрифтов – интересный вопрос. Могу сказать, что first contentful paint точно не ожидает появления шрифта и считается временем, когда отрисовалось что-либо кроме белой страницы или цвета фона.


    А вот по поводу наших приближений TTFMP – скажу честно, пока не проверяли.

  • Сохранение JS и CSS ресурсов в Локальном хранилище браузера
    0

    К сожалению не так всё хорошо ) Процент медленных запросов на мобильных сетях не превосходит 10%, но достаточно близок. Это примерно и есть доля Бабули.


    Учитывая наш опыт, я бы всё-таки рекомендовал попробовать вместо кэширования в LS сжатие в brotli и вечное кэширование в HTTP-кэше для преодоления проблем сети:


    Cache-Control: max-age=315360000, public, immutable

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


    Статистику о типе навигации можно собрать через Navigation Timing API, свойство performance.navigation.type.

  • Сохранение JS и CSS ресурсов в Локальном хранилище браузера
    +3

    Мы в Поиске Яндекса тоже когда-то давно догадались до оптимизации путём складывания статики в LocalStorage.


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


    Так вот, внедрили кэширование в LS, увидели драматическое уменьшение размера HTML, не смогли увидеть ухудшение в DevTools – обрадовались и стали использовать.


    Шли годы, скорость обрастала аналитикой и прочим А/Б тестированием, и в голову пришла идея перепроверить – примерно на двухтысячном тикете про баги в фиче, где не оттестировали сценарий, когда статика берётся из кэша. Дело близилось к середине 2017, на тот момент мы уже умели получать со всей аудитории скоростной фидбек в виде метрик. У нас были:


    • все стандартные метрики Navigation Timing API
    • время отрисовки шапки (страница отдаётся чанками, и шапка приходит сильно раньше выдачи)
    • начало парсинга выдачи
    • окончание инициализации клиентского фреймворка
    • разработанные другими командами метрики поведения пользователя на странице

    Провели А/Б эксперимент и увидели:


    • +12% времени скачивания HTML – логично, мы же начали передавать по сети то, что раньше не передавали;
    • -3% времени до отрисовки шапки – уже не так логично – мы же оптимизацию отключаем;
    • -1% времи до начала парсинга выдачи, и примерно на столько же – времени до инициализации клиентского фреймворка;
    • уменьшилось время до первого клика по выдаче, что косвенно говорит о том, что выдача раньше отрисовывается и становится доступной пользователю для взаимодействия; позже у нас появились более конкретные метрики на эту тему, но тогда не было.

    После этого кэширование в LS благополучно отключили, а после удаления машинерии по управлению этим кэшированием и множества noscript на случай отключенного JS, увидели на потоке ещё большее ускорение.


    И про ServiceWorker мне есть что рассказать. Как-то раз мы решили его попробовать, и начать не сразу с места в карьер, а с умом и пошагово – сперва снять показания с самой лёгкой вариации. Добавили sw.js, который ничего не умел, кроме как устанавливаться и навешивать пустой обработчик на событие fetch.


    И снова поймали замедление. Сотни миллисекунд по всем метрикам, начиная со времени до первого байта. Так что для кэширования я бы рекомендовал SW только после серьёзного исследования – иначе есть риск сделать всё не правильно, а совсем наоборот. Если попадание в HTTP-кэш хорошее (у нас 80–90%) – будет точно медленнее.


    Если это SPA, где не так важны сотни миллисекунд загрузки оболочки, зато важен оффлайн – вопрос совершенно обратный, тут оно стоит того и используется именно для того, для чего задумывалось.


    В итоге сейчас мы пришли к следующей схеме:


    • весь CSS инлайновый – так быстрее рисуется; даже если стили в дисковом кэше – так быстрее; даже не пытаемся кэшировать это в браузерных хранилищах – всё равно так останется быстрее;
    • jQuery (да, у нас всё ещё jQuery) и бандл с фреймворком i-bem и общими сущностями загружаются внешними скриптами – с хитрыми префетчами для прокачки кэша;
    • скрипты асинхронны (defer) и расположены в первом чанке HTTP-ответа для WebKit, в остальных – синхронные с предзагрузкой с помощью link[rel=preload] из первого чанка (отключено для FF – там пока баги с preload); это связано с разными нюансами работы разных движков с синхронными и асинхронными скриптами;
    • вычисляем медленные запросы и отправляем на лёгкую версию – там в плане схемы со статикой всё то же самое, но функциональность сильно беднее, и вёрстка сильно хитрее свёрстана – всё с целью уменьшения размера; про это даже есть отдельный пост.

    Можно заметить, что это сильно отличается от рекомендуемого в постах "Как по-быстрому оптимизировать фронденд". И так же как рекомендации из этих постов строго не рекомендуется к применению бездумно.


    Есть, конечно, очевидные вещи, которые можно внедрять не размышляя: вечное кэширование всего, что можно, gzip/brotli для сжатия, скрипты не должны блокировать отрисовку, не нужно сушить кошку в микроволновке. Но в остальном – нужно измерять скорость на реальных пользователях своего сервиса, считать статистику и полагаться на эксперименты. Сервисы разные, пользователи разные – оптимизации подходят разные.

  • Сохранение JS и CSS ресурсов в Локальном хранилище браузера
    +1

    Там почему-то неправильные данные. Указано, что Chrome не поддерживает, но это не так. Можно убедиться на практике – попробовать отдать этот заголовок на каком-то ресурсе и попробовать нажать Ctrl+R – если он в кэше, и кэш ещё валиден – ресурс не будет скачан.

  • Сохранение JS и CSS ресурсов в Локальном хранилище браузера
    +1

    Уже вполне неплохая. Chromium поддерживает, так же как и Safari. Так что уже можно – мы пользуемся, например

  • Runtyper — инструмент для проверки типов при выполнении JavaScript кода
    +1

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

  • Бывший разработчик Firefox: удалите сторонние антивирусы
    +1
    Не стоило бы айтишнику судить о происходящем у простых пользователей по своему окружению :)
  • Вышел ReactOS 0.4.3 под кодовым именем «Haters gonna hate»
    0

    Никак не проверяете, что вирусов действительно нет?

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0

    {extends: 'eslint:recommended'} =)

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0
    А почему mobx?
  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0
    Скорее это идеология npm – если это есть в репозитории – не пиши заново. Все модули маленькие и выполняют единственную задачу. В какой-то мере опасно, но удобно и быстро.

    В тёплые LAMP'овые времена в проектах не было такого количества мелких зависимостей – всё писалось самостоятельно.
  • Тонкости благополучного git-merge
    0
    Отвечает ggray:
    мне кажется что рекурсивная стратегия никак не связана с решениме конфликтов при ребейзе, а автору я бы посоветововал включить rerere если у него часто такие кейсы возникают :)
  • Вернется ли Павел Дуров в Россию и каким его видят западные СМИ
    0
    Ну не просто же так он был упомянут. Вряд ли на IT-ресурсе напишут «Иосиф Кобзон не считает Telegram безопасным. Зачем мы это написали? Да так просто». Если человек упоминается в контексте, значит, его мнение считается значимым для темы.
  • БЭМ — методология развешивания костылей
    +2
    Знаете, что я скажу вам, господа? Мир фронтенда — бегун на костылях в принципе, но бегун быстрый. У нас особая ситуация — наши программы выполняются в браузерах, возможности которых ограничены, конкретные браузеры выпускаются разными, никак не связанными командами, а версии обновляются неравномерно.

    HTML изначально был предназначен для статей, связанных гиперссылками, но разработчики и пользователи захотели красивых страничек, и начали использовать таблицы для позиционирования и всякие атрибуты для украшательств. Это костыль или чистейший гений архитектуры? Конечно, костыль — таблица же для данных, а не для верстки страниц.

    Версии обновляются медленно, а мы хотим новых возможностей JS или писать для браузера на совершенно другом языке. Появляются полифиллы, транспайлеры и компиляторы в JS. Так что же, разве не костылями являются Babel или TypeScript? Да конечно костылями — это же надо, компилировать высокоуровневый язык в JavaScript! А кое-кто ведь и низкоуровневые компилирует! Это вынужденная мера, но путем таких костылей мы получаем огромные возможности.

    Так же, поскольку у нас нет иного выбора, кроме CSS, а возможности его ограничены, приходится на этих ограниченных возможностях строить методологии, которые оградят разработчиков от стрельбы по ногам и облегчают масштабируемость и поддерживаемость кода. Отсюда и появились БЭМ и другие его братья. Да, они ограничивают некоторые возможности CSS и привносят некоторые правила, которые можно назвать костылями с точки зрения академической архитектуры. К примеру, селекторы в БЭМ — классический пример борьбы с коллизиями при использовании глобальных переменных. Но это не от хорошей жизни — в современном CSS нет других возможностей создавать пространства имен.

    Но что делать, отказаться от любых хаков, лишь бы не вылезать из калеи, в которую нас загоняют веб-технологии в чистом виде? Конечно нет, если бы мы так делали — веб не пришел бы туда, куда пришел.

    Веб — богатейшая почва для набросов, можно сорвать покровы с любой актуальной технологии и методологии и потешить тем самым самолюбие, но стоит ли этим заниматься? Может быть, лучше было бы разработать достойную альтернативу или пойти и заняться улучшением какой-нибудь из текущих? Может быть, оно само по себе и не взлетит и не станет лучше, но свежая идея — тоже очень важная в мире веба штука.
  • DevTips: Советы веб-разработчику (17-32)
    0
    На Маке Ctrl+L так же работает. Это классический шорткат из терминалов. Про Cmd+K я даже и не знал :)
  • Тестирование в Яндексе. Как сделать отказоустойчивый грид из тысячи браузеров
    0
    Я уверен — виноват именно роутер из статьи, поэтому лучшего места для этот репорта не найти
  • Неизменяемость в JavaScript
    +1
    На практике, во множестве случаев применение неизменяемых данных увеличит общую производительность вашего приложения, даже если определённые операции станут более затратными в отдельности.

    Как частенько договаривал неизвестный Andre_487 за известным Станиславским: не верю! Есть ли бенчмарки конкретных реализаций на JS?

    Можно понять, как иммутабельность и чистые функции делают быстрее программы на языках, где это ядерная концепция, позволяющая оптимизировать и разводить по потокам при компиляции, но в JS ведь это отсутствует и оптимизации в современных машинах рассчитаны совсем не на подобные паттерны.
  • Одна из особенностей PHP, связанная с методами и функциями
    0
    У JS и PHP активный обмен опытом: в PHP объявляют вложенные функции, в React пишут HTML среди кода
  • 10 основных ошибок при разработке на Node.js
    +6
    Потому что мы злодеи — поощряем страдания того, кто сам погрязает в собственном безумии.
  • Проверка Vim при помощи PVS-Studio в GNU/Linux
    0
    То есть, все-таки что-то планируется, просто позже, когда продукт дойдет до кондиции?
  • Проверка Vim при помощи PVS-Studio в GNU/Linux
    0
    Можно узнать, почему категорически не планируется публичных версий под Linux?
  • Вычислите длину окружности
    0
    После многолетних экспериментов определили везде пи через #define

    А вы думали, почему дистрибутив разрастался?
  • Comment from a drafted post.
  • Топ10 ошибок, совершаемых при разработке на AngularJS
    0
    Это тяжелое наследие JSLint Крокфорда и его нелюбви к FD, и особенно определенным ниже использования. Нужно выставлять latedef: 'nofunc' и радоваться.
  • Топ10 ошибок, совершаемых при разработке на AngularJS
    +2
    <irony>
    А то и так:
    loDash.factory('_', function($window) {
      return $window._;
    });
    

    </irony>
  • Топ10 ошибок, совершаемых при разработке на AngularJS
    +4
    Почему же нельзя?
  • Недостатки Wordpress — техническая сторона
    0
    Вы поразитесь еще больше, узнав, что так умеют не только на PHP. Да что там, большая часть кода, который прекрасно работает, похожа на огромную кучу навоза.
  • WSGI/Rack для PHP
    +4
    А как в современных версиях PHP с управлением памятью? Возможно ли эффективное длительное выполнение скрипта?
  • Пуленепробиваемые тесты JavaScript
    0
    Хотелось бы попрдробнее узнать о методике Benchmark.js: как именно выбирается количество повторов, что значит «столько раз, чтобы получить статистически значимые результаты»? Есть ли такая информация?
  • Изоморфный БЭМ
    0
    Можно задать обратный вопрос: а почему код изначально не на GitHub'е? )
  • Нетрадиционный обзор React
    0
    В императивной шаблонизации я сторонник подхода, при котором представление — это практически чистый HTML, код в котором ограничивается выводом значений переменных, циклами, ну, может, еще какими-нибудь элементарными вещами. Мне кажется, что много HTML — мало кода читается гораздо лучше и выглядит гораздо чище, чем много HTML и много кода. А уж о бизнес-логике в представлении и речи не было.
  • BemPHP: реализация методологии БЭМ средствами PHP
    +1
    Отличная идея — разнообразить БЭМ новыми языками. Но не совсем правильно утверждать, что для БЭМа все делается на JS для Node.js. Блок в библиотеке представляет собой набор файлов, реализующих разные «технологии»: файл block.deps.js для зависимостей, block.css — для нормальных стилей, block.ie.css — для костылей IE, block.browser.js — для браузерного кода, block.bh.js — шаблон для выполнения в BH и так далее. Блок, таким образом, является (почти) самодостаточным компонентом, содержащим код для всего стека разработки фронтенда. Как именно блоки со своими наборами технологий выводятся на страницу, во многом определяется данными в формате BEMJSON — то есть, фронтенд строится по data driven парадигме. Как именно все это собирается в страницы, можно изучить на примере.

    Поэтому если идти до конца по этому пути, нужно реализовать свою технологию, которая будет использовать PHP как технологию блока. Кстати говоря, не так давно появилась подобная штука: порт на PHP шаблонизатора BH: github.com/bem/bh-php
  • Нетрадиционный обзор React
    –6
    Интересный момент в том, что в PHP, откуда, видимо, создатели и черпали вдохновение, уже много лет считается хорошей практикой не смешивать HTML и логику. Именно на этом настаивают сторонники дополнительных шаблонизаторов в PHP, который сам по себе неплохой шаблонизатор.
  • Как Битрикс чуть Новый Год не погубил
    0
    Ну, конкретно этот шаблон (кстати, что это за шаблонизатор?) — совершенно не читаемая каша. Уж лучше было бы применить немного PHP для улучшения читаемости — скажем, составлять длинные списки классов с помощью массивов.

    Есть же отличные примеры правильной шаблонизации на чистом PHP — посмотреть на Yii, Kohana или любой другой MVC-фреймворк.
  • Как Битрикс чуть Новый Год не погубил
    0
    Мне кажется, отсутствие возможности размахнуться художествами в коде — не особенно плюс, хотя и вынуждает держать логику отдельно от шаблонов.
  • Интернет в закрытой стране: Опыт Северной Кореи
    0
    Интересно было бы узнать, какие при этом цены
  • Миграция проекта со StarTeam в SVN
    +3
    Вообще говоря, «имею опыт работы» — очень даже аргумент, особенно когда организуешь не свой личный проект, а промышленного монстра. Если нужно наладить стройный релизный цикл, мало прочитать даже эту замечательную книжку. Опыт работы очень помогает, когда появляются исследования истории, откаты, переносы задач по одной в релизную ветку и все вот это релизное. Я уж не упоминаю о задачах спасения перетертых или поврежденных данных.

    Так что автор все правильно сделал: для большого проекта — знакомая СКВ, для себя — Гит.
  • Пишем быстрый и экономный код на JavaScript
    0
    Так же было бы круто перевести статьи по ссылкам из данной