Обоснование варианта венгерской нотации для иерархий URL

Один из лучшие обсуждения в эфире в эти дни вращается вокруг сокращения URL. Одна из причин, по которой люди обращаются к сервисам сокращения URL-адресов, таким как bit.ly и TinyURL, заключается в том, что веб-сайты и приложения используют чрезвычайно длинные URL-адреса. Во многих случаях это связано с открытыми иерархиями файловой системы (кстати, потенциальной угрозой безопасности) и желанием воспользоваться описательными именами файлов для SEO и информационных целей. Относительно недавно Вкусные основатель Джошуа Шахтер выразил мнение, что URL Shorteners вредны для сети , в то время как Бен Парр в Mashable опровергает с несколько причин он считает, что услуги полезны ,

Использование URL Shorteners в некоторой степени находится вне контроля разработчиков. Они не могут знать, будут ли они использоваться или нет, и это действительно выходит за рамки их обязанностей. Но тогда возникает вопрос: почему разработчики просто не генерируют короткие URL-адреса ? Почему они не ужесточают иерархию файловой системы и не представляют пользователю что-то более разумное? Разве это не устранит необходимость сокращения URL-адресов (и дискуссии)? В конце концов, очень длинные имена файлов и глубоко вложенные иерархии тратят трафик и деньги.

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

ДЛИННЫЕ URL-адреса НЕ ТОЛЬКО BANDWIDTH HOG

Первое напомнило мне, что cookie-файлы являются гораздо более скудными по потреблению пропускной способности, так как cookie-файлы размером 4-5 КБ, вставленные в заголовки HTTP, такие, как такая большая нагрузка на День благодарения, не редкость в наши дни. Это напоминание хорошее, потому что решить его сложнее, чем просто укоротить URL. Другими словами, это обсуждение на следующий день - но у нас это будет в конце концов. Достаточно сказать, что есть техническое решение (баночка с печеньем) для этой проблемы, и мы углубимся в это позже, потому что это не совсем уместно в этом обсуждении.

Второй ответ был более непосредственно связан с негативным влиянием автоматического сокращения URL-адресов на связанные с бизнесом функции и цели.

Ориентация ключевых слов на ваш URL может обеспечить (небольшое) повышение SEO релевантности страниц, если оно соответствует запросу.

http://www.seomoz.org/blog/11-best-practices-for-urls

http://www.seomoz.org/article/search-ranking-factors

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

http://www.useit.com/alertbox/20030630.html

Это поднимает важный момент, который следует рассмотреть, прежде чем принимать решение об уменьшении длины имен файлов.

Если значение «поиска» для вашей компании таково, что потеря поискового трафика из-за удаления ключевых слов из URL-адресов и последующей SED (поисковая оптимизация) будет значительной, то, возможно, сокращение URL-адреса не является хорошей идеей. Если вы заметите это, в рейтинге страниц или в потоке трафика, или если вы измеряете эффективность SEO в своей организации, то вам определенно следует учитывать это в отношении потенциальных затрат на длинные URL-адреса.

ОСТАВЬТЕ ЖИРОВОЙ ДРУГОЙ

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

Например, возможно, это тот случай, когда ваши URL должны содержать определенные ключевые слова, которые обязательно сделают их длинными. Но должны ли вспомогательные ресурсы содержать длинные описательные имена файлов? Вам действительно нужно использовать /assets/monthly/images/this/is/ridiculous/myimage.jpg, когда чего-то намного короче и проще будет достаточно? Существует множество вспомогательных типов объектов, составляющих веб-страницу, которые не могут так или иначе повлиять на усилия SEO. Рассмотрим иерархию файловой системы, которую вы используете для:

• Сценарии
• CSS
• Изображений
• Часто используемые элементы содержимого (верхние и нижние колонтитулы, меню и т. Д.)

И проверьте, используют ли они чрезмерно длинные URL-адреса. Влияние сокращения длины имен файлов поддержки объектов при сохранении длинного URL-адреса страницы в имени SEO, вероятно, является более значительным, поскольку отношение объектов к URL-адресу страницы в среднем составляет 50: 1. Сокращение даже в иерархической структуре именования может оказать существенное влияние на пропускную способность.

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

ДОВЕРЯЙТЕ МНЕ, ВЫ ЛЮБИТЕ ЭТОТ САЙТ

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

Разница между сокращением URL самостоятельно с помощью посредника или скрипты на стороне сети (или просто делая это как дизайн во время разработки), это то, что вы не запутываете URL, а просто сокращаете его. Проблемы с услугами сокращения URL-адресов частично связаны с тем, что они названы неправильно. О, они сокращают URL, но для этого они полностью стирают любую ссылку на оригинал и, по сути, представляют пользователю бред.

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

КОРОТКО, НО НЕ ОБУСЯТЬ

Учтите, что программисты давно используют такие методы, которые позволяют другим разработчикам идентифицировать имена переменных «с одного взгляда». Венгерская нотация один из таких методов. Используя префикс имен переменных с использованием кодированной системы идентификаторов, разработчики могут легко отличить короткое целое число (sNum) от длинного целого (lNum) и так далее.

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

Похожие

Комментарии