Рекомендаций по работе с веб-сайтами Перевод

Yori Yori 19 Апреля 2022

Перевод статьи Джеффа Хуанга, которая опубликована в 2019 г., а обновлена 24 августа 2021 г. «Эта страница рассчитана на долгое время». Про несколько проблем Интернета, а именно — «гниение ссылок», потери ценного контента в сети и др.


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

Закладка за закладкой приводили к мертвой ссылке за мертвой ссылкой. Что исчезло: уникальные статьи на kuro5hin о технической культуре; коллекция математических головоломок и связанных с ними дискуссий ученых, с которыми меня познакомил мой отец; учебные пособия Вудмана по обратному проектированию из моих школьных лет, где я впервые попробовал чувство контроля над программным обеспечением; даже моя последняя закладка, серия сообщений в Google+, разоблачающих несоответствие зарядных устройств usb-c спецификации, исчезла.

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

Конечно, я тоже внес свой вклад в эту проблему. В статье, которую я опубликовал 7 лет назад, есть аннотация, включающая демонстрационную ссылку, которая была захвачена спам-страницей с изображением тыквы на ней. Частью этого упущения была лень, чтобы избежать необходимости обновлять и поддерживать работоспособное веб-приложение год за годом.

Я рекомендовал своим студентам размещать веб-сайты на Heroku и публиковать портфолио на Wix.

Тем не менее, каждая платформа с незаменимым контентом когда-нибудь отмирает. Географические города, Живой журнал, what.cd, теперь Yahoo Groups. Однажды Medium, Twitter и даже хостинговые сервисы, такие как GitHub Pages, будут разграблены, а затем отброшены, когда они больше не смогут расти или не смогут найти работающую бизнес-модель.

Проблема многогранна.

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

Во-вторых, растущий набор библиотек и фреймворков делает Веб более сложным. Сначала появился jquery, затем bootstrap, npm, angular, grunt, webpack и многое другое. Если вы веб-разработчик, который следит за последними новинками, то это не проблема.

Но если нет, то, возможно, вы программист встраиваемых систем, технический директор стартапа, корпоративный разработчик Java или аспирант по химии, уверен, что вы, вероятно, могли бы понять, как настроить какой-нибудь веб-сервер и набор инструментов, но будете ли вы продолжать в том же духе год за годом, десятилетие за десятилетием? Вероятно, нет, и когда в следующем году вы столкнетесь с проблемой зависимости пакета или выясните, как восстановить свои html-файлы, вы можете просто поднять руки и заархивировать файлы, чтобы разобраться с ними «позже». Даже простые технологические стеки, такие как генераторы статических сайтов (например, Jekyll), требуют рабочего процесса и в какой-то момент перестанут работать. Вы попадаете в ад зависимостей npm и забываете команду для упаковки выпуска. А иметь веб-сайт с несколькими html-страницами сложно; как бы вы узнали, как каждая страница ссылается друг на друга? index.html.old, копия about.html, index.html, nav.html?

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

Итак, что мы можем сделать с этими проблемами? Это не такая простая проблема, которую можно решить в одной этой статье. Машина обратного хода и archive.org помогает дольше сохранять некоторый контент. И иногда альтруистичный индивид повторно размещает контент в другом месте.

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

Но я думаю, что мы должны рассмотреть как 1) случайный «сопровождающий» веб-контента, кто-то, кто не постоянно следит за новейшими веб-технологиями, что означает, что веб-сайт должен иметь низкие потребности в обслуживании; 2) и сканеры, которые сохраняют контент и личные архиваторы, «архиватор», что означает, что веб-сайт должен быть прост в сохранении и интерпретации.

Итак, мое предложение — это семь нетрадиционных рекомендаций по работе с веб-сайтами, которые должны быть информативными, чтобы их было легко поддерживать и сохранять. Руководящее намерение состоит в том, что сопровождающий будет стараться поддерживать веб-сайт в рабочем состоянии как минимум 10 лет, возможно, даже 20 или 30 лет. Это не обязательно противоречивые взгляды, но это устремления, которые не являются мейнстримом — манифестом для долгосрочного веб-сайта.

