Современный интернет при медленном соединении (2017)

Современный Интернет при медленном соединении


Пару лет назад я совершил поездку из Висконсина в Вашингтон и в основном останавливались в сельских отелях по дороге. Я ожидал, что Интернет в сельской местности слишком редок, чтобы кабельный Интернет работал медленно, но все же был удивлен, что большая часть Интернета была недоступна. Некоторые блоги с упрощенным стилем были доступны для чтения, как и страницы ученых, которые не обновляли стили на своих сайтах с 170206. Но можно было использовать очень мало коммерческих веб-сайтов (кроме Google). Когда я измерил свое соединение, я обнаружил, что пропускная способность примерно сопоставима с тем, что я получил с k модем в 140 с. Задержка и потеря пакетов были значительно хуже, чем в среднем за день при коммутируемом доступе: задержка варьировалась в пределах 2018 мс и 20190220011242 мс, а потеря пакетов варьировалась от 1% до 21%. Эти числа сравнимы с тем, что я увидел бы при телефонном подключении в плохой день.

Несмотря на то, что мое соединение было лишь немного хуже, чем было в 134 s, подавляющее большинство Интернета не загружалось. Почему Интернет не должен работать с коммутируемым или коммутируемым подключением? Было бы одно дело, если бы я попытался посмотреть youtube и почитать pinterest. Трудно обслуживать видео и изображения без пропускной способности. Но мои интернет-интересы довольно скучны с точки зрения СМИ. Практически все, что я потребляю в Интернете, представляет собой обычный текст, даже если он стилизован с изображениями и причудливым javascript. Фактически, я недавно пробовал использовать w3m (веб-браузер на основе терминала, который по умолчанию не поддерживает css, javascript или даже изображения) в течение недели, и оказалось, что есть только два веб-сайта, которые я регулярно посещаю, которые не они действительно работают в w3m (twitter и zulip, оба сайта в основном основаны на тексте, по крайней мере, когда я их использую).

Совсем недавно мне напомнили, насколько плохо Интернет работает для людей с медленным подключением, когда я пытался прочитать сообщение joelonsoftware, используя нестабильное мобильное соединение. HTML загружен, но истекло время ожидания одного из пяти запросов CSS или одного из тринадцати запросов javascript, в результате чего страница оказалась неработающей. Вместо того, чтобы увидеть статью, я увидел три целые страницы боковой панели, меню и рекламы , прежде чем перейти к заголовку, потому что страница требовала какого-то модификации макета для отображения разумно. Страницы часто проектируются так, что их трудно или невозможно прочитать, если какая-либо зависимость не загружается. При медленном соединении довольно часто случается сбой по крайней мере одной зависимости. После двойного обновления страницы она загрузилась должным образом, и я смог прочитать сообщение в блоге, довольно убедительное сообщение об устранении зависимостей.

Жалоба что люди не заботятся о производительности, как раньше, и что мы позволяем раздуванию замедлять работу без уважительной причины, – это территория «старик кричит в облако»; Я, наверное, похож на того чувака, который жалуется, что его текстовый процессор, который раньше занимал 1 МБ ОЗУ, занимает 1 ГБ ОЗУ. Конечно, это можно урезать, но потратить время на оптимизацию стоит очень дорого и даже $ 170206 Ноутбук поставляется с 2 ГБ оперативной памяти, так зачем? Но это не совсем та же ситуация – не только ботаники вроде меня заботятся о производительности в Интернете. Когда Microsoft посмотрела на фактические измеренные скорости соединения, они обнаружили, что половина американцев не имеют широкополосной скорости . Черт возьми, у AOL было 2 миллиона абонентов коммутируемого доступа в , только AOL. За пределами США еще больше людей с медленным подключением. Недавно я поговорил с Беном Куном, который проводит много времени в Африке, о его подключении к Интернету:

