Идеи пользователя 9746
Некоторое время назад в Битриксе появилась минификация CSS и JS файлов - отлично! Теперь хочется и минификация HTML-кода. Особенно это актуально для модных одностраничных "портянок" с горой HTML'я.
Да, есть модуль "Компрессия", но только gzip'ует, а не минифицирует код, но такое сжатие лучше оставить веб-серверу (н-р, nginx), а от модуля хватило бы только минификации.
Да, есть модуль "Компрессия", но только gzip'ует, а не минифицирует код, но такое сжатие лучше оставить веб-серверу (н-р, nginx), а от модуля хватило бы только минификации.
В Битриксе есть ошибки и это нормально. Даже есть критические, ломающие сайт - это тоже нормально. Но когда они проявляются после установки стабильных обновлений или установки "голой" коробки - это непростительно.
Да, вся разработка проектов ведётся на dev-серверах, да, создана извращённая система доставки релизов (git & git flow вывозят) с dev на production и это очень сильно помогает не "положить" production кривым обновлением Битрикса. Но давайте уже разрабатывать платформу современными методами и современными инструментами, а не радоваться тому, что в 2015 году наконец-то научились минифицировать CSS & JS и узнали, что такое адаптивность.
На стороне разработки платформы нужно CI (Continuous Integration, непрерывная интеграция), нужно хорошее покрытие разнообразными тестами и публичные статусы каждого обновления/релиза.
Также нужно несколько эталонных установок Битрикса хотя бы в самых минимальных конфигурациях в виртуальной лаборатории, которые будут постоянно обновляться всеми выпущенными обновлениями для того, чтобы можно было сравнить со своей установкой и быстро понять, на чей стороне ошибка. (Сейчас ТП на любой чих просит доступ к сайту, чтобы исследовать ошибку; раньше удавалось воспроизвести ошибку в Виртуальной лаборатории, но её убили).
На стороне клиента/партнёра нужна возможность самостоятельно запускать готовые тесты для проверки коробки и обновлений.
Не жду скорейшей реализации этой идеи, тут работы на несколько месяцев как минимум, но и забивать на это тоже нельзя.
Да, вся разработка проектов ведётся на dev-серверах, да, создана извращённая система доставки релизов (git & git flow вывозят) с dev на production и это очень сильно помогает не "положить" production кривым обновлением Битрикса. Но давайте уже разрабатывать платформу современными методами и современными инструментами, а не радоваться тому, что в 2015 году наконец-то научились минифицировать CSS & JS и узнали, что такое адаптивность.
На стороне разработки платформы нужно CI (Continuous Integration, непрерывная интеграция), нужно хорошее покрытие разнообразными тестами и публичные статусы каждого обновления/релиза.
Также нужно несколько эталонных установок Битрикса хотя бы в самых минимальных конфигурациях в виртуальной лаборатории, которые будут постоянно обновляться всеми выпущенными обновлениями для того, чтобы можно было сравнить со своей установкой и быстро понять, на чей стороне ошибка. (Сейчас ТП на любой чих просит доступ к сайту, чтобы исследовать ошибку; раньше удавалось воспроизвести ошибку в Виртуальной лаборатории, но её убили).
На стороне клиента/партнёра нужна возможность самостоятельно запускать готовые тесты для проверки коробки и обновлений.
Не жду скорейшей реализации этой идеи, тут работы на несколько месяцев как минимум, но и забивать на это тоже нельзя.
Наличие любого параметра (?blablabla) у ссылки на подключаемый файл заставляет любое клиентское приложение (браузер, прокси-сервер, мобильное приложение и т.д.) обязательно обратиться за файлом на сервер.
Это RFC.
Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла.
Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.
Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).
Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.
UPDATE 2015-04-01
Теоретическое обоснование и рекомендации от известных разработчиков:
Это RFC.
Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла.
Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.
Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).
Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.
UPDATE 2015-04-01
Теоретическое обоснование и рекомендации от известных разработчиков:
- Application cache
Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network.
- В Apache
- В Nginx
- Rails Asset Pipeline
- Модуль Web Optimizer для 1С-Битрикс, многие идеи из которого перешли "в коробку"
- Все проекты TM (.)
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