Cемь нетрадиционных рекомендаций по работе с веб-сайтам

Вернемся к ванильному HTML / CSS — я думаю, мы достигли точки, когда html / css стал более мощным и удобным в использовании, чем когда-либо прежде. Вместо того, чтобы начинать с гигантского шаблона, заполненного .js includes, теперь можно просто снова написать простой HTML с нуля. CSS Flexbox и Grid, canvas, селекторы, box-shadow, видеоэлемент, фильтр и т.д. Устраняют большую потребность в библиотеках JavaScript. Мы можем избежать jquery и bootstrap, когда они не нужны. Чем больше библиотек включено в веб-сайт, тем более хрупким он становится. Пропустите полизаполнения и префиксы CSS и придерживайтесь атрибутов CSS, которые работают во всех браузерах. И часто проверяйте свой HTML-код; это может избавить вас от головной боли в будущем, когда вы столкнетесь с ошибкой.

Не сводите к минимуму этот HTML — сведение к минимуму (сжатие) вашего HTML и связанных с ним CSS / JS кажется, что это экономит драгоценную пропускную способность, и все крупные компании делают это. Но почему бы и нет? Что ж, вы не так уж много экономите, потому что ваши веб-страницы должны быть сжаты перед отправкой по сети, поэтому упреждающее сокращение вашего контента, вероятно, не сильно экономит пропускную способность, если вообще что-то делает. Но даже если это сэкономило несколько байтов (в конце концов, это просто текст), теперь вам нужно запустить процесс сборки и добавить это в свой рабочий процесс, поэтому обновление веб-сайта стало более сложным. Если в html есть ошибка или будущая несовместимость, свернутую форму сложнее отлаживать. И это недружелюбно по отношению к вашим пользователям; так много людей начали работать с HTML, разбив эту кнопку просмотра исходного кода, а сведение к минимуму вашего HTML мешает этому идеалу обучения, видя, что они сделали. Сведение к минимуму HTML не сохраняет его образовательного качества, и архивируется только результирующий фрагмент кода.

Предпочитайте одну страницу нескольким — несколько страниц трудно поддерживать. Вы можете потерять представление о том, какие страницы на что ссылаются, и это также приводит к некоторой системе шаблонов страниц для уменьшения избыточности. Сколько страниц на самом деле может поддерживать один человек? Имея один файл, вероятно, просто index.html , проста и незабываема. Используйте эту бесконечную вертикальную прокрутку. Вам никогда не придется копаться в своих файлах или grep, чтобы увидеть, где находится какой-то контент. И как ваша версия должна управлять этим файлом? Должны ли вы использовать git? Засунуть их в папку old/? Ну, мне нравится простой подход к присвоению имен старым файлам с указанием даты их удаления, например index.20191213.html. Использование формата даты ISO позволяет легко сортировать ее, и нет никакой путаницы между американским и европейским форматами даты. Если у меня есть несколько версий за один день, я бы использовал стиль, аналогичный тому, который обычно используется в файлах журналов, из index.20191213.1.html. Приятным побочным эффектом является то, что вы можете получить доступ к более старой версии файла, если помните дату, без входа на веб-хост.

Покончить со всеми формами горячих ссылок — это предостерегающее слово, похоже, исчезло из словаря Интернета, но это одна из причин, по которой я видел, как совершенно хороший веб-сайт разваливался без всякой причины. Прекратите напрямую включать изображения с других веб-сайтов, прекратите «заимствовать» таблицы стилей, просто ссылаясь на них, и особенно прекратите ссылаться на файлы JavaScript, даже те, которые размещены оригинальными разработчиками. Горячие ссылки обычно считаются грубыми, поскольку ваши посетители используют чужую пропускную способность, это замедляет работу пользователя, вы позволяете другому веб-сайту отслеживать ваших пользователей, и, что еще хуже, если местоположение, на которое вы ссылаетесь, изменяет структуру папок или просто отключается, тогда сбой каскадом распространяется и на ваш веб-сайт. Google Analytics не нужен; храните свои собственные журналы сервера и настраивайте GoAccess или сокращайте их, как вам нравится, предоставляя вам более подробную статистику. Не отдавайте свои журналы Google бесплатно.

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

