что происходит, когда Вы вводите в URL в [закрытом] браузере

Сначала компьютер смотрит в хост назначения. Если он существует в локальном кэше DNS, он использует эту информацию. В противном случае DNS Querying выполняется до тех пор, пока не будет найден IP-адрес.

Затем ваш браузер открывает соединение TCP к хосту назначения и отправляет запрос в соответствии с HTTP 1.1 (или может использовать HTTP 1.0, но обычные браузеры не делают это больше).

Сервер смотрит вверх по необходимым ресурсам (если он существует) и отвечает с использованием протокола HTTP, отправляет данные клиенту (= ваш браузер)

браузер, затем использует Parser HTML для повторного создания структуры документа, которая позже Представлено вам на экране. Если он находит ссылки на внешние ресурсы, такие как изображения, файлы CSS, файлы JavaScript, они доставляются так же, как сам документ HTML.

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

Например.

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

Внимание: это чрезвычайно грубый и упрощенный эскиз, предполагающий максимально простой HTTP-запрос (нет HTTPS, нет HTTP2, нет дополнительных данных), простейший DNS, нет прокси, одностековый IPv4, только один HTTP-запрос, простой HTTP-сервер на другом конце, и никаких проблем на любом шаге. Для большинства современных намерений и целей это нереалистичный сценарий; все они намного сложнее в реальном использовании, и технологический стек стал на порядок сложнее с тех пор, как это было написано. С учетом этого следующая временная шкала всё ещё в некоторой степени действительна:

1. браузер проверяет кэш; если запрошенный объект находится в кэше и является свежим, перейдите к # 9
2. браузер запрашивает у ОС IP-адрес сервера
3. ОС выполняет поиск в DNS и отвечает, что IP-адрес в браузере
4. открывает TCP-соединение с сервером (этот шаг намного сложнее с HTTPS)
5. браузер отправляет HTTP-запрос через TCP-соединение
6. браузер получает HTTP-ответ и может закрыть TCP-соединение или повторно использовать его для другого запроса
7. браузер проверяет, является ли ответ перенаправлением или условным ответом (3xx кодов состояния результата), запрос авторизации (401), ошибка (4xx и 5xx) и т.д.; они обрабатываются иначе, чем обычные ответы (2xx)
8. , если они кэшируются, ответ сохраняется в кэше
9. , который декодирует ответ браузера (например, если он gzipped)
10. браузер определяет, что делать с ответом (например, это HTML-страница, изображение, звуковой клип?)
11. браузер представляет ответ или предлагает диалог загрузки для нераспознанных типов

. принять это только как резюме, сокращенное для ясности. Кроме того, параллельно с этим происходит много других вещей (обработка набранного адреса, спекулятивная предварительная выборка, добавление страницы в историю браузера, отображение хода выполнения для пользователя, уведомление плагинов и расширений, визуализация страницы во время ее загрузки, конвейеризация, отслеживание соединений для сохранения активности, управление куки-файлами, проверка на наличие вредоносного контента и т.д.) - и вся операция становится на порядок сложнее с HTTPS (сертификаты и шифры и pinning, о мой!).

Посмотрите на спецификацию http. Или начать, попробуйте http://www.jmarshall.com/easy/http/