Целью переиздания оригинальной статьи Джейка Арчибальда является повышение осведомленности и поддержка дискуссии о роли прогрессивного улучшения внутри сообщества. Мы с нетерпением ждем ваших мнений и мыслей в разделе комментариев – Ред.

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

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

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

Естественно, что данная статья представляет собой подборку лучших практических примеров и советов, основанных на реальных проектах и фактическом поведении браузера. Тем не менее, я хотел найти более весомые доказательства из “реального мира”. Оказывается, эти доказательства все время были передо мной.

Мне нравится Tweetdeck.

Я не использую Chrome без открытой Tweetdeck вкладки. Я использую это приложение много раз в день и это мой основной клиент для работы с Твиттером. Однако его работа зависит от JavaScript, который позволяет визуализировать больше, чем экран загрузки.

Ранее Твиттер имел аналогичные возможности, но со временем начал представлять исходный контент как HTML для повышения производительности. Таким образом, Твиттер предоставляет аналогичный тип данных и в нём можно проследить аналогичные случаи использования, что делает его идеальным вариантом для реального сравнения.

Тестирование.

Для начала я:

• Выполнил настройку Tweetdeck аккаунта с шестью колонками,
• закрыл все другие приложения (чтобы избежать дополнительной нагрузки на пропускную способность),
• подключился к достаточно быстрой проводной сети,
• использовал Network Link Conditioner для имитации стабильного 2 Мбит ADSL подключения,
• очистил кэш браузера.

Я установил загрузку Tweetdeck в новой вкладке, а затем снова очистил кэш браузера и далее открыл для загрузки шесть окон Chrome, что эквивалентно контенту на Твиттере (если вам интересно, то можете взглянуть на стартовую страницу).

В данном случае скорость в 2 Мбита может показаться медленной, но мне доводилось останавливаться во многих отелях, где скорость интернета и близко не доходила до отметки 2 Мбит. В области моего проживания для тех людей, у которых отсутствует возможность волоконной связи, максимальный показатель широкополосной сети имеет значение 4 Мбит. На мобильных устройствах будут гораздо более низкие скорости в зависимости от типа сигнала и качества приёма.

Результаты.

Вот два испытания играть одновременно (примечание: они были казнены отдельно):

02.080s	Tweetdeck визуализирует экран загрузки. Ранее Tweetdeck сначала отображал пустой экран.
02.150s	Твиттер отображает три “колонки” твиттов и это лишь на 70 мс позднее чем Tweetdeck визуализирует экран загрузки.
02.210s	Твиттер отображает шесть колонок твиттов. Твиттер предоставил основное содержимое страницы.
04.070s	Tweetdeck визуализирует шесть пустых столбцов. Твиттер загружает фоновые изображения.
05.180s	Tweetdeck отображает свою первую колонку твиттов.
06.070s	Tweetdeck создает другую колонку.
06.270s	… и ещё одну.
08.030s	… и ещё одну.
08.230s	… и ещё одну.
10.120s	… и ещё одну, и всё это основной контент, предоставляемый Tweetdeck. Tweetdeck на данный момент полностью загружен, в то время как Твиттер продолжает загружать дополнительное содержимое (направления, которым нужно следовать и т.д.)
10.120s	Твиттер завершил загрузку вторичного контента.

Итак, Твиттер выполняет загрузку на экран основного контента на 7,91 секунду раньше, чем Tweetdeck и это несмотря на шесть окон, которые оказывают влияние на быстродействие. Первый бит основного контента Твиттер отображает на экране на 3,03 секунды позднее.

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

Этот эксперимент проводился с очищенным кэшем, но как насчет полной версии? Далее мы проведем такой же тест во второй раз, но при этом кэш браузера не будет очищен:

00.060s	Tweetdeck визуализирует экран загрузки. Tweetdeck и в этом случае отображает пустой экран первым.
00.090s	Твиттер отображает первую “колонку” твиттов.
01.010s	Твиттер отображает вторую “колонку ”.
01.110s	Твиттер отображает третью “ колонку ”.
01.190s	Твиттер отображает четвертую “колонку ”.
01.200s	Tweetdeck отображает шесть пустых колонок.
01.230s	Твиттер отображает пятую “колонку ”.
01.240s	Твиттер отображает шестую “колонку ”. Теперь Твиттер отобразил весь основной контент.
02.100s	Tweetdeck отображает первую колонку.
02.160s	Tweetdeck отображает вторую колонку.
02.260s	Tweetdeck отображает третью колонку.
03.030s	Tweetdeck отображает четвертую колонку.
04.010s	Tweetdeck отображает четвертую и пятую колонки. Теперь Tweetdeck представил вес� … Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров Главная → Программирование → 03.09.2013 by Newsbot Comments are closed.