Otrivin

На бэке рассчитать вес каждого подключаемого ресурса в gz, передать в data-атрибут (хоть в байтах, хоть в процентах); на фронте обойти все эти ресурсы, рассчитывая общий вес, затем вешать слушателя на onload каждого из них и считать. Переменную можно использовать глобальную, window['awesomeCounter']

Для оптимизации использовать кэш + прописать атрибут заранее, если ресурсы статические

Используйте инструмент Coverage в chromium-браузерах.
Я собираю статистику по всем типовым страницам, включая попапы/медиа запросы, затем чищу css на основании её анализа. К сожалению, полностью автоматических корректно отрабатывающих инструментов я не встречал.

У Яндекса есть спеллер. На гитхабе есть классы для работы с ним.
Попробуйте, может помочь

Если проект развернут на веб-сервере либо у Вас Линукс, воспользуйтесь этой инструкцией

Думаю, имеется в виду:
- Использование заголовков h1-h6 строго в упорядоченном виде согласно иерархии, и только в пределах основного контента страницы

- Избегать чрезмерного использования "a", чтобы не плодить лишних внутренних ссылок (например, при вёрстке ИМ, карточку товара можно целиком обернуть в ссылку, а можно сделать div, в котором будет 3 одинаковых "a"-элемента - на имени, на изображении, на кнопке "подробнее"

- В принципе меньшее количество элементов на странице (имеется в виду избегание лишних оборачиваний элементов в контейнеры). Меньше нод - выше скорость парсинга страницы, выше ее производительность.

- Также в копилочку производительности использование всяких штук типа "responsive images", ленивой загрузки, критических стилей, приоритезации загрузки ресурсов (стили/скрипты/шрифты).

- Валидность. Без комментариев.

Как зависит? Ну, говорят, Гугл любит технически качественные сайты. Плюс скорость работы сайта сказывается на юзабилити, что в свою очередь отражается на поведенческих факторах, что тоже влияет на позиции.

Стоит.