не буду утверждать на 100%, но есть шанс, что регулярка, которая еще будет проверять target, будет работать медленнее, чем предложенный Димой вариант

парсить хтмл – неблагодарное занятие)

так что лучше на 2 шага разбей

т.е. взять строку, сделать из нее дом-узел, применить квериселектор и промутить обработку, а потом это все обратно в инерХтмл = быстрее чем - по строке пройтись регуляркой?

не исключено

а насколько большая строка?

строка не будет - слишком большой

ну максимум в нее можно будет вместить 5-6 ссылок.

ну тогда вообще не парься

код тоже будет понятнее, чем мудреная регулярка)

просто вот эта обработка запускается каждый раз когда редактор сохраняет свое состояние, что бы на сервак я отправлял уже "подправленный" набор данных с редактора.
Т.е. когда редактор в первый раз сохранился, я прошелся, вынял все <a> подправил их.
Но когда он второй сохраняет - я так прохожусь вынимаю все <a> - но внутри обработки массива "всех <a>" - то что біло обработано - не пройдет условия для обработки (мол я уже впихнул к ним атрибут).
Я думал может тот факт что с каждым запуском обработки, у меня будут только "чистые" <a> как-то его ускорит.

да, но строк может быть много. Представь обычную статью ИТ тематики, ну сколько там ссылок 10-20 от силы, если это конечно не подборка материалов.

то есть, по факту, ты хочешь всю статью парсить регуляркой и в ней находить ссылки?

неее, что же

как минимум регуляркой я не паршу статью, сейчас покажу как редактор отдает

каждая строка редактора это элемент массива blocks. Я прохожусь по этому массиву, и захожу только в те разделы где тип (параграф, список) может иметь в себе ссылку

понял

и там уже я вынимаю значение text - и ищу в нем ссылки.

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

точнее подпилить редактора теоретически возможно, но как-то ушли от этой идеи.