Программисты, занимающиеся рефакторингом внешнего интерфейса, — это исключение, которое уделяет внимание коду, а также опыту. Хотя оптимизация кода сложна, существует больше инструментов для тестирования производительности, подтверждающих результаты оптимизации. Однако, чтобы испытать такие вещи, как мы можем доказать, что это хорошо или плохо?
1. Оптимизация визуального восприятия
- загрузка страницы
- запрос данных
- рендеринг изображения
Во-вторых, данные доказывают эффект опыта
Сегодня я сосредоточусь наwebnovel«Сайт ПК познакомит вас с двумя вышеупомянутыми пунктами, как оптимизировать реконструкцию с точки зрения опыта и как использовать данные, чтобы доказать, что ваша оптимизация эффективна.
1. Оптимизация визуального восприятия
Чтобы оптимизировать опыт, мы должны сначала узнать, что такое хороший опыт.
Не знаю, где я слышал поговорку: «Хороший опыт — это тот, который не хочется испытывать». Это предложение звучит противоречиво, но оно совпадает с общепризнанной концепцией Xiaohongshu «Не заставляйте меня думать». Вы хотите, чтобы пользователи приходили на «веб-новеллы» читать романы, а не хвалить наш веб-опыт. Когда пользователи начинают обращать внимание на работу нашего веб-сайта, это означает, что наш опыт плохой.
Где пользователи могут легко почувствовать опыт нашего веб-сайта?
1. Загрузка страницы
Во-первых, когда страница загружается. Здесь отчетливо виден логотип «вебновелла» и три маленькие иконки, при обновлении страницы будет процесс с нуля в одно мгновение.
мы"webnovel«Сайт предназначен для зарубежных пользователей по всему миру, выпрыгивая из порочного круга совместимости с браузерами IE в Китае, поэтому мы выбрали значки SVG с высокими требованиями к совместимости с браузерами, но с лучшими эффектами рендеринга для маленьких значков». SVG принадлежит вектору. значки, при условии, что громкость может быть гарантированно меньше, ее также можно увеличивать и уменьшать без искажений». Мы сослались на код JS, который Iconfont «онлайн-инструмент управления иконками от Ali» автоматически сгенерировал для нас на странице, и результат показал указанный выше эффект рендеринга.
Принцип на самом деле очень прост, структура DOM нашего значка SVG динамически добавляется внутри нашего тега после выполнения JS. Таким образом, будет эффект рендеринга страницы сначала, а затем рендеринга значка. Поэтому мы, естественно, подумали о том, чтобы поместить структуру DOM, сгенерированную JS, непосредственно во внутреннюю часть, чтобы решить эту проблему.
Но это глупо и наивно. Когда мы копировали DOM-структуру, мы обнаружили, что объем SVG-кода слишком велик. Размещение его непосредственно внутри страницы сильно увеличило бы объем HTML-кода и повлияло бы на скорость рендеринга всей страницы. чувство подхватили.Кунжут и арбуз.
В конце концов, мы приняли решение разделить иконки SVG.Значки, отображаемые на первом экране, были напрямую добавлены в DOM, а остальные значки по-прежнему динамически загружались JS. Это мешает пользователям видеть значки за пределами сгиба, даже если они мерцают. Таким образом, мы решили проблему мерцания значка в верхней части страницы, а также избежали проблемы количества кода значка SVG. Пользователи не могут воспринимать мерцание значков, и они не будут тратить время на размышления о том, быстро или медленно загружается наша страница.
Предварительная загрузка данных первого экрана может в определенной степени улучшить работу наших пользователей при обновлении и переходе на страницу.
2. Запрос данных
Второе место — это когда мы запрашиваем данные. Когда мы переключаем TAB, мы ясно видим эффект загрузки. Действие пользователя запускает запрос данных.Во время ожидания мы используем загрузку, чтобы информировать пользователя об этом состоянии, чтобы уменьшить беспокойство пользователя по поводу ожидания. На самом деле это обычная практика для загрузки данных и расширения возможностей.
Но каким бы быстрым ни был наш запрос данных, пользователи все равно могут четко видеть эффект от этой загрузки. Это не то, чего мы хотим.
Здесь мы справляемся с этим следующим образом: когда пользователь наводит указатель мыши на эту кнопку, мы думаем, что у пользователя есть желание щелкнуть, поэтому мы заранее инициируем операцию запроса данных. Когда пользователь нажимает эту кнопку, весь процесс нашего запроса данных может быть завершен, что означает, что наше состояние загрузки исчезло. На этом этапе пользователь может напрямую видеть данные, которые мы загрузили. То есть очень вероятно, что пользователь не увидит наше состояние загрузки в течение всего процесса. Разве это не оптимизация опыта, который мы хотим?
Использование времени простоя пользовательских операций для предварительной обработки — хороший способ улучшить работу с запросами данных.
3. Рендеринг изображения
Мы все знаем, что изображения и значки являются элементами отображения, особенно обложка книги, сделанная нашими дизайнерами веб-сайта с большой осторожностью, мы, естественно, готовы выбрать более крупные, но более качественные изображения высокой четкости. Чтобы не влиять на отображение текста, нам пришлось выбрать механизм, похожий на ленивую загрузку изображений, чтобы отложить загрузку изображения.
Но ясно видно, что это то же самое, что и логика загрузки предыдущей загрузки данных, для которой требуется карта-заполнитель, представляющая состояние загрузки. Когда изображение загружается, изображение-заполнитель мгновенно заменяется обложкой нашей книги высокой четкости, поэтому в это время происходит неожиданное мерцание.
Когда пользователи увидят вспышку, они будут думать о том, быстрая у вас загрузка или медленная. Но мы хотим: «Не заставляйте меня думать». Мы не хотим, чтобы пользователи думали о чем-то другом, кроме нашего продукта. Поэтому нам нужно найти способ ослабить или даже убрать это мерцание.
Говоря об этом, мы должны популяризировать механизм кэширования изображений, который есть в самом нашем браузере. Изображения, к которым ваш браузер обращался в течение определенного периода времени, будут кэшироваться браузером. Когда вы снова увидите изображение, изображение будет напрямую считывать содержимое, кэшированное браузером, и открываться мгновенно, и проблемы с мерцанием не будет.
Поэтому мы задались вопросом, могли бы мы использовать этот механизм для решения проблемы перепрошивки раньше. Но теперь сложность в том, что обложка нашей страницы сведений больше, чем обложка первой страницы. Поскольку размеры разные, это разные картинки, поэтому понятия кэширования нет.
Если мы сделаем так, чтобы страница сведений также использовала обложку домашней страницы, маленькое изображение страницы сведений будет растянуто и будет выглядеть размытым. Если на домашней странице используется большая обложка книги страницы сведений, накладные расходы на загрузку данных изображения на домашней странице слишком высоки.
Решением, которое мы используем здесь, является метод трехслойной суперпозиции. Мы помещаем карту-заполнитель, маленькую обложку книги и большую обложку книги в одно и то же положение в соответствии с уровнем изображения выше. Когда пользователь входит на нашу страницу сведений с главной страницы, наша карта-заполнитель и небольшая обложка книги мгновенно отображаются с использованием кеша браузера.Поскольку небольшая обложка книги размещается поверх карты-заполнителя, пользователи не могут ее видеть. В это время загружается обложка большой книги.Когда загружена обложка большой книги, она будет закрыта поверх обложки маленькой книги. Когда пользователь внимательно смотрит на обложку книги, очень вероятно, что большая обложка книги уже загружена.
Как видно из GIF на изображении выше, весь процесс изменился с предыдущего изображения-заполнителя на мигание большой обложки книги и стал текущим градиентом от маленькой обложки книги к большой обложке книги. На самом деле, пользователям очень трудно обнаружить.
Увидев это, некоторые студенты могут спросить, раз здесь нет изображения-заполнителя, зачем вам нужно загружать это изображение? На самом деле причина очень проста, потому что не все заходят на страницу сведений с главной страницы. Возможно, что пользователь открыл ссылку напрямую. Затем карта-заполнитель возвращается к исходной логике в это время. Сначала посмотрите на заполнитель, а затем на обложку книги. Конечно, я также должен признать, что для таких пользователей мы фактически загрузили дополнительный ресурс в виде небольшой книжной обложки. Но для оптимизации опыта я лично считаю такое потребление ресурсов приемлемым.
Еще один интересный момент заключается в том, что поскольку изображение-заполнитель, маленькая обложка книги и большая обложка книги загружаются в этом месте одновременно, они также будут кэшироваться браузером как картинки.Когда пользователь переходит на другие страницы, если есть та же картина, которая мгновенно открывается снова. Таким образом, мы в полной мере используем кеш браузера, что еще больше улучшает взаимодействие с пользователем на нашем веб-сайте.
Кэширование изображений делает работу веб-сайта лучше, чем хорошо.
Во-вторых, данные доказывают эффект опыта
Опыт оптимизации визуального слоя — это то, что вы видите, это то, что вы получаете, и вы можете быстро увидеть результаты оптимизации. Однако существует множество проблем с опытом, вызванных различиями в браузерах или различиями пользователей, и мы не можем интуитивно и быстро доказать эффект оптимизации опыта. Мы должны полагаться на данные, чтобы доказать это.
Чтобы говорить с данными, мы должны сначала иметь данные, а инструмент сбора данных, используемый нашими зарубежными компьютерными станциями, передается Analytics от Google. Вот интересная история по этому поводу.
Я видел этот результат на днях, когда тестировал нашу страницу «веб-новеллы» с помощью webpagetest, «всемирно известного инструмента для тестирования скорости загрузки веб-сайтов».
Как это сделать? Мы выбрали грубый, но эффективный подход, включив CSS непосредственно в наш HTML-файл «CSS Inline Inside HTML». Файлы CSS исчезли, посмотрите, у вас все еще есть DNS, SSL... Ух ты! Отлично, я отнес это боссу, чтобы попросить кредит. Босс дал мне два балла и ошеломил меня.
Во-первых, у вас, очевидно, эффект при первой загрузке страницы.. Для большинства пользователей, которые уже закешировали этот файл CSS, как вы докажете, что эта оптимизация снова используется для них?
Во-вторых, «веб-новелла» — это глобальный веб-сайт, как вы можете доказать, что эта оптимизация оптимизирована для пользователей во всех регионах?
Да как мне это доказать? При таком большом количестве пользователей "веб-новелл" в мире я использовал тестовый отчет "веб-страницы", чтобы охватить все терминалы и группы пользователей, который показывает, что он не заслуживает доверия. И как мне доказать, насколько сильна эта оптимизация?
В это время появился хороший китайский коллега, и мой партнер по фронтенд-логике помог мне сделать вывод случайного предварительно обработанного образца AB внутри фрейм-машины. Причина очень проста, пусть 50% пользователей загружают наш CSS оригинальным способом, а остальные 50% пользователей используют способ, которым наш CSS встроен в HTML. Таким образом, мне нужно только добавить идентификатор, чтобы различить две выборки и сообщить об этом в GA «Google Analytics», затем GA автоматически поможет нам подсчитать и обработать эти выборки, и, наконец, мне нужно только сделать 10 в среднем из два образца.Вычитание внутри, мы знаем, сколько наших усилий по оптимизации.
Возникает еще один вопрос, что мы должны сообщать GA в виде данных? Очевидно, что время загрузки всей веб-страницы используется для оправдания загрузки CSS неправильно. Затем я использую время после загрузки CSS, чтобы доказать это? Но как я могу доказать, что страница отображается после загрузки CSS? Разве мы не оптимизируем опыт? Как вы можете просто полагаться на загрузку файла CSS, чтобы доказать, что пользовательский опыт улучшился?
В этот момент я грязный. Нет, я хочу задержать всю сцену, чтобы не паниковать.
Опыт, опыт, CSS не грузятся, пользователи даже страницы не видят, как это можно назвать опытом? Таким образом, время, когда пользователь впервые увидел страницу, считается в определенной степени свидетельством качества опыта.
Как получить это время? На самом деле с помощью API производительности можно получить время каждого этапа работы браузера, показанное на рисунке выше.
Браузер Chrome может использовать window.chrome.loadTimes().firstPaintTime; Браузер IE8+ может использовать window.performance.timing.msFirstPaint;
чтобы получить время начала рендеринга страницы. В итоге все сошлись во мнении, что под временем «firstPaintTime — navigationStart» следует приблизительно понимать время с момента, когда пользователь посещает страницу, до момента, когда он ее видит.
Итак, я очень рад сообщить на этот раз в GA, а затем версия выходит в сеть, ожидая сбора данных. В итоге получается следующая статистика:
Конечно, мы также сообщили об этой узкой проблеме студентам на стороне сервера. Тогда ответ был таков, что "вебновелла" - это пока новый проект нашей зарубежной станции, и многие зарубежные серверы нуждаются в доработке. Я считаю, что эта болевая точка будет решена после следующих устройств.
Отчетность по данным, чтобы оптимизация вашего опыта была обоснованной.
Суммировать
Пространство ограничено, поэтому здесь я привожу лишь разрозненный список, я лично считаю, что вы можете провести некоторую оптимизацию реконструкции с точки зрения пользовательского опыта и как использовать данные, чтобы доказать свою силу оптимизации. Я надеюсь, что это вдохновит и поможет вам.Если у вас есть какие-либо вопросы, пожалуйста, оставьте мне сообщение, и мы сможем подробно пообщаться.