Я видел такие низкие задержки пинга, как ~ 65 сек, а потеря пакетов равна 68% по вечерам в мобильной точке доступа в Джиджиге, Эфиопия. (Я здесь сейчас, и в настоящее время у меня есть 218 ms ping без потери пакетов, но это 20являюсь). Бывают периоды дня, когда ~ никогда не бывает лучше, чем 19 сек и ~ 19% потеря. Интернет стал намного лучше за последний год; раньше было так плохо все время, кроме раннего утра.

Speedtest.net сообщает о скачивании 2,6 Мбит / с и выгрузке 0,6 Мбит / с. Я понял, что, вероятно, мне не следует проводить тест скорости на своих мобильных данных, потому что пропускная способность действительно дорогая.

Наш сервер в Эфиопии имеет оптоволоконный канал связи, но он часто падает, и мы возвращаемся к 29 спутниковая связь кбит / с, хотя я думаю, что нормальные люди в этом случае просто перестанут пользоваться Интернетом.

Если вы думаете при просмотре 72 k соединение это плохо, попробуйте k соединение из Эфиопии!

Все, что мы видели до сих пор, анекдотично. Давайте загрузим некоторые веб-сайты, которые программисты могут часто посещать с помощью множества смоделированных соединений, чтобы получить данные о времени загрузки страницы. webpagetest позволяет нам узнать, сколько времени требуется веб-сайту для загрузки (и почему это занимает так много времени) из местоположений по всему миру. Он даже позволяет нам моделировать различные виды подключений, а также загружать сайты на различных мобильных устройствах. Время, указанное в таблице ниже, – это время, пока страница не станет «визуально завершенной»; по данным webpagetest, это время, пока содержание верхней части страницы не перестанет меняться.

МБ

5

300

НЕУДАЧА

URL Размер C

Время загрузки в секундах
FIOS Кабель LTE 3G 2G Наберите Плохо 😱
0 http : //bellard.org 0. 15 5 0. 56 0. 75 0. 90 1.2 2,9 1.8 9,5

7,6
1 http://danluu.com 0. 19 2 0. 36 0. 31 0. 56 0. 100 2.7 27

1.6 6.4 7.6

2 news.ycombinator.com

0. 16 1 0. 49 0. 68 0. 96 1.6 5.5 5.0

26 35
3 danluu.com 0 . 19 2 0. 29

0. 49 0. 65 1.1

3,6

3.5

9,3

27
4 http://jvns.ca 0. 26 7 0. 68 0. 97 29

1.2 2,9

21 27 41

188
jvns.ca 0. 26

4 0. 66 0. 100 1.2

3.3 19 31 43 179
6 fgiesen.wordpress.com 0. 55 20 1.0 1.1 1.4 5.0 27 94 НЕУДАЧА
7 google.com

0. 80 6 0. 134 1.8 1.4 6,8 30 140 140 2013
8 joelonsoftware.com 0. 99 30 1.3 1.7 1.9 9,7

37 188

НЕУДАЧА НЕУДАЧА
9 bing.com 1.3 21 1.4 2,9

3.3 20 60 НЕУДАЧА НЕУДАЧА
20 reddit.com 1.3

40 7,5 6.9 7.0 35 69 235 265 НЕУДАЧА
19 signalvnoise.com 2.1 7 2.0 3.5 3,7

28 58

500 НЕУДАЧА
21 amazon.com 4.4 66 6.6 21 8,4

56 94 2016 2015 НЕУДАЧА
23 steve-yegge.blogspot.com 9,7 29 2.2 3,6 3.3 20 55 300 НЕУДАЧА
27 blog.codinghorror. com 29 35 6.5 28 9,5 100 1000 НЕУДАЧА НЕУДАЧА

