For Pikapuka, we addressed two separate tasks: reducing calculation time for an SEO analytics block and fixing the blog's mobile layout. In the measurement on 13 July 2026, the analytics block ran in 3.07 seconds instead of 21.98. This result applies to that particular report and dataset.
Project website: Pikapuka
Initial task
An analytics service needs both calculations within reports and readable public content. Slow calculations get in the way of working with data; article overflow makes mobile reading difficult. We used different checks for these problems.
When optimizing the report, it was necessary to save the classification results and total values. A quick answer with other numbers would not solve the problem.
Work and documented results
| Work | Result | Period or source |
|---|---|---|
| Faster SEO analytics | 3.07 s instead of 21.98 s in the SEO report | Measured on 13 July 2026 |
| Mobile blog and favicon | 24 checks across 6 screen sizes | 2 October 2026 |
Faster SEO analytics
3.07 s instead of 21.98 s in the SEO report · Measured on 13 July 2026
We optimised calculations and caching in the Metrica report. Sped up the analytics section for a large counter while preserving calculation results.
We investigated a cold query comparing SEO data. Most of the time was occupied by the analytics block: some of the results were recalculated, and a large set of phrases was processed in PHP.
Reused the already calculated overall result in the search engine comparison. Heavy processing was moved to a PostgreSQL query with a materialized intermediate result. The classification rules and priorities of dictionaries have been preserved.
We added a cache of normalized values inside the request and changed the lifetime of the existing block cache. Data and rule updates still change the cache version so that the report does not continue to use an outdated result.
After the change, we compared the outputs of the old and new implementations. In the recorded measurement, block execution time fell from 21.98 to 3.07 seconds. Matching calculation results was a separate acceptance requirement.
Mobile blog and favicon
24 checks across 6 screen sizes · 2 October 2026
We fixed overflow in 3 articles and the blog listing and adapted pagination. Updated the favicon to 120 × 120 px. Text and links were preserved.
In October, horizontal overflow was fixed in three articles and the blog list. We adapted the pagination, preserving the texts and links.
Conducted 24 tests on six screen sizes. Separately, we updated the favicon to 120 × 120 px. Checking the layout and changing the icon did not affect the calculations of the analytical report.
The public screenshots show the current desktop and mobile interface. We do not publish the private analytics report or its counter data in this case study.
How we verified the result
To speed things up, we compared the results before and after the change: summary data, classification and sections of search engines. Time measurements are given for one analytical block on a verified data set.
For the blog, the result was confirmed by checking three articles, a list and pagination at different widths. During the preparation of screenshots, no forms were sent and no private data of clients was revealed.
Scope of the result
3.07 seconds — execution time of the SEO report block in the recorded measurement. This is not the loading time of the main page and is not an indicator of the speed of all service screens.
After correcting the mobile layout, readability was checked technically. The change in traffic or conversion due to these edits was not measured in this case.
What to consider for a similar project
For a similar task, first separate server calculations from page layout. Analytics optimisation should check both execution time and matching results; layout checks should cover specific pages and screen sizes.