Efficient alternative to `?after=<tag_name>`. Pagination

[3F]

While web version uses ?after=<tag_name>, API v3 seems allows only per_page / page requests.
Thus we can't just use {location.search} as it was presented in data.

Alternatively we can of course request to each separate tag/release, BUT!
In fact this means toooo many requests to API:
(unauthenticated: 60 requests per hour / authenticated: 5000 requests per hour)

TODO: Efficient alternative to ?after=<tag_name>.
Current implementation will use only single request via pagination to the first 100 records.
Others requires at least N requests to N page when no related info from web version, eg.:
(100 records page1) -> failed -> (100 records page2) -> failed -> (100 records page3) -> success;

Any after param such /releases?after=v1.6.1 will indicate to the page != 1
But web version uses 10 records per page. That will not help us detect page 11 for the next 100 records.
Anyway, the other records can be processed through individual /releases/tags/:tag