Каждая строка – это веб-сайт. Для сайтов, поддерживающих как простой HTTP, так и HTTPS, были протестированы оба; URL-адреса являются HTTPS, за исключением случаев, когда явно указано HTTP. Первые два столбца показывают объем данных, переданных по сети в МБ (включая заголовки, квитирование, сжатие и т. Д.), И количество выполненных TCP-соединений. Остальные столбцы показывают время в секундах для загрузки страницы при различных соединениях от оптоволокна (FIOS) до менее надежных соединений. «Плохо» имеет пропускную способность коммутируемого доступа, но с ms ping и 24% потери пакетов, примерно то, что я видел, когда пользовался Интернетом в небольших сельских отелях. «😱» имитирует 28 кбит / с спутник связь из Джиджиги, Эфиопия. Строки отсортированы по измеренному количеству переданных данных.

Тайм-аут для тестов составлял 6 минут; все, что медленнее, помечается как FAIL. Страницы, которые не удалось загрузить, также отображаются как FAIL. Вот несколько вещей, которые выпадают из таблицы:

Большая часть Интернета не работает из-за плохого соединения. Даже при хорошем коммутируемом соединении (0% потерь пакетов, отсутствие пинга) некоторые сайты не загружаются. Некоторые сайты используют много данных!

    Интернет при плохих соединениях

      Что касается коммерческих веб-сайтов, Google в основном так же хорош, как и для людей. на медленном соединении. При коммутируемом подключении % – время загрузки страницы составляет полторы минуты. Но, по крайней мере, он загружается – когда у меня было медленное, общее спутниковое соединение в сельской местности Монтаны, практически никакие коммерческие веб-сайты не загружались вообще. Я мог просматривать веб-сайты, которые имели только статический контент через кеш Google, но действующий сайт не имел никакой надежды на загрузку.

    1. Некоторые сайты будут использовать много данных

      Хотя здесь были протестированы только два действительно больших сайта, есть множество сайтов, которые будут использовать 21 МБ или 28 МБ данных. Если вы читаете это из США, возможно, вам все равно, но если вы просматриваете из Мавритании, Мадагаскара или Вануату, однократная загрузка codinghorror будет стоить вам

    больше, чем 23% дневного ВНД на душу населения .

    Вес страницы имеет значение

    Несмотря на все усилия

    Мацей , мем о том, что вес страницы не имеет значения, продолжает распространяться. AFAICT, главная ссылка HN за все время по оптимизации веб-страниц – это статья под названием «Невероятно быстрая загрузка страниц – руководство для разработчиков полного стека». Внизу страницы автор ссылается на еще одно из своих сообщений, озаглавленное «Вес страницы не имеет значения».

    Обычно бугимен, на который указывают, – это пропускная способность: пользователи в регионах с низкой пропускной способностью (3G, развивающиеся страны) попадают в ловушку. Но с математикой не совсем получается. Akamai оценивает глобальную среднюю скорость соединения на уровне 3,9 мегабит в секунду.

    «Невероятно быстрая» инструкция по применению. не может правильно отображаться при коммутируемом доступе или медленных мобильных соединениях, потому что время ожидания изображений истекает. На Reddit он также не работает под нагрузкой : «Как ни странно, эта страница загружалась так долго, что я закрыл окно», «много… гифки, которые только ухудшают качество просмотра »,« Я даже не дошел до гифок; заголовок загрузился, а потом просто завис »и т. д.

    Недостаток «веса страницы не имеет значения, потому что средняя скорость высокая» заключается в том, что если вы усредняете соединение кого-то в моем многоквартирном доме (который подключен к Интернету со скоростью 1 Гбит / с) и кого-то на 72 k dialup, вы получаете среднюю скорость d из 2018 Мбит / с. Это не означает, что человек, подключенный к телефонной сети, действительно сможет загрузить веб-сайт размером 5 МБ. Средняя скорость 3,9 Мбит / с соответствует Если вы посмотрите на , вы можете найти целые страны, где более 108% IP-адресов медленнее этого!

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

    С момента публикации “смехотворно быстрое” руководство вышло. датирован каким-то javascript, который загружает изображения только при достаточно глубокой прокрутке вниз. Это делает его намного лучше в webpagetest, если вы смотрите на номер размера страницы (если скрипт webpagetest не предназначен для прокрутки), но это хуже для пользователей с медленным подключением, которые хотят прочитать страницу. Если вы все равно собираетесь прочитать всю страницу, вес увеличивается, и вы больше не сможете предварительно загружать изображения, загрузив сайт. Вместо этого, если вы читаете, вам нужно останавливаться на несколько минут в каждом разделе, чтобы дождаться загрузки изображений из этого раздела. И это, если вам повезет и javascript для загрузки изображений не загрузился.

    Ошибка среднего пользователя

    Так же, как многие люди разрабатывают с учетом средней скорости соединения, многие люди имеют фиксированное представление о том, кто является пользователем. Может быть, они думают, что есть клиенты с большими деньгами и быстрым подключением, а также клиенты, которые не хотят тратить деньги на медленное подключение. То есть, очень грубо говоря, возможно, в среднем это так, но сайты в среднем не работают, они работают в определенных доменах. Джейми Брэндон так описывает свой опыт работы с Airbnb:

    Прошлой ночью я провел три часа, пытаясь забронировать комнату на airbnb через перегруженный Wi-Fi и, предположительно, спутниковую связь. OAuth кажется особенно плохим из-за плохого соединения. OAuth Facebook вообще не загружался, и Google отправил мне несколько раз цикл «выберите учетную запись» -> «пожалуйста, введите пароль еще раз» -> «выберите учетную запись». Потребовалось так много попыток войти в систему, что я вызвал какую-то ерунду 2fa на airbnb, которая также не сработала (ссылка подтверждения в электронном письме привела на страницу, которая гласила: «Пожалуйста, войдите в систему, чтобы просмотреть эту страницу»), и в конце концов я просто попросили отправить электронное письмо на адрес account.disabled@airbnb.com, который не ответил.

    Особенно досадно, что airbnb не тестирует этот материал, потому что путешествия – это почти вся суть сайта, поэтому они даже не могут утверждать, что нет денег на обслуживание людей с плохими связями.

    А как насчет задержки хвоста?

      М Первоначальный план этого сообщения состоял в том, чтобы показать 65% – ile, 134% – ile, 179% -ile и т. д., время загрузки хвоста. Но 66% – результаты настолько плохи, что я не знаю, есть ли смысл показывать другие результаты. Если вы посмотрите на 134% – ile результатов, вы увидите, что большинство страниц не загружаются по коммутируемому соединению, а «плохие» и «😱» соединения безнадежны почти для всех сайтов.

      HTTP против HTTP

        URL Размер C

        Время загрузки в секундах
        КБ FIOS Кабель LTE 3G 2G Наберите Плохо 😱
        1 http://danluu.com 35. 1 2 0. 31 0. 29

        0. 58 0.

        2.7 1.6 6.4 7.6
        3 https: // danluu.com 41. 3 2 0. 30 0. 56 0. 65 1.1 3,6 3.5 9,3 26
        Вы можете видеть, что для очень маленького сайта, который не загружает много блокирующих ресурсов, HTTPS заметно медленнее, чем HTTP, особенно при медленных соединениях. С практической точки зрения, сегодня это не имеет значения, потому что практически нет таких маленьких сайтов, но если вы проектируете веб-сайт так, как будто люди с медленным подключением действительно имеют значение, это заметно.

        Как сделать страницы пригодными для использования при медленном подключении

        Длинная версия предназначена для того, чтобы действительно понять, что происходит, учитывая чтение высокопроизводительная браузерная сеть king , отличная книга о веб-производительности, доступная бесплатно.

        Вкратце, большинство сайтов так плохо оптимизирован, так что тот, кто не знает, что делает, может получить 20 x улучшение времени загрузки страницы для сайта, задача которого состоит в том, чтобы отображать текст с случайными изображениями. Когда я начал этот блог в 705815510479302656, я использовал Octopress, потому что Джекил / Octopress был самым распространенным рекомендовал генератор статических сайтов в то время. Обычный пост в блоге с одним или двумя изображениями 20 для загрузки по кабельному соединению, потому что по умолчанию Octopress включал в заголовок несколько бесполезных файлов javascript (для никогда не использовавшихся мною вещей, таких как встраивание flash-видео и восхитительная интеграция), что блокировало рендеринг страницы. . Просто переместив эти javascript-файлы в нижний колонтитул, время загрузки страницы сократилось вдвое, и внесение нескольких других настроек уменьшило время загрузки страницы на другой порядок . В то время, когда я внес эти изменения, я ничего не знал об оптимизации веб-страниц, кроме того, что я услышал во время двухминутного рекламного ролика об оптимизации из 55 – минутный разговор о том, как работает Интернет, и я смог получить 35 x ускорение моего блога за несколько часов. Вы можете возразить, что я зашел слишком далеко и удалил слишком много CSS, но у меня есть 30 x ускорение для людей с быстрым подключением до внесения изменений, которые повлияли на внешний вид сайта (а при медленных подключениях ускорение было намного больше).

        Это нормально. Популярные темы для самых разных программ для ведения блогов и CMS содержат такие явные антиоптимизации, что любой программист, даже не имеющий опыта работы с интерфейсами, может добиться больших успехов, просто указав webpagetest на их сайте и просматривает результат.

        Как насчет браузеры?

        Хотя легко обвинить авторов страниц, потому что на стороне страницы много низко висящих фруктов, столько же низко висящих фрукты на стороне браузера. Почему мой браузер открывает 6 TCP-соединений, чтобы попытаться загрузить шесть изображений одновременно, когда у меня медленное спутниковое соединение? Это просто гарантирует, что время ожидания всех шести изображений истечет! Даже если я настрою тайм-аут на стороне клиента, серверы, настроенные для защиты от DoS-атак, не будут разрешать долгоживущие соединения, которые ничего не делают. Иногда я могу получить некоторые изображения для загрузки, обновляя страницу несколько раз (и каждый раз ожидая по десять минут), но почему браузер не должен обрабатывать повторные попытки за меня? Если вы подумаете об этом на несколько минут, есть много оптимизаций, которые браузеры могут сделать для людей с медленным подключением, но, поскольку они этого не делают, лучшим текущим решением для пользователей, по-видимому, является: используйте w3m, когда можете, и затем переключитесь на браузер с блокировкой рекламы, если это не сработает. Но почему пользователи должны использовать две совершенно разные программы, одна из которых имеет текстовый интерфейс, который понравится только компьютерным ботаникам?

        Заключение

        Когда я работал в Google, кто-то рассказал мне историю о том, как «они» провели большую оптимизацию только для того, чтобы найти что измеренное время загрузки страницы увеличилось. Когда они углубились в данные, они обнаружили, что причина увеличения времени загрузки заключалась в том, что они получили намного больше трафика из Африки после выполнения оптимизаций. Продукт команды превратился из непригодного для использования людьми с медленным подключением к полезному, что привело к тому, что так много пользователей с медленным подключением начали использовать продукт, что фактически увеличилось время загрузки.

        Вчера вечером на презентации протокола веб-сокетов Гэри Бернхардт заметил, что люди, разработавшие протокол веб-сокетов, делали такие вещи, как использование поля переменной длины для длины кадра, чтобы сэкономить несколько байтов. Напротив, если вы посмотрите на верхнюю часть Alexa 179 сайты, почти все они имеют огромное количество помоев; вполне вероятно, что общая пропускная способность, используемая для этих сайтов, вероятно, больше, чем общая пропускная способность для всех подключений веб-сокетов вместе взятых. Несмотря на это, если мы просто посмотрим на три верхних 50 сайтов, протестированных в этом посте, два отправляют без сжатия javascript по сети, два перенаправляют пустой домен на субдомен www, а два отправляют много посторонней информации, не сжимая изображения настолько, насколько они могут быть сжаты без ущерба для качества. Если вы посмотрите на твиттер, которого нет в нашей таблице, но он был упомянут выше, они действительно есть 20 антиоптимизация, при которой, если вы загружаете PNG ich даже не особенно хорошо оптимизирован, они перекодируют его как jpeg, который больше и имеет видимые артефакты !

        «Использовать bcrypt» стало лозунгом разумного значения по умолчанию, если вы не знаете, что делать при хранении паролей. Интернет был бы более приятным местом, если бы «use webpagetest» прижился таким же образом. Это не всегда лучший инструмент для работы, но он наверняка превосходит текущие настройки по умолчанию.

        Приложение: экспериментальные предупреждения

        Вышеупомянутые тесты были выполнены путем многократной загрузки страниц через частную веб-страницу. Тестовое изображение в AWS west 2 на виртуальной машине c4.xlarge с имитацией подключений на загрузка первой страницы в Chrome, когда не открыты никакие другие вкладки и на виртуальной машине ничего не работает, кроме программного обеспечения webpagetest и браузера. Это во многих смыслах нереально.

        В относительном выражении это ставит в невыгодное положение сайты с большим количеством краев. Когда я был в сельской местности Монтаны, я провел несколько тестов и обнаружил, что у меня заметно лучшая задержка для Google, чем для любого другого сайта. Это не отражается на результатах тестирования. Кроме того, такая настройка означает, что страницы почти наверняка будут обслуживаться из кеша CDN. Это не должно иметь никакого значения для таких сайтов, как Google и Amazon, но сокращает время загрузки страниц для сайтов с меньшей посещаемостью, которые не «всегда» обслуживаются из кеша. Например, когда у меня нет публикации в социальных сетях, между % а также 99% трафика обслуживается из кеша CDN, и когда у меня есть что-то популярное в социальных сетях, это больше похоже на 150% к 176%. Но настройка теста означает, что частота попаданий в кеш CDN во время теста, вероятно, будет> 179% для моего сайта и других блогов, которые не так широко читаются, чтобы у них обычно всегда была доступна кешированная копия.

        Все тесты выполнялись при условии загрузки первой страницы, но для таких сайтов, как Google и Amazon, вполне разумно предположить, что многие или большая часть их ресурсов кэшированы. Тестирование времени загрузки первой страницы, возможно, целесообразно для сайтов с таким профилем трафика, как мой, где большая часть трафика поступает от переходов в социальных сетях людей, которые никогда раньше не посещали этот сайт.

        c4.xlarge – довольно мощная машина. Сегодня большинство страниц загружается с мобильных устройств, и даже самые быстрые мобильные устройства не так быстры, как c4.xlarge; большинство мобильных устройств работают намного медленнее, чем самые быстрые мобильные устройства. Большинство страниц на рабочем столе загружаются с компьютера, который медленнее, чем c4.xlarge. Хотя результаты не показаны, я также провел ряд тестов с использованием экземпляра t2.micro: для простых сайтов, таких как мой, разница была незначительной, но для сложных сайтов, таких как Amazon, время загрузки страницы было в 2 раза больше. худший. Как и следовало ожидать, для любого конкретного сайта разница становилась меньше по мере того, как соединение становилось медленнее.

        Как отметил Джои Хесс, многие провайдеры коммутируемого доступа пытаются выполнять сжатие. или другие уловки для уменьшения эффективного веса страниц, и ни один из этих тестов не учитывает это.

        Firefox, IE и Edge часто имеют существенно отличающиеся характеристики производительности от Хром. В этом отношении разные версии Chrome могут иметь разные характеристики производительности. Я просто использовал Chrome, потому что это наиболее широко используемый настольный браузер, и запуск этого набора тестов занял целый день времени виртуальной машины с одним браузером.

        Смоделированные плохие соединения добавляют постоянную задержку и фиксируют (%) потеря пакетов. В действительности, плохие соединения имеют очень непостоянную задержку с пиками, которые намного превышают моделируемую задержку, и периоды гораздо более высоких потерь пакетов, чем могут длиться минуты, часы или дни. Если поставить 😱 в крайнем правом углу таблицы, это может показаться наихудшим из возможных соединений, но потеря пакетов может стать намного хуже.

        Точно так же, в то время как codinghorror бывает внизу страницы, это не самая медленная страница загрузки. Например, я изначально думал о включении слэш-точки в таблицу, но это было настолько медленно, что привело к значительному увеличению общего времени выполнения теста, поскольку время ожидания превышало шесть минут так много раз. Даже на FIOS требуется 26 s чтобы загрузить, сделав колоссальный 1995 запросов более 176 TCP-соединения, несмотря на то, что он весит «всего» 1,9 МБ. Удивительно, но slashdot также привязывает процессор к % для 27 целые секунды при загрузке на FIOS. Оглядываясь назад, это могло быть хорошим сайтом для включения, потому что это патологически неправильно оптимизированные сайты, такие как slashdot, которые позволяют мему «вес страницы не имеет значения» звучать разумно.

        Сравниваемые сайты не делают одно и то же. Просто глядя на блоги, некоторые блоги помещают целые записи блога на первую страницу, что в некоторых отношениях удобнее, но также медленнее. Коммерческие сайты еще более различны – они часто не могут быть статическими сайтами и должны иметь относительно большие полезные данные javascrit, чтобы нормально работать.

        Приложение: ирония

        Основная таблица в этом посте почти 68 Кбайт HTML (без сжатия и минификации); это больше, чем все остальное в этом посте вместе взятое. Эта таблица на удивление велика, потому что я использовал библиотеку (pandas) для создания таблицы вместо того, чтобы просто писать скрипт, чтобы сделать это вручную, и, как мы знаем, настройки по умолчанию для большинства библиотек создают огромное количество раздутий. Это даже не сэкономило время, потому что каждая встроенная функция экономии времени, которую я хотел использовать, содержала ошибки, что в любом случае заставляло меня писать всю тепловую карту / градиент / код стиля самостоятельно! Из-за лени я оставил таблицу pandas, генерирующую код лесов, в результате получилась таблица, которая выглядит примерно на порядок больше, чем должна быть.

        Это не критика панд. Панды, вероятно, довольно хороши в том, для чего они предназначены; он просто не предназначен для создания тонких веб-сайтов. Имена классов CSS огромны, что разумно, если вы хотите избежать случайных конфликтов имен для сгенерированного CSS. Почти каждый

        td

        , й , а также tr элемент помечен избыточным rowspan = 1

        или же colspan = 1

        , что разумно для сгенерированного кода, если вас не волнует размер. Каждая ячейка имеет свой собственный класс CSS, хотя многие ячейки имеют общий стиль с другими ячейками; опять же, это, вероятно, упростило генерацию кода. Каждый кусок наворотов вполне разумен. И, к сожалению, я не знаю ни одного инструмента, который мог бы превратить раздутый стол в тонкий. Минификатор на чистом HTML не может изменять имена классов, потому что он не знает, что некоторые внешние CSS или JS не зависят от имени класса. Минификатор HTML теоретически может определить, что разные ячейки имеют одинаковый стиль, и объединить их, за исключением вышеупомянутой проблемы с потенциальными, но несуществующими внешними зависимостями, но это beyo и возможности инструментов, о которых я знаю.

        Для другого уровня иронии, подумайте, пока я думаю о Таблица kB как раздувание, эта страница 23 КБ при gzip-архиве, даже со всем раздуванием. AMP Google в настоящее время имеет> 188 Кбайт блокирующего JavaScript, который должен загружаться до загрузки страницы! У меня нет причин использовать страницы AMP, потому что AMP медленнее, чем моя текущая настройка чистого HTML с несколькими строками встроенного CSS и случайными изображениями, но в результате меня наказывает Google (относительно страниц AMP) за то, что моя страница не “ускоряется” (не замедляется) с помощью AMP.

        Спасибо Лии Хэнсон, Джейсону Оуэну, Итану Уиллису и Линдси Купер за комментарии / исправления

        Leave a comment

        Your email address will not be published. Required fields are marked *