Навязчиво сжимайте свои изображения — быстрее для ваших пользователей, меньше места для архивирования и проще в обслуживании, когда вам не нужно создавать резервные копии огромной папки. Ваши изображения могут иметь такое же высокое качество, но быть меньше. Уменьшайте ваши SVG-файлы, сжимайте PNG-файлы без потерь, создавайте JPEG-файлы, чтобы они точно соответствовали ширине изображения. Стоит потратить некоторое время на поиск наиболее оптимального способа сжатия и уменьшения размера ваших изображений без потери качества. И как только WebP получит поддержку в Safari, переключитесь на этот формат. Безжалостно сведите к минимуму общий размер вашего веб-сайта и сделайте его как можно меньше. Каждый МБ может стоить кому-то реальных денег, и на самом деле мой оператор мобильной связи (Google Fi) взимает цент за МБ, так что веб-сайт размером 25 МБ, который сегодня довольно распространен, сам по себе стоит четверть, примерно столько же, сколько газета, когда я был ребенком.

Устраните риск неработающего URL–адреса — существуют службы мониторинга, которые сообщат вам, когда ваш URL-адрес не работает, и в один прекрасный день вы не поймете, что ваша домашняя страница не загружалась в течение месяца, а поисковые системы ее деиндексировали. Потому что 10 лет — это больше, чем рассчитано на срок службы большинства жестких дисков или операционных систем. Но чтобы полностью исключить риск взлома URL-адреса, настройте вторую службу мониторинга. Потому что, если первый из них остановится по какой-либо причине (они переходят на платную модель, они закрываются, вы забываете что-то обновить и т.д.), вы все равно получите одно уведомление, когда ваш URL-адрес недоступен, а затем поймете, что другая служба мониторинга отключена, потому что вы не получили второе уведомление. Помните, что мы пытаемся поддерживать что-то в рабочем состоянии более 10 лет (в идеале намного дольше, даже 30 лет), и в течение этого периода многие службы будут отключены, поэтому две службы мониторинга безопаснее.

После выполнения этих действий продолжайте и поместите немного текста в нижний колонтитул: «Страница была спроектирована так, чтобы прослужить долго», со ссылкой на эту страницу, объясняющей, что это значит. Эти слова обещают, что сопровождающий сделает все возможное, чтобы следовать идеям, изложенным в этом манифесте.

Прежде чем вы начнете протестовать, это явно не для веб-приложений. Если вы создаете приложение, то создайте свое веб- или мобильное приложение с нужным вам рабочим процессом. Я даже не знаю ни одного веб-приложения, которое оставалось бы аналогичным образом функционирующим более 10 лет, так что в любом случае это кажется безнадежным делом (за исключением преподавателя python Филиппа Го из-за его минималистской стратегии его поддержки). Это также не для веб-сайтов, поддерживаемых такими организациями, как Википедия или Twitter. Зарплаты ИТ-команды, вероятно, достаточно, чтобы поддерживать веб-сайт в рабочем состоянии в течение некоторого времени.

На самом деле, даже не так важно, чтобы вы строго следовали 7 «правилам», поскольку они скорее провокация, чем строгие правила.

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

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

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

https://jeffhuang.com/designed_to_last/

3 Ответа

  1. German German 19 Апреля 2022 (ред.)

    Я полностью согласен с принципом — страницы должны быть спроектированы таким образом, чтобы выжить долгое время. И дополнил бы это, сказав, что если вы разрабатываете свою страницу так, чтобы она просуществовала 10 лет, то поместите ее в интернет-архив в первый день. Кстати, а почему на этом сайте нет такой возможности?

    1. Evg Evg 19 Апреля 2022

      Будет, это будет однозначно.

  1. OleStep OleStep 19 Апреля 2022

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

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