Note: we're talking here about the difference between permalinks
%/name/%. It would be a whole different story if we were to compare
Now, there are two use cases that affect performance:
One. You have a permalink and WP needs to resolve it in order to serve the page requested.
This means setting up the WP class. The main function is at the bottom of the code. After init this involves calling
parse_request. This checks whether rewrite rules exist for this particular page and checks query variables for validity. In this case we'd like to know whether processing
example.com/123/slug takes more time than
example.com/slug. For that to matter you would have to assume that the PHP string function that needs to handle a few bytes more has a significant impact on performance.
Once the requested url has been chopped into workable chunks, the action moves to
parse_query, which in this case will be passed a query object either containing
name or both
ID (confusingly in the query object the ID is called
p). A lot of handling is done, but nothing extra for including the ID in the query.
Next follow two hooks in (
posts_selection) that are plugin territory, so impact on performance is unknown.
Now comes the main issue: will it take more time to query the database with one variable or with two? Both
name are stored in the
wp_posts table in the database. So, there is no difference in the size of the table that will be queried. Also, both are unique, because when a post is stored this is checked (OP's assumption that including ID in the url will get rid of the
-2 in posts is wrong, unless you hack the saving procedure). As a result, it doesn't really matter whether you have to query all database rows for the unique
ID or the unique
name. The only difference in performance when providing both is that after the row with the
ID has been found it will check if the
name matches. That really is negligible.
Two. You need to generate a permalink on a page.
This is done by the
get_permalink function. For standard post types the procedure only adds some lengthy calculations if you are using
name it is just a matter of search and replace in this line of code:
$permalink = home_url( str_replace( $rewritecode, $rewritereplace, $permalink ) );
The efficiency of
str_replace depends on the size of the parameters that are passed to it, but since all possible rewriting parameters are passed, not just the one or two that are actually used, this does not affect performance.
For custom post types
get_permalink refers to
get_post_permalink, which involves more calculations anyway, but essentially winds down to the same search and replace.