Я был одержим производительностью в Интернете и автоматизацией задач, просто чтобы сделать Интернет быстрее и сократить время разработчиков. Я хотел, чтобы процесс создания веб-приложений был настолько безболезненным, как кажется. Я потратил некоторое время на изучение книг, статей и сообщений в блогах от таких гениев веб-перфоманса, как Пол Айриш, Адди Османи и Илья Григорик.
Недавно мой наставник предложил попробовать оптимизировать oppia. Мы начали с оптимизации внешнего интерфейса, как это было предложено в статье Высокопроизводительные веб-сайты: основные знания для инженеров внешнего интерфейса, сократив как можно больше HTTP-запросов. Одним из узких мест было то, что Oppia использует множество сторонних библиотек, поддерживать и оптимизировать их может быть сложно.
У нас была неделя или две, чтобы разрабатывать, как мы можем оптимизировать контент и максимально сократить количество HTTP-запросов. И я вспомнил свой любимый инструмент для автоматизации задач Gulp. Проблема заключалась в том, что мы не используем node напрямую в oppia (мы используем python) ooh snap, но node входит в число загружаемых нами внешних зависимостей и используется в интеграции (e2e) и во внешнем тестировании. Поскольку мы используем GoogleAppEngine в качестве нашего сервера, как, черт возьми, мы собираемся использовать gulp для запуска сервера? Мы черпали вдохновение из репозитория gulp-gae. Единственная проблема заключалась в том, что gulp-gae предполагает, что вы установили движок приложений Google, и экспортируется на ваш путь. Но в Oppia мы не хотим, чтобы разработчик устанавливал GAE перед его использованием. Скачиваем и пользуемся, не устанавливая на компьютер разработчика. Поэтому мне пришлось изменить gulp-gae, чтобы это разрешить. Мы хотели, чтобы сервер запускался с помощью gulp, потому что есть некоторые задачи, такие как задачи наблюдения, которые должны выполняться параллельно с запущенным сервером. Это удобно, когда разработчик вносит некоторые изменения в файлы, которые нам нужны перестроить даже без остановки и повторного запуска сервера.
Мне удалось минимизировать и объединить все сторонние css и javascripts. Это уменьшает количество загружаемых ресурсов. До этих изменений мы загружали почти 3 МБ файла css и почти 8,9 МБ файлов Javascript. Но я смог сократить css до 297 КБ CSS и 935 КБ Javascript.
Также у нас был один из беспорядочных способов загрузки и обновления сторонних библиотек. Поэтому мы разработали лучший способ сделать это, добавив manifest.json, который документирует все подробности о том, что загружать и что следует оптимизировать.
В основном я жду, чтобы увидеть, как это улучшит наш тест на понимание скорости, когда он будет развернут во время нашего следующего выпуска. Другая проблема, которая по-прежнему является узким местом, - это попытка уменьшить время до первого байта (TTFB), измерение, используемое в качестве показателя скорости отклика веб-сервера или другого сетевого ресурса.
