//div[contains(@class, 'test-class"')]
засунуть дюбель и заделать дыру штукатуркой зафиксировав тем самым дюбель.Это совсем не так работает.
Ты ждешь пока фронт отправит запрос на бек(это вообще к скорости работы стека отношения не имеет, все зависит от интернета и машины пользователя), бек его обрабатывает (в твоем случае php)(условно это займет 0,02сек с роутингом, контроллером и экшеном), потом передает на бд(вообще можно пренебречь), бд его обрабатывает(вот тут может быть условно от 0,01 до 1-2+ секунд, в зависимости от запроса), бек отправляет на фронт(пусть еще 0,02).Так вот, если операции с запросом к пхп выполняются довольно быстро, то запросов в бд во первых МНОГО, на одну нормальную страницу того же новостного портала или маркета их может быть 8-30 (это и выборка уже просмотренного, рекомендации, сам список итемов, запись действий пользователя для внутренней аналитики, счетчики просмотров, комментарии...), в зависимости от наворотов, а во вторых все они имеют разную, но безусловно превышающую, относительно кодовой части, задержку. Так что да, бд - практически всегда узкое место.
То есть оно же все поочереди выходит, то есть быстродействие языка и фреймворка получается влияет?Именно из-за того что оно все по очереди, язык 90% простаивает в ожидании данных от бд. И даже написанное на ассемблере приложение выиграет вам пусть 50% от тех 10% что работает язык, общий прирост получится поднять на 5%. Это при том что стоимость разработки и поддержки поднимется в разы. За эти деньги можно разово вложиться в железо (допустим взять второй сервер чтобы работал параллельно) и увеличить производительность в 2 раза за в 10 раз меньшую сумму.