Препроцессоры позволяют использовать медиа-запросы непосредственно внутри блока свойств. После обработки соответствующие селекторы будут заключены внутри блока медиа-запроса. Препроцессор, таким образом, меняет порядок селекторов.

Из файла test.less

@tablets: ~"(min-width: 768px) and (max-width: 979px)";
@mobile: ~"(max-width: 767px)";

.widget {
  float: left;
  width: 25%;

  @media @tablets { float: none; width: 100%; }
  @media @mobile { display: none; }

  > .title {
    font-size: 18px;

    @media @tablets { font-size: 16px; font-weight: bold; }
  }

}

получаем test.css

.widget {
  float: left;
  width: 25%;
}
@media (min-width: 768px) and (max-width: 979px) {
  .widget {
    float: none;
    width: 100%;
  }
}
@media (max-width: 767px) {
  .widget {
    display: none;
  }
}
.widget > .title {
  font-size: 18px;
}
@media (min-width: 768px) and (max-width: 979px) {
  .widget > .title {
    font-size: 16px;
    font-weight: bold;
  }
}

Главное удобство этого подхода в том, что селекторы в исходном файле располагаются в непосредственной близости. Такую запись легко читать и исправлять. Даже в конечном CSS они будут располагаться друг за другом. Это, на мой взгляд, гораздо удобнее, чем группировать все правила для медиа-запросов в одном файле и подключать его в конец стилей.

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

• Одинаковые последовательности символов отлично сжимаются при передаче с HTTP-сервера, если настроено сжатие файлов.
• Отдельные блоки Media Queries почти не влияют на производительность браузера при рендеринге страницы